[cap-talk] Implementing attenuated delegation
kpreid at switchb.org
Thu Jun 21 10:56:13 PDT 2012
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/>
More information about the cap-talk