What is a capability?

Quibblers see this first.

Capabilities are protected names. A capability is a name in that it designates something within a computing system. Just as “/usr/bin/grep” names something in Unix so does a capability name something in Keykos. I can’t depict capabilities here for they are not composed of characters. The program that holds and can wield a capability does not have access to the bits of that capability. Message passing primitives in capability systems allow a holder of a capability to send it in a message to another program. The Unix name “work.c” may name different files for different programs and if I pass “work.c” to you it will probably access different data for you than for me. If I pass you a capability, on the other hand, it will yield the same data for you as for me. Unlike names in directories, capabilities suffice to access the designated thing whereas classical directories include extra protection structures designed to define who can access the designated thing. When a program passes a capability to another, it has passed its authority to the other. Here are some notes on names and capabilities, and why capabilities should not appear as bits to the application.

When a programming language is adapted to a capability system it is customary to arrange that some language identifiers designate capabilities, perhaps by denoting an integer index into a list of capabilities. It is also customary for command systems to hold capabilities in a directory for users under names chosen by the user. Unlike classic operating systems, however, such a directory seldom plays a role in the execution of the application and most application components will never reside in such a directory. A Unix file cannot exist that is not registered in some directory. Objects may exist in capability systems, with capabilities designating them without those capabilities appearing in any directory.

An analogy between capabilities and pointers is instructive. A pointer designates a computing object. A pointer is not protected however and bit patterns not intended as pointers cause havoc when so used. Java has protections against such misuse and consequently Java’s object references serve as capabilities. (Some more quibbling about names and capabilities.)

Registering application components in Unix directories often exposes them to programs and people that should have no access to them. Most computer users have been faced with directories holding large and expensive objects with little way to learn the consequences of deleting them to recover space. Many applications have failed because the machine administrator could not tell what files were necessary to some critical application.

The application within a capability system appears to the computer administrator as a single object of known size with no parts. We designed, but did not implement for Keykos, controls so that a subsystem upon which an application depended could not be deleted without the authority to delete the application.

The Message Metaphor

The text above is best explained in a metaphor where program components are said to communicate via messages or signals. The subroutine pattern is replaced by the idea of sending a message to the routine and receiving a message in return. In this context a capability serves as the address of a message denoting the thing to which to deliver the message. If communication between system components is limited to these messages which must be addressed with capabilities and capabilities may be included in messages, then we probably have a capability system.

If there are no calls, whither the stack?

Capabilities often designate storage objects such as pages and segments. Such things are not normally thought to be receiving and sending messages. It is constructive to describe them this way, however.

In this light the operations that a capability is said to support in other modes of description, may instead be explained as merely some data in the message that the receiver interprets which is the most meaningful part of the message.

Sometimes we say that there are distinct capabilities to the same object. Joule calls these “facets”. The object is able to discern thru which facet a message arrives. The same situation can alternately be described by saying that the facets are to different objects that share the state of some larger object.

This section needs cleaning and repositioning!!

Other Characterizations of Capabilities

Some definitions of capabilities emphasize that a capability permits a specific set of actions or methods on the object that it designates while other caps to the same object allow a different set. Keykos digs a bit deeper and merely includes a data byte in a key to get the same effect. They are inter-definable.
In the job of getting a message to B the cap platform has two duties: Crypto concentrates on the second part of the problem. Internet and Ethernet concentrate on the first part of the problem. Capabilities unify the two problems and solve them at the same time within the confines of the cap platform.


Bill Weiher suggested the term “license” as something a person holds indicating that he is competent to know how to perform some action. This is an indication of competence, not trust. It is a useful idea but I think it plays no role here. Truth is you need a license to operate an iPhone.