[cap-talk] "ambient authority" on wiki.erights.org

[David-Sarah Hopwood]

Rob Meijer wrote:
> On Mon, June 15, 2009 17:22, David-Sarah Hopwood wrote:
>> Rob Meijer wrote:
>>> I would think, given your above statements, that you would feel the
>>> following might be a fair definition of "ambient authority":
>>>
>>> 1) "The subset of the authority of an actor that it derives from its
>>> ability to use ambient permissions in a non designating way."
>>>
>>> Where I would feel the following might be a more useful definition (thus
>>> including static permissions):
>>>
>>> 2) "The subset of the authority of an actor that it derives from its
>>> ability to use ambient permissions. (either in a designating or non
>>> designating way)."
>>
>> I don't understand what distinction you want to make by "designating" vs
>> "non-designating".
> 
> Let's take the 'open' example from the wikipedia page:
> 
>   f1=fopen("filename", "r");
> 
> There is nothing there that designates the permissions that should be used.
> "filename" both names and designates the object but not the permissions.

Okay, but this is unconventional use of terminology: we normally use
"designate" when referring to objects. Using it to refer to permissions
as well would be confusing, for example it would make the phrase
"separation of designation and authority" ambiguous.

> Now compare that to the static variable:
> 
>   void Alice::someMethod() {
>       sPowerfulReference->usePermission();
>   }
> 
> sPowerfullReference being a named object reference does designate the
> permission to be used.

There are two requests here (unfortunately obscured by the language syntax).
It is clearer if we make the static dereference explicit:

  Reference r1 = deref("sPowerfulReference");   <- ambient request
  assert(r1 != null);
  r1->usePermission();                          <- non-ambient request

This is actually very similar to the fopen example. Compare:

  FILE *f1 = fopen("filename", "r");            <- ambient request
  assert(f1 != NULL);
  fread(buf, sizeof(buf), 1, f1);               <- non-ambient request

>> In all systems I'm aware of, the object(s) that are to be directly acted
>> on by a request are designated in that request. The difference at issue
>> is whether the request has to explicitly specify the permission(s) to
>> access each such object (either paired with, or combined inseparably with
>> the corresponding designator).
> 
> So far I'm completely with you.
> 
>> "Ambient" means that it doesn't.
> 
> OK, according to that definition, and assuming you want ambient authority
> to refer to authority not permissions, I would interpret it that 1 would
> fit your view.
> 
> Does the fopen example (the non designating use of ambient permissions)
> represent an instance of ambient authority to you,

Yes (the call to fopen, not uses of the returned file handle).

> and does the static reference (the designating use of ambient permissions)
> represent non ambient authority to you?

The dereference of the static variable represents use of ambient authority.
The '->usePermission()' method call does not.

> Looking at the wikipedia page, the page, the definition of "Ambient" as in
> the sense that it exists in a broadly visible environment (often, but not
> necessarily a global environment) where any subject can request it by name
> seems quite sensible, and compatible with 2. The reason why the static
> reference might according to the wikipedia be non ambient as in 1 is
> buried in the (in my view questionably ambiguous) definition of "name":
> 
> "any way of referring to an object that DOES NOT ITSELF INCLUDE
> AUTHORIZING INFORMATION, and could potentially be used by any subject;"

This is necessary to exclude capabilities (for example) from being
understood as names, which is clearly not the intent.

> I must say looking at the static reference example, and reading the
> definition of name on wikipedia, I feel it can absolutely be read both in
> a way as to say it is ambient authority as in a way as to say it is non
> ambient authority.

Does the separation into two requests clarify why this is?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com