The Four Delegation Problems
Alice gives Authority to Bob. Mallet wants that authority, but Alice wants to deny this authority to Mallet. There are two yes/no questions, corresponding to the two question marks above.
The above links explain each of these cases, and examines the differences in how Capabilities vs. Access Control Lists (ACLs) address these issues. In summary
Only Prohibit What You Can Prevent
Historically, capabilities have suffered in competition with ACLs because of a perception that they were weaker than ACLs at expressing limits on delegation. (ref Bobert, Gong, Wallach) As we've seen, the one place where capabilites are indeed weaker at expressing a prohibition is the one case where the prohibition is unenforceable -- indeed incoherent. ACLs, by enabling such prohibitions to be expressed, only weakens security. By leading users and programmers to make decisions under a false sense of security about what others can be prevented from doing, ACLs seduce them into actions that compromise their own security.
By dividing up the issue of prohibiting delegation into these four categories, we see that
This misunderstanding has misled the computer world into building ACL-based systems for around 20 years (Unix, MacOS, Windows9x, WindowsNT). For capability systems to catch on, they must be viable in an ACL-infested world. What are the options for interfacing capability secure systems to a legacy of ACL permissions? Answering this question should be a fruitful area for research.
The Third School: Cryptography
Modern cryptography is creating a third school of computer security. This school is characterized by
We see a natural affinity between capabilities and modern cryptography. Not only can capabilities be implemented cryptographically, but many (not all) of the security relationships being explored by modern cryptography can be naturally expressed in capabilities. The world of financial cryptography has converged on bearer instruments, almost by necessity given the above two principles. Capabilities are a pure logic of bearer instruments. We expect interfacing capabilities to modern cryptographic systems -- those founded on the above two principles -- to generally be straightforward.
We see no comparable affinity between ACLs and modern cryptography.
What we refer to here as "delegation of authority" is in many ways similar to what contract law would call "assignment of rights". An important difference is that, here, the acquisition of authority by the delegatee does not normally imply the loss of that authority by the delegator. By contrast, in contract law, the acquisition of rights by the assignee does normally imply the simultaneous loss of that right by the assignor. The Ode's taxonomy of kinds of rights refers to this as the distinction between shared and exclusive rights.
For controlling access to physical objects, it's easier to create a system of exclusive rights, since they can be more easily moved than copied. Electronic access control systems -- whether based on capabilities, ACLs, or cryptographic protocols -- more easily support the creation of shared access rights. The Ode, ERTP (see also The Digital Path), and the Waterken IOU protocol show to build exclusive-rights transfer systems (one closer to the conventional meaning of "assignment of rights") as a layer of abstraction on top of a system of capability-based shared-rights.
We thank [May I acknowledge you by name?] for bringing both these similarities and differences with contract law to our attention.
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.