[cap-talk] the "flaw" of separating designation from authority

[Fred Spiessens]

On 25 Oct 2006, at 23:13, Karp, Alan H wrote:

> Your example
>
> 	MyFileSystem.writeFile(fileID: 12345  certificate: Fcert data:
> "XYZ").
>
> shows only one file.  What if the method that implements writeFile
> invokes another method that takes two arguments, the second being a  
> log
> file? Someone could build a system that correctly did
>
> 	MyFileSystem.logWriteFile(fileID: 12345 certificate: Fcert1
> data: "XYZ"
> 			  	        fileID: 67890 certificate:
> Fcert2)
>
> In this case, Fcert1 is provided by the invoker of writeFile and  
> Fcert2
> by the invoker of logWriteFile and the system knows which cert to  
> apply
> to which argument.  However, someone could also build a system that
> incorrectly did
>
> 	MyFileSystem.logWriteFile(fileID: 12345 fileID: 67890 data:
> "XYZ"
> 				        certificates: Fcert1, Fcert2)
>
> Now, the invoker of writeFile could specify fileID 67890 as an  
> argument,
> and the log file will be corrupted.  That's the mistake we made in
> Client Utility.  Of course, the problem with the latter is that we  
> lost
> track of which argument each certificate refers to.

OK, I see, thanks for the explanation.
Yes, loosing the connection between the origin of the designation and  
the origin of the authority will result in confused deputies. When  
programming deputies, the ultimate advantage of capabilities is: that  
you don't have to keep track of this connection yourself.   
Programmers tend to keep track only of the designation (functionality- 
minded as they are), which is probably the reason why, in Client  
Utility, they thought they could get away with combining  
certificates, when they could not be sure that these certificates had  
the same origin (certificates provided in the same invocation may be  
of different origin).

The flaw is not "separating designation from authority" but "losing  
track of the connection between the origin of the designation and the  
origin of the authority".  The former would have indicated a flaw in  
the system, while the latter is a programming error.

The only necessary condition for a system to allow a programmer to  
protect his deputies from being confused is: that authority can be  
passed as an unforgeable reference. The rest can, in principle, be  
taken care of by the programmer (even if his job would have been  
considerably simpler in a capability system).

Again, I do not exclude that other, more important flaws in Client  
Utility style programs, indicate that  real capabilities are  
necessary, but capabilities are not strictly necessary to avoid  
confused deputies (they are just most useful and efficient for that  
purpose, and  make programming much less error prone).

cheers,
Fred.