[E-Lang] Possession as Metaphor (was: Pet Extensions and such (was: what is good about E?))

[Mark S. Miller]

[quoting out of order again]
At 06:16 PM Thursday 7/26/01, Ken Kahn wrote:
>When I last bought a car, they gave me the keys and a key they called a
>valet key. This was news to me. I asked and they said it doesn't open the
>trunk but does open the doors and starts the engine. A nice physical example
>of POLA.

Yes.  Jonathan Shapiro uses exactly this example to explain capabilities at 
http://www.eros-os.org/essays/capintro.html#defn .  I like it.


>I would have thought the problem in Beta 2.2 is that some keys are master
>keys that work throughout a floor or building - not that lots of keys are on
>the same key ring. Or was the problem one that doesn't map to this metaphor?

The problem is indeed one of mapping the metaphor.  The Toontalk lock/keys 
system you describe, as well as SPKI, are actually more key-like than 
capability-like.  Toontalk and SPKI are being truer to this 
metaphor-for-capability systems than capabilities themselves are.

What's the difference between capabilities and keys?  Keys separate 
designation and authority.  Houses and cars that you can't enter are still 
part of your world.  In a key system, when you want to enter a house, you 
have to make two choices: "Of all the houses I might want to enter, which 
one do I wish to enter now (and where is it)?" and "Of these various keys I 
have, which one should I use to enter the house?"  The user logically should 
only need to make one choice.  In your key ring system, and SPKI's ambient 
authority, you select the house you want, and if you possess the needed 
authority, it will automatically be found and provided.

In a capability system, to a potential user of the house, the key *is* the 
house.  You interact with the house by interacting with the key, or with 
objects derived from interacting with the key.  There are not two things 
being brought together.  Whereas in a physical key system there are: 
designation (which house) and authority (keys).

So, if both schemes reduce the user's burden to one choice, is there a 
difference?  Yes, a huge one, and I think it's the basis for Alan's concern 
about E-Speak2.2's POLA violating key rings.  If the provision of authority 
is automated, by selection from a large pool, then deputies can be confused 
into, for example, using their own authority to take actions that they 
"thought" were being authorized by keys handed to them by their clients.

By contrast, in the capability scenario, to the user, the key names not a 
particular house, but a house-purpose to them.  The user obtained this key 
by being constructed with it in a particular instance variable, or by 
receiving it in a particular argument position of some message.  This tells 
them *why* someone gave them this key to use. There can be no deeper answer 
to "Which house is this?" than this "why". As I say on 
http://www.erights.org/elib/capability/delegations.html : "In a capability 
system, the authority applied to an action is only the authority *explicitly 
brought to bear* by the agent [...] This is accomplished with no extra 
notation by combining designation with authority." [emphasis added]

See http://www.cap-lore.com/CapTheory/ConfusedDeputy.html for why this is so 
important.  I'm sure you're already familiar with this paper, but it's one 
of those few papers that should be reread again every few years.  I get more 
out of it each time.


It's also illuminating to notice where KeyKOS does provide an automatic 
key-ring-like mechanism:  The Can Opener.  For debugging purposes, the Can 
Opener holds a bag of openers for opening domains.  When presented with a 
domain to open, it searches the bag for one that works and applies it.  
Openers are doing rights amplification.  

Rights amplification is about separating an authority into two parts that 
must be brought back together in order for the authority to be used.  While 
the separation isn't designation vs authority, it's still a separation, and 
has many of the same consequences.  We are now exactly parallel to our 
original houses, keys, and locks metaphor, and Ken's solution for making it 
easier exactly describes what KeyKOS did.

House == Domain
House designation == start key
Entering the house (or being able to enter the house) == Domain key
House Key == Brand-based Opener
Key Ring == Can Opener (holds and applies a bag of Brand-Based Openers)
Opening Door == amplify a start key to a Domain key with an Opener

The KeyKOS Can Opener, being an instance of the automated key ring pattern, 
therefore does have some confused deputy dangers.  But at least we only have 
to face this danger in the very limited context of rights amplification.


 From here, I'm not sure how to bring the discussion back to UI design for 
secure installation.


        Cheers,
        --MarkM