[cap-talk] Derivative rights

[Jed Donnelley]

On 2/5/2008 1:54 PM, Karp, Alan H wrote:
> ross mcginnis wrote:
>> Naming the letter does give you the authority to perform some
>> operation.  It gives you the authority to *attempt* to copy
>> it.  This is a derived right that the mere possession of the
>> letter name produces.  Depending on who is holding the letter
>> the attempt will be successful.  Mallory manipulates the
>> situation so that the person attempting to copy it is
>> successful in the attempt.
>>
> I'm getting lost in the analogy.  Let's revert to code.
> Let's say that you can guess that I have a file named
> "/usr/karp/mypasswords".  I will run programs for you,
> and you may pass parameters to those programs.  However,
> the programs I will run for will only operate on files
> if given open file handles.  In other words, the programs
> I run on your behalf never do an open operation.  Write a
> program that invokes one of these programs in which the
> filename you have correctly guessed is treated any
> differently than an arbitrary string.  I'm sure you 
> wouldn't claim that an arbitrary string is a capability.
> My question is why you would treat an arbitrary string
> that may happen to be the same as a filename as a capability.

The above (which I agree completely with) I think
gets to the sense I was trying to convey of
essentially how much some thing (a token that
can be sent in a message) can be considered
a "capability".  You may present arguments
that some tokens (e.g. the text string
"/usr/karp/mypasswords" as above) "really are
capabilities!", but in the end your arguments
must depend on just how strongly such
tokens meet the capability criteria.

"/usr/karp/mypasswords" is both easily
forgeable and conveys negligible authority.
It's not a capability any more than:

https://wiki.nersc.gov/

is a capability.  Fundamentally not at all.

If you wanted to redefine our lexicon so that
such strings would be considered capabilities,
what would the point be?  It seems to me that
it would only lead to confusion.  People would
look at those strings and say, "What, that's
a capability?  I thought a capability had
to be unforgeable and convey some authority?"

They would be right to reject the above as
"capabilities".

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