[cap-talk] NDAs

[Charles Landau]

On 6/10/09 Toby Murray wrote:
> Ah I see where the disconnect is coming from. By "built" I mean "I can
> build an object that provides this authority". NDA provides this
> authority by performing the actions I described in my previous messages
> in response to being invoked by other objects/processes. 

To summarize: NDA calls Bob repeatedly, giving him a resume capability 
that is the authority (proxied by NDA) to send a message to Carol once. 
I assume NDA's behaviour is fixed and known, so an authority proxied by 
NDA is as good as the direct authority.

> The actual authority that is non-delegatable is the right to invoke
> Carol without Bob being able to intercede. Bob is forced to proxy to
> share the authority that NDA gives him to invoke Carol, which is
> entirely the point.

The unrestricted right to invoke Carol is simply the start capability 
called Carol that NDA holds. It is delegable.

The authority that NDA provides to Bob is the repeated authority to call 
Carol once. (Note that this is not the same as the unrestricted right to 
call Carol. For example, Bob cannot create two threads that call Carol 
in parallel.)

Bob (the person in control of the process designated by the start 
capability named Bob) could delegate this authority by (1) replacing the 
program in his process with a fixed and known program that redelegates 
the use-once capability each time it receives it, and then (2) 
discarding his capability to that process, so he can't modify it again.

Toby Murray wrote:
> On Mon, 2009-06-08 at 11:22 -0700, Mark Miller wrote:
>> > I think the fundamental non-delegatable permission your analysis
>> > relies on is the right to receive messages sent on a given reference.
>> > In systems like Coyotos, Flat Concurrent Prolog, Mach, Joule, or
>> > ToonTalk, channels have two ends (ports, whatever). One represents the
>> > right to place messages into the channel. The other represents the
>> > right to receive (or be invoked by) messages that have been placed
>> > into the channel. Either may be sent in messages, thereby sharing (or
>> > transferring) the right to directly send ot receive. 
>> > 
>> > I do not think you analysis applies to such systems.
> 
> Suppose we have an NDA, whose subject (i.e. the object it gives
> non-delegatable authority to) is Bob and target (the object that NDA
> gives Bob non-delegatable authority to invoke) is Carol. Then I agree
> that if NDA has a reference to the send port of a channel, to which Bob
> has the receive port, then NDA won't work correctly. 

Because Bob can delegate his authority by sharing the capability to the 
receive port. In this case the delegation relies on Bob (and everyone 
else who has a capability to the receive port) giving up his capability 
to the receive port (otherwise, Bob might be able to starve the 
delegee). In my case above the delegation relies on Bob (and everyone 
else who has a capability to his process) giving up his capability to 
the process. I think the cases are not that different. In either case, 
we must rely on Bob to take the correct steps to delegate, after which 
we are not relying on Bob at all.