[e-lang] [cap-talk] Non-Delegatable Authorities in Capability Systems

Toby Murray toby.murray at comlab.ox.ac.uk
Wed Dec 12 21:23:22 EST 2007

Thanks again for the clarification.

(This message is being cross-posted to e-lang, since some of its content
is most relevant there. Direct replies accordingly.)

In order to get the paper back onto a solid foundation, while ensuring
it requires as little modification as possible (since it went through
two rounds of review before being accepted), I think the right thing to
do is to define a subset of E that /does/ enforce the (stronger)
non-delegatability-of-returns property and state that we are using that
subset for code examples. Then amend the comments about E enforcing
non-delegatability-of-returns and cite an example like Joe-E instead.

I'm not absolutely convinced that "(delegatable) single-use return
capabilities" is strong enough, since with these, Bob can share in a
manner not equivalent to proxying, since he doesn't get to vet the
invocation that is going to be performed. 

I'm hoping you can help me define a suitable subset of E that does
enforce the stronger non-delegatability-of-returns property, which also
includes the subset of E that we've used currently in the paper (as
described in the Appendix).

The property that I'm after is that, when A invokes B, that B always has
the final say about the results returned to A.

At first glance, it appears that one needs to disallow (at least) the


and stipulate that each vat runs a single turn only (in order to cover
the case you pointed out in which one delegates a resolver and returns
the corresponding promise). 

Would that be enough?


On Mon, 2007-12-10 at 17:16 -0500, Kevin Reid wrote:
> >> Minor comment: I expect that the actual results in a "buggy  
> >> delegator" scenario depend on the exact mechanism used for  
> >> upgrading the buggy program (what level of the system is  
> >> replaced); i.e. the examples, containing no upgrade hooks, are  
> >> unrealistic. Some upgrade hooks might defeat the no-delegation-of- 
> >> future-replies property.
> I'd like to call your attention to this; any upgrade mechanism will  
> either involve some sort of interposition, thus adding a potentially- 
> problematic (depending on its design) layer to the semantics you're  
> concerned with, or will involve restarting a vat with new code, and  
> therefore be necessarily the distributed case.

I see what you mean and agree that the scenario, as currently put, is
totally contrived. That said, the paper is more concerned with whether
one can express non-delegation at all, and (perhaps cowardly) sidesteps
the issue of whether the NDA implementation would be practically
applicable in real software. I tend to believe that perhaps
non-delegation is unnecessary in real software. However, conventional
wisdom tells us that one cannot express non-delegatability in any
capability system. It is this point that the paper is really trying to

More information about the e-lang mailing list