[tahoe-dev] Tahoe Access Control

[Zooko O'Whielacronx]

On Fri, Jun 3, 2011 at 12:36 PM, Brian Warner <warner at lothar.com> wrote:
>
> If there were a dedicated CLI command, maybe "tahoe attenuate-cap"?

Nit-pick: "attenuate" means the action of a general sort of object
which owns a greater authority and offers a lesser authority. A
typical example is an object in a ocap language which has a capability
to another object, and has the ability to invoke ".write()" or
".read()" on that other object, but it offers only a ".read()" method
to its users. We say that that object "attenuates" the authority of
the more powerful cap and offers a less powerful cap--the reference to
itself. Attenuation can be quite general: it might involve
statefulness (such as a revocable forwarder, which at some point in
time deletes its copy of the more powerful cap and thus renders itself
impotent), and it might involve arbitrary code being run in response
to attempts to use it.

For the operation of making a less powerful *crypto* cap out of a more
powerful *crypto* cap, such as producing a Tahoe-LAFS read-cap from a
Tahoe-LAFS write-cap, the word "diminish" is more specific than
"attenuate". Diminishing is a one-time operation that takes a cap and
returns a new cap, and it is usually seen as not maintaining extra
state or running extra code when you try to use the new cap.

References:

I got this terminology of "diminish" from Jonathan Shapiro's work e.g.
[1] and his PhD dissertation. That is more in the operating systems
tradition of capability research.

I assume that "attenuation", like almost everything from the
programming languages tradition of capability research, is best cited
as "re-read Mark S. Miller's PhD dissertation".

Regards,

Zooko

[1] Shapiro, J.S.: The practical application of a decidable access
model. Technical Report SRL-2003-04, SRL, Baltimore, MD 21218
(November 2003)