[cap-talk] password capabilities & object capability model?

Jed Donnelley capability at webstart.com
Tue Aug 19 14:06:11 CDT 2008

At 07:12 AM 8/19/2008, Mark Miller wrote:
>On Tue, Aug 19, 2008 at 3:06 AM, Rob Meijer <capibara at xs4all.nl> wrote:
> > I am writing a proposal article for a linux centered magazine on the
> > subject of AppArmor & MinorFs and the access control model used and
> > enabled by MinorFs.
>Wonderful! I look forward to it.

I also look forward to seeing it.

> > Currently I talk about MinorFs as a 'capability based' system.
> > MinorFs in contrast with most recent capability based systems that
> > advocate to be 'object capability' systems, uses password capabilities.
>Sorry, but this very common and useful category of capability system,
>even when used in an object-oriented style, is neither an
>object-capability system nor a password capability system.
>It isn't ocaps, since references are unguessable rather than
>unforgeable. Put another way, access is based on what you know rather
>than what you have. Knowledge can be transfered even through one-way
>bit channels, and so the star properties are impossible.
>As I was first using the term "password capabilities", it is a
>password capability system, but the Monash system is not. But then
>(years ago on cap-talk) Toby pointed out that the term "password
>capabilities" was coined by the Monash system to describe what they
>were doing. I agree that this historic claim does and should take

Hmmm.  I'm not quite so picky (refined, careful?) about the use
of some terms such as "password capability".  I'll point out that in
the 1981 "Managing Domains in a Network Operating System" paper:


that reviewed opportunities for communicating capabilities I referred
to such "sparse data" capabilities as "password-controlled capabilities".
The work that paper refers to (LINCS/NLTSS) was initially implemented
in 1979 - about the same time as the Amoeba work as I recall.  I believe
the above reference precedes any reference to "password-capabilities"
by those working on the Monash systems.  The earliest Monash reference
I can find is:


from 1984.  Still, since the Monash papers do seem to try to own
the "password-capability" term, perhaps it's best to use a more
generic term like "sparse capability".

>For what you are doing, the proper historic term in the literature,
>(first?) used by Amoeba, is "sparse capabilities". I sometimes use
>that, but I prefer "cryptographic capabilities" or "cryptocaps". Also
>used on cap-talk (and I think first suggested by Jed Donnelley):
>"capabilities as data". But it's quite a mouthful.

"Sparse capability" seems good to me.  To me the term "cryptographic
capability" seems to suggest something about the implementation.
It's easy to imagine a "sparse capability" or "password capability"
implementation with no cryptographic algorithms involved - though
you do have to generate 'random' data.

>If you only have authenticity but not unguessability, then perhaps

"YURL" to me also suggests something more Web (http) specific.

>If only unguessability without authenticity, then perhaps
>"webkey". If both, I recommend "cryptocap".

I'm not sure what to recommend, but as I note, "cryptocap" seems to
me to imply something about the implementation.  Perhaps if your
implementation does use cryptography (e.g. like the Tahoe file
system definitely does) then "cryptographic capability" or
"cryptocap" would be fine.  I consider such capabilities to be
specific instances of "sparse capabilities" or "capabilities as

To me "sparse capability" or even "data capability" seem best.
Most important I think is to flesh out what you mean and compare
it to other work when you first start using your term.

> > Further, if anyone would be interested in reviewing the proposal article
> > before I submit it to the magazine, please let me know.
>I have had good luck posting draft to cap-talk as a whole for review.

That seems like a good idea to me.  I'd read the paper and feed back

--Jed  http://www.webstart.com/jed-signature.html 

More information about the cap-talk mailing list