This anecdote was to show that authority is not composed of amorphous ambient liquid which the application is ignorant of.
Authority, like data, is something that the application must name and thus have names for.
Capabilities provide a concept that normally supplies a name for and an authority over some element in the system, such as a piece of data or the function of turning on the garage lights.
- The Deputy
- The deputy is a program that is called upon (deputized) by a client to perform some action and at the same time granted by the client temporary authority to take that action.
The client provides a name of a resource upon which to take the action.
The deputy has additional built-in authority to take other actions that are a necessary part of its job.
- The Deputy is Confused when
- The client names a resource to which it lacks authority.
The deputy attempts its normal act on the resource named by its client.
The deputy’s act is permitted by security mechanisms because the deputy’s built-in authority is sufficient for this act.
The deputy has unwittingly abetted an indirect action by its client that the security rules were designed to prevent.
The deputy has unwittingly abused its own built-in authority.
The deputy is blameless if the semantics of the system did not allow it to say that the act was to be subject to its client’s authority.
Capabilities aid the deputy in that the argument supplied by the client to the deputy is a capability which naturally includes the necessary authority.
The deputy’s action is via that capability.
In a capability system, the client, by hypothesis, is unable to designate something to which it lacks authority.
Here is some historical information on the development of the idea.