Objects, keys, and messages

Programs running in capability systems, such as KeyKOS, hold some representations of authority called keys.

Keys are tokens of authority. A program may only cause actions warranted by the keys it holds. Any action that a program causes is enabled by some key that it holds and explicitly identifies in an invocation of that key.

A key designates a specific object. The authority conveyed by a key is specific to just the object designated by that key. Different keys may designate the same object but convey different authority over that object. Exercising authority represented by a key is done by invoking the key. Some objects have state which may be modified by a holder of a key that designates the object. Weaker keys to that object may only let the holder sense the state of the object.

A slot holds a key. All keys reside in slots. Just as a register holds different numbers at different times, so does a slot hold different keys at different times.

An invocation involves a message, specified by the invoker and delivered to the object designated by the invoked key. The invoker may include in a message keys and/or data that he holds, whereupon the designated object may also hold them.

In summary: If object A holds a key b to object B then A may request B’s service by invoking b thus sending a message to B.