[cap-talk] Derivative rights

[Jed Donnelley]

At 07:25 PM 2/4/2008, ross mcginnis wrote:
>...
> > 3. This:
> >
> > https://wiki.nersc.gov/bin/view
> >
> > isn't a capability because it isn't bundled with
> > the authority to operate on it (e.g. read or write)
>
>I believe that I could challenge you on most of these points, but I 
>shall just concentrate on point 3) since this is very relevant to my 
>previous argument:
>
>You are saying the https://wiki.nersc.gov/bin/view isn't a cap 
>because it doesn't bundle authority to read or write. I agree 
>completely with you here, BUT: it does bundle me an authority- the 
>derived authority to *attempt* to read/write (In fact I just did 
>attempt it- it came up with dialog box asking me for username and 
>password).  The fact that I couldn't read or write doesn't mean that 
>couldn't attempt to read or write.  The attempt is a definite and 
>distinct right that I have and can exercise at will.

The properties that I gave off the top of
my head for capabilities (you can find better
lists) are more or less guidelines.  I "good"
capability will have these properties strongly and
clearly.

The examples, by the same token, can of course
be "challenged".  We aren't talking about
mathematical definitions or proofs here.

As for the example you chose to challenge,
of course the information:

https://wiki.nersc.gov/bin/view

helps a bit to know a URL to challenge, but there
are so many other ways to obtain the same information
that the unforgeability property is certainly also
lacking in this case - even if just considered
for its "authority" to challenge the Web site
(which, incidentally, I run).

You'll find people on this list who don't
consider any "capability as data" (e.g.
like the wideword capability that I gave:

https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D

) a true "capability" for various reasons including
that it is in principle forgeable (unlike a
descriptor type capability kept in a c-list) and
it doesn't bundle the authority to communicate
to the server (the authority to communicate on
the Internet is "ambient").

I personally think that such "data" capabilities
are enough "capability" that referring to and
treating them as such (e.g. discussing membranes,
revocation, mechanisms like Horton, etc., etc.)
are meaningful.  I also believe that one can
get capabilities as data to be even stronger
capabilities, including the bundling of the
authority to communicate (takes "OS" support),
but now we are getting into implementation
details and speculation.  These points of
strength with regard to any "capability"
implementation can be debated.

You said, "To me it appears that *any* reference
is a cap."  You can of course argue this position,
but for most references your argument will be
quite weak because some of the important properties
of capabilities will be missing or weak.

You might find it interesting to contrast the
general "capability" notion, e.g.:

http://en.wikipedia.org/wiki/Capability-based_security

with the tighter "object capability" model:

http://en.wikipedia.org/wiki/Object-capability_model

You can likely see how people tighten down on
these concepts in an effort to constrain their
properties (though nobody on this list will take
much credit or strongly support the Wikipedia
content in this regard - it's just convenient).

If you just want to challenge for the sake
of argument, what's the point?  I don't think you
will get any takers.  The value of capabilities come
from their properties, the strengths of those properties,
and how they can be used to build systems, not in the
"capability" name.  If you want to just challenge the
name, then you should probably go back and talk to
Humpty Dumpty.  In the mean time I hope I've added
a bit to your information/views about capabilities.

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