Financial Cryptography

"How is a capability different to an object?"

A discussion on cap-talk on the definition of capabilities seems to have erupted... Here is one capabilty fan's interpretation of what a capability is, and how it relates to objects, in the sense of Java and other OO languages.

-------- Original Message --------
Subject: "How is a capability different to an object?"
Date: 6 May 2004 20:45:04
From: zooko@zooko.com
To: iang@systemics.com

You asked me that after MarkM's talk at FC'99, and I didn't know.

Nowadays, I would say this:

Think of a graph with circles connected by arrows. (I really like thinking in these terms. If you don't like thinking in terms of graphs, this probably isn't the best explanation for you.)

Now, let any "thing" in the system under consideration, whether that thing be a person, computer, process, chunk of data, computational object, etc. be one of those circles.

Now say that there are only three ways that one circle can get an arrow pointing to another circle:

1. The first circle creates the second circle (e.g., a process spawns another process, a Java object constructs another Java object, etc.). In this case, the second circle begins life with only a single incoming arrow, coming from the first circle.

2. There was a third circle who already had an arrow pointing to the first circle and an arrow pointing to the second circle. This third circle gives to the first circle an arrow which points to the second circle. This is the event captured in the famous Granovetter Diagram [1].

3. A link between two objects comes in from outside of this world. Please ignore this case for now, and revisit it after you understand what capabilities are.

Okay, now suppose you want to do some access control. You're writing a program, or a policy, or something that wants to specify who can touch what. To be concrete, let's say that you want to specify whether Alice can or cannot read a certain file. If you were never going to change your mind, and if you were not going to allow other people to make their own access control decisions while interoperating with yours, then this would be easy -- just write down "Alice, File, Yes", or "Alice, File, No". That is the basis of the Access Control List approach to access control.

The Object Capabilities approach to access control is to draw a graph with a circle labelled "Alice" and an arrow pointing to a circle labelled "File". Or leave the arrow off if you don't want to grant Alice that access.

Okay, now where are we? Well, the three rules (ignoring the 3rd) above tell you how the access control state can evolve over time. The basic ACL approach that we sketched above doesn't include this notion of evolving over time, so assuming that your access control decisions evolve over time, we would have to add it.

[End of General Definition]

Okay, now I wrote this in as general a manner as I could because I know that your interests include things outside of a specific thing like "this one virtual machine running on my computer". However, to make the notion of capabilities concrete, suppose you have a Java Virtual Machine, and the circles are Java objects and the arrows are Java references. Now suppose one of the objects is under the control of Alice and can be used by her to read files. Another object represents a file.

There, now you are using capabilities for access control in that JVM.

I'll stop for now!

--Zooko

[1] "Alice captured in the instant of giving Bob an arrow to Carol." Making this image required high speed photography by professional National Geographic photographers.

Posted by iang at May 7, 2004 07:03 PM | TrackBack