To avoid confusion, ObjectCapabilityModel is the new name for the original capability model, as represented originally by DennisAndVanHorn and other early capability operating systems, ProtectionInProgrammingLanguages, and the various ActorLanguages. 

This model can be implemented in a number of different ways:
* ObjectCapabilityOperatingSystem (DennisAndVanHorn, HydraOs, CapOs, MachOs, KeyKos, ErosOs)
* ObjectCapabilityLanguage (ActorLanguages, ProtectionInProgrammingLanguages, W7 (DoubleYouSeven), JouleLanguage, E (EeLanguage), possibly OzLanguage)
* ObjectCapabilityHardware (IntelFourThreeTwo, CTSRD/CHERI)
* Capability-based VirtualIsa''''''s (AsFourHundredMachineInterface)

The pure ObjectOrientedProgramming model and the ActorsModel of computation is essentially lambda calculus + local side effects + method dispatch. The SchemeLanguage, the MlLanguage, and the PiCalculus are lambda calculus + local side effects. As explained in OdeToTheGranovetterDiagram and ParadigmRegained, to get from any of these (or from ConcurrentLogicProgramming) to the ObjectCapabilityModel, you don't need to add anything, and you don't need to remove anything. Essentially all you need to do guarantee that sources of causality outside these models (such as mutable static state or static native devices) are not made available to computation by other means. With these guarantees, the object reference graph becomes the access graph. (The access graph is just a better way to visualize Lampson's access matrix.)

Often, local object capability systems are connected by a cryptographic capability protocol. A distributed capability protocol by itself cannot be more than a PasswordCapabilityModel. But when used to connect local object capability systems, we say the result implements the DistributedObjectCapabilityModel.

For programming style guidelines specific to the ObjectCapabilityModel, see CapabilityOrientedProgramming. ''COP? What a fortuitous acronym. :-)''

Features common in many OO languages that are incompatible with the ObjectCapabilityModel include static class member variables or global variables, and  ambient authority to 'system' resources (such as console IO, FileSystem). C/C++ 'static' function variables are also problematic. Such globals become an issue... both because untrusted code is often able to access or manipulate, and because ''mobile'' code really should maintain a binding to the global back on the source machine (i.e. rather than being cut off via sandbox!). Static ''methods'' (aka 'procedures') are legit if restricted to operations upon their arguments. An ObjectCapabilityLanguage must support alternative patterns for access to system resources; a common pattern is passing a PowerBox into 'main'.

MultiMethods are also problematic. They generally violate encapsulation. But, even if MultiMethods were restricted to the public interfaces of objects, they would be problematic because untrusted code (modules, plugins, extensions) might introduce its own MultiMethods to obtain control of sensitive operations. That said, MultiMethods ''patterns'' could be implemented securely by more explicitly managing a 'rulebook' of methods, with capabilities to access it or register new MultiMethods. This won't be as syntactically convenient as MultiMethods, but it may achieve what you need.

----
Unlike the other CapabilitySecurityModel''''''s, the object-capability model isn't a security model to be bolted on to some other model of computation. Rather, it is a model of computation that's inherently modular and secure. It dates from when the study of modularity and abstraction mechanisms had not yet become a separate discipline from the study of security. DennisAndVanHorn understood that good modularity and abstraction mechanisms should be good security mechanisms, and sought to solve the whole problem with one unified set of mechanisms.

----
The EeLanguage implements a ObjectCapabilityLanguage in JavaLanguage. See http://www.skyhunter.com/marcs/ewalnut.html

----
CategorySecurity CategorySecurityModel