From: Dean Tribble <>
Replying To: marcs <>
Date: Sun, 08 Dec 2002 12:57:14 -0800
Subject: Re: [e-lang] Naming Capability Systems

I'm going to attempt to respond to Tyler's messages by expanding on this 
message,  and filling in some of the important points that led to what 
otherwise looks like a glib set of answers. shap

First a definition for David :-)  "Authority" is the term that I use 
generically for some set of access rights.   It might be represented as a 
capability, a privilege, etc.  Is there a different, existing term that is 
as generic?

One of the problems with the particular naming issue was a confusion between 

- building blocks; e.g., capability, objects, etc. 
- foundation semantics; e.g., caps-as-sets, ambient authority. the UNIX kernel
- systems; larger scale aggregations, from the foundations on up (e.g., 
UNIX, E, Java, J2EE, etc.)

The phrase "ambient capability system" made people  (including me) think of 
systems of "ambient capabilities", rather than systems made from 
capabilities in which authority is wielded implicitly, by performing 
operations that require the authority.  The true confusion in that word 
juxtaposition is that some people were talking about foundations, some were 
talking about systems, and some were talking about building blocks.

In a previous email, I gave examples of where people had started from 
E-like foundations, and built ambient authority systems.   One of the 
questions was whether those were capability systems or not, and if so, we 
could not generally speak positively of capability systems.  The eventual 
conclusion was that they must be, if nothing else, because that's what too 
many people think they were.  As Tyler notes, that's not the issue.  People 
don't learn much about capabilities now because they think Lampson 
discredited the entire area; they certainly don't make subte distinctions 
within it.  The key is to make it clear that while Lampson may have been 
correct about his straw man, it was a straw man that does not apply to the 
systems that we are building.  So, consider the following table: alan_karp

                Capabilities        ACLS
Ambient      | Lampsons,       |   all
authority    | Eros-MODEL      |
foundations  |                 |
Designated   | Secure object   |  not
authority    | systems, E,     |  possible
foundations  | KeyKOS, EROS    |
              |                 |

The big point is that ambient authority systems have a variety of problems 
(many enumerated in my previous message); Lampson made a system from  
capabilities, but then modeled it as an ambient authority system. Thus his 
conclusions about ambient authority capability systems are interesting, but 
not relevant to the object capability systems that we are talking 
about.  They do not generalize to all capability systems.

Also note that "Ambient authority systems" is not a subset of "capability 
systems", but rather a cross-cutting distinction,  that may be a more 
important distinction in many ways.  For example, I believe that all ACL 
systems are necessarily ambient authority systems (certainly all the ones 
that I encounter :-).  If the above diagram is correct, then capabilities 
are important *because* they can build designated authority systems, and 
not vice versa :-)

>There is a real risk that "lambda" as an adjective would cause Silicon 
>Valley VC

That was one of many problems with the term,  but it's not worth 
reconstructing :-)

>"object capability system".
>"ambient-authority capability system".

Note that this does not define terms for the building blocks of these two 
systems because they can't be clearly distinguished,  and the distinction is 
not significant.

I know there are a few important points missing  (there was one thing that 
MarkM cared about a lot that I'm leaving out) but I can't remember 
them.  Another message :-)

The upshot is that the discussion on Friday was much more in line with and 
about the points that Tyler raises.   I hope this helped make that clear 


e-lang mailing list