[cap-talk] Derivative rights

[ross mcginnis]

> From: alan.karp at hp.com
> To: cap-talk at mail.eros-os.org
> Date: Tue, 5 Feb 2008 19:35:35 +0000
> Subject: Re: [cap-talk] Derivative rights
>
> ross mcginnis wrote:
>
>> authority to access the file. This is the sole cause of
>> failure in the system. It has nothing at all to do with the
>> use of an identity based control system.
>
> But the only way to copy the letter was to be on the approved list. That's an ACL, and that's the authority that led to the failure. Naming the letter was insufficient to do anything to it. You need the ability to perform some operation. Access rights control operations on object.
>

This could very quickly degenerate into a philosophical discussion about what is a cause.  I'm using the standard scientific usage of the word cause. That is, when you do an experiment you have two versions of a set-up, the set-ups are exactly identical except for one particular feature is changed compared to the other set-up.  If a result is different between the two set-ups then you say the result is caused by whatever it is that it different.  You don't say the result is caused by the set-up. Althought, it is necessary for the particular features of the set-up to be present for the result to occur.
In this case the identity access control is part of the set-up.  The feature varied was the use of a reference(cap).  Thus we say the use of a reference caused the failure.  The identity control is a particular feature of the set-up that does need to be present for the result to occur (but we don't say the identity control caused the failure).

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.

Another example is the web address that Jed Donnelley gave: https://wiki.nersc.gov/bin/view 
Because I know have possession of that reference(cap) I now have the derived right to *attempt* to use the services of the underlying object: ie. I can attempt to read/write to the wiki.  There fact that my attempts will almost likely fail doesn't me that I don't have the right to attempt.  (This distinction is very clear in every day life: eg: here in Australia, Queensland- the police may charge people for attempted break and enter as well as break and enter.)
Now Jed can say that I don't have the authority to read/write, but he can't say that I can't cause a read/write.  All I have to do is pass the web address to someone that will be successfull in their attempt to access the page.  Because it is a password-cap and not an object-cap it is possible for me to pass the web address. If it was an object-cap instead, then I it is quite possible that I wouldn't be able to cause a read/write (it would, of course, depend of the connectivity of the communication network between people who would be successful in their attempt and me). 

ross
_________________________________________________________________
Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT