Capability Attenuation
Often there is a capability that provides a range of functions and we come to need a capability that provides a sub-range of those functions.
Sometimes this need is foreseen when the first cap is defined and sometime not until later.
Sometimes the subset is defined merely by restriction of methods (OO speak) or orders (Keykos speak).
Other possible restrictions may be, for example, to restrict the first parameter to be even.
Early capability hardware provided capabilities to memory and defined a bit therein allowing writing.
The same capability with that bit set to 0 allowed only reading.
These bits were called permission bits and a primitive operation would transform a cap by turning off some caller specified permission bit.
A weakened cap (p bit = 0) could be used anywhere a strong cap could be used, until a store was attempted via that cap.
This allowed a degree of polymorphism where code that did not store, could run correctly with either sort of capability.
Another sort of situation is where there is some multiply instantiated abstracted state and a variety of capabilities thereto.
There may be no common functions between these caps and any site where one of the keys is used must likely know which sort it is.
One source of examples are three sorts of service key in Keykos.
Typically the program that wields a more powerful cap must know more of the logic of those abstracted data.
The weaker caps can be acquired by invoking the corresponding stronger key with a specific order for the weaker key.
Keykos considered defining a permission field in each capability but rejected that plan.
In each case the attenuation is accomplished by an order (method) on some stronger key to the same object.
The data byte in the start key conveniently supports this plan in most cases.
Synthetic Attenuation
For a capability X that is used by sending a message via X, attenuation can be achieved by building a new object that holds X and forwards permissible messages that it receives to X.
The functionality that defines X is unmodified.
Descriptions and Implementations
For several reasons it is beneficial to achieve attenuation by small modifications to the code that defines the strong caps, but document the result as if a new weaker object related to the original had been created.
Sometimes the opposite plan is strategic.
The two views are externally equivalent but the repertoire of patterns may fit one description and not the other.
Charlie Landau showed that for some purposes it is good to be able to assert that distinct keys denote distinct objects.
In such cases I had to settle for adding that one of the two objects held a key to the other to explain how the pair behaved externally.