Some object-based programming languages (e.g. JavaScript, Java, and C#) provide ways to access resources in other ways than according to the rules above including the following:
Such use of undeniable authority violates the conditions of the object-capability model. Caja and Joe-E are variants of JavaScript and Java, respectively, that impose restrictions to eliminate these loopholes.
Computer scientist E. Dean Tribble stated that in smart contracts, identity-based access control did not support well dynamically changing permissions, compared to the object-capability model. He analogized the ocap model with giving a valet the key to one's car, without handing over the right to car ownership.4
The structural properties of object capability systems favor modularity in code design and ensure reliable encapsulation in code implementation.
These structural properties facilitate the analysis of some security properties of an object-capability program or operating system. Some of these – in particular, information flow properties – can be analyzed at the level of object references and connectivity, independent of any knowledge or analysis of the code that determines the behavior of the objects. As a consequence, these security properties can be established and maintained in the presence of new objects that contain unknown and possibly malicious code.
These structural properties stem from the two rules governing access to existing objects:
As a consequence of these two rules, an object can obtain a reference to another object only through a preexisting chain of references. In short, "Only connectivity begets connectivity."
Almost all historical systems that have been described as "capability systems" can be modeled as object-capability systems. (Note, however, that some uses of the term "capability" are not consistent with the model, such as POSIX "capabilities".)
KeyKOS, EROS, Integrity (operating system),[dubious – discuss] CapROS, Coyotos, seL4, OKL4 and Fiasco.OC are secure operating systems that implement the object-capability model.
Miller, Mark Samuel (May 2006). "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control". erights.org. Baltimore, Maryland. Retrieved 28 July 2013. http://erights.org/talks/thesis/ ↩
Mark S. Miller; Ka-Ping Yee; Jonathan S. Shapiro (2003). "Capability Myths Demolished" (PDF). Technical Report SRL2003-02. Systems Research Lab, Johns Hopkins University. {{cite journal}}: Cite journal requires |journal= (help) http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf ↩
[1] citing: J.B. Dennis, E.C. Van Horn. “Programming Semantics for Multiprogrammed Computations.” Communications of the ACM, 9(3):143–155, March 1966. http://srl.cs.jhu.edu/pubs/SRL2003-03.pdf ↩
Lutsch, Felix (26 August 2019). "Agoric Q&A with Dean Tribble". Chorus One. https://blog.chorus.one/agoric-qa-transcript/ ↩
Henry Lieberman (June 1981). "A Preview of Act 1". MIT AI memo 625. {{cite journal}}: Cite journal requires |journal= (help) /wiki/Template:Cite_journal ↩
Henry Lieberman (June 1981). "Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1". MIT AI memo 626. {{cite journal}}: Cite journal requires |journal= (help) /wiki/Template:Cite_journal ↩