From: "Karp, Alan" <>
Date: Wed, 4 Dec 2002 08:28:07 -0800
Subject: RE: [e-lang] "Capability Myths Demolished" (was: Software securit y workshop)

Jonathan Shapiro wrote:
>                                         The first is the so-called
> "split capability" system from Alan Karp and friends, which is a very
> nice design in spite of being (IMHO) inaccurately named. Alan may not
> agree with me. 

No disagreement here.  Do you have a better name?  My paper "Using Split Capabilities for Access Control" is scheduled for the next issue of IEEE Software.  I'm just getting ready to fax the changes to the galley proofs to the editor, so this is my last chance to find a better name before the concrete sets. 

Alan Karp 
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1141
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278 shap

> -----Original Message-----
> From: Jonathan S. Shapiro []
> Sent: Wednesday, December 04, 2002 8:14 AM
> To:
> Subject: Re: [e-lang] "Capability Myths Demolished" (was: Software
> security workshop)
> On Tue, 2002-12-03 at 17:49, David Wagner wrote:
> > There are two kinds of mechanisms that might have claim to the name
> > capabilities:
> >   Lampson-style capabilities: What you call a C-list.
> >   E-style capabilities: Things that combine both authorization
> >     and designation.
> > 
> > I suspect you would like to reserve the term "capabilities" 
> for E-style
> > capabilities only.  I, however, was taught that the word 
> "capabilities"
> > encompasses both styles (or that it refers to Lampson's notion)...
> I'm not sure that the disconnect you surmise actually exists. 
> There *is*
> confusion about the term capability created by Netscape, but it is a
> different one from the confusion that you have identified.
> First, the Lampson defintion *does* combine designation and 
> authority. A
> Lampson capability is an (object-designator, rights) pair in 
> the Lampson
> paper. Second, the definition of the term comes from Dennis and van
> Horn, who are quite clear that designation is critical. To my 
> knowledge,
> there are only three existing "capability" system in which designation
> and rights have in fact been separated. The first is the so-called
> "split capability" system from Alan Karp and friends, which is a very
> nice design in spite of being (IMHO) inaccurately named. Alan may not
> agree with me. :-) The second is Netscape capabilities, which even
> Netscape concedes were misnamed. The third is POSIX 
> capabilities, which
> was a knowing and deliberate choice of naming to undermine the
> credibility of the term, made with malice aforethought.
> A C-list isn't a capability. It is a collection of 
> capabilities. One of
> the key differences in various capability system designs is whether
> C-lists are sets or maps. In the "C-list as set" approach, 
> possession of
> a capability is required (demonstrated by membership in the 
> C-list), but
> operations do not explicitly designate the particular capability they
> are using. In some cases they may designate the C-list. This lends
> itself to a variety of bugs in code and some interesting 
> ambiguities if
> multiple candidate authorities are present in the same C-list:
>   1. Which one should be used, or do we understand this
>      to mean the authority that is the union of the presently
>      held capabilities?
>   2. If union, how is the runtime to understand the correct
>      computation of union for user-defined objects (Wulf's
>      notion of extensible capability systems in Hydra, or
>      start keys in KeyKOS/EROS).
> The second model is the "C-list as map" model. In this model, the
> wielder must designate both the C-list and the specific contained
> capability under which the operation is to be performed.
> Either C-list model falls under the general heading of "capability
> systems" in the existing literature. Because I find extensibility
> important and implicit capability designation (note: not object
> designation) dangerous, I personally prefer the "C-list as 
> map" model. 
> shap
> _______________________________________________
> e-lang mailing list
e-lang mailing list