[cap-talk] Implementing attenuated delegation

[Kevin Reid]

On Jun 21, 2012, at 10:18, David Bruant wrote:

> More specifically, I wish to provide a generic attenuation feature, but 
> the more I think about it, the less I find how to do it. The conclusion 
> I'm coming to is that the possible (and relevant) attenuations are 
> highly coupled to the object I want to attenuate and more precisely, its 
> public API, so a generic feature is hard to achieve.

This conclusion is essentially correct, in my understanding. These are the sorts of attenuation which can be expressed without reference to specific protocols[*]:

• Shallow revocability: that is, the attenuated cap stops delivering messages to the original cap on command. This is known as a caretaker or revoker. The caveat is that an arbitrary object may have an operation which is "return yourself" or "pass yourself to this argument" or "return a cap equivalent to yourself"; therefore a caretaker is useful only when the target is cooperative and designed with a caretaker in mind. The specific requirement is that the target object must not return or otherwise provide to its callers objects which themselves provide authority.

• Membranes. A membrane is similar to a caretaker in that it wraps a target cap; it is different in that it also creates new wrappers for every cap returned by the target, and "inverse" wrappers for every cap passed *to* the target. That is, a membrane *transitively* interposes itself between the client and the target.

Membranes can provide a variety of services depending on their design. Membranes without knowledge of protocols can do things such as:

+ Deep revocability: all elements of the membrane shut themselves down on command.

+ Translation: A membrane can be used to genetically convert the messages passing across it; for example, the serialization of messages in a distributed ocap system, or the “FFI” layer intermediating between two different dynamic object systems.

+ Voluntary oblivious compliance (VOC): A subsystem may be wrapped in a membrane which protects it by making mistakes, such as by preventing a specific type of cap (which is intended to be closely held by that subsystem) from passing out of it.

+ Audit-based semantic constraints[†]: An attenuating membrane may make use of reliable information about the wrapped object's methods (reaction to messages); for example, if methods may be known to have no side effects (on the receiver), then a “read only” attenuating membrane may be defined. In E, such information is provided by the Auditors mechanism.


[*] Protocol: A set of messages, such as the set of messages which an object understands.
[†] I don't know a good name for this.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>