[cap-talk] Concening entry "ambient authority" in Wikipedia

[Dave Chizmadia - Gmail]

Rob,

    I think you're using a more restricted definition of
ACI than I am ...

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Rob Meijer
> Sent: Friday, June 05, 2009 9:53 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Concening entry "ambient authority" 
> in Wikipedia
> 
> 
> On Fri, June 5, 2009 14:40, Dave Chizmadia - Gmail wrote:
> > Could I suggest the following wordy, but precise defintion? ...
> >
> >     "The term 'Ambient Authority' refers to an access control
> >     design pattern in which one Actor (the Initiator) is not
> >     required to explicitly designate the specific authority by
> >     which it requests an action by another Actor (the Target).
> >     Ambient Authority is (nearly?) inevitable in systems where
> >     the access control check is made at the Target by evaluating
> >     access control rules over ACI (Access Control Information)
> >     provided by the Initiator (or on behalf of the Initiator by
> >     its access control infrastructure). In such cases the
> >     specific authority required for an action is inferred from
> >     the ACI, rather than being explicitly designated. Ambient
> >     Authority is possible in systems where the Initiator must
> >     present a token authorizing a requested action if the Inter-
> >     Actor Communication system provides a "helper" facility that
> >     automatically looks through the list of Initiator
> >     authorization tokens to find the one that will allow the
> >     action requested by the Initiator."
> >
> > -DMC
> 
> I like to compare the user based filesystem access control at 
> the process
> level of granularity to an equivalent patern at the 
> class/object level of
> granularity.
> 
> 1) A UNIX process has ambient authority to a filesystem as a 
> result of, and
>    limited, by the user id that the process runs under. This 
> authority is
>    implicitly shared with UNIX process running under the same user id.
> 2) An object A has ambient authority to an (static member) 
> object B as a
>    result of, and limited by the fact, that the object is an 
> instance of a
>    particular class C. This authority is implicitly shared with other
>    objects of the class C.

    So what is the problem? 

    In example 2, the ACI is class membership. The type system, which 
is acting as the access control infrastructure, checks the class of 
the Initiator instance object and renders a decision about access on 
that basis. In a strict OCap system, that check isn't part of the 
access control model, since possession of the Target's object 
reference is both necessary and sufficient to invoke the desired 
method, but is part of a type safety model, since invocation won't
be allowed to proceed if the class membership check fails.

> I thus feel the implicit sharing of 1/2 is much more relevant to a
> definition than the ACI component of 1.

    The implicit sharing of example 1 is on the basis of shared ACI in 
the form of a common userId, while the implicit sharing of example 2 
is on the basis of shared ACI in the form of a common class. Both 
examples are covered by my definition.

> Rob

-DMC