[E-Lang] Other languages with secure capabilities

[Mark S. Miller]

At 01:13 AM Wednesday 5/9/01, Peter Van Roy wrote:
>I agree completely.  In fact, we used the same argument when designing
>the protocols to make Oz network transparent.  Objects in Oz are mobile
>by default (object state moves to process using it).

While it may be the same argument in a different context, I fear that this 
argument has led you to a security-incompatible solution.  Unless you mean 
something very different by "object", then among mutually suspicious nodes 
objects must by default be stationary.  Further, non-stationary objects should 
not be considered mobile, but replicable.  For both, money is a great example.

Many people have misread the MintMaker example 
http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
as involving non-stationary Purses.  Of course, our code doesn't work 
under such an assumption.  But it's an interesting exercise.  If you believe 
in distributed object-based capability security among mutually suspicious 
nodes, and you believe that these secure objects can be non-stationary, then 
try to write a MintMaker equivalent in which the Purse-equivalents move to 
the machine of the client holding the Purse.

As to "mobile" vs "replicable", if you could truly implement an object, 
designatable by a capability, that could change its host, but have all 
designators know to go to the new host instead of the old one, then you 
could implement the Holy Grail of money protocols: A money without an 
issuer.  A dollar (or whatever) could just be a mobile object, the current 
owner of the dollar would be according to the current hosting machine, and 
the dollar would change hands by moving between machines.  If you instead 
concede that double spending cannot be prevented without a stationary 
issuer, then non-issuer-managed objects are stationary or replicable, 
but not mobile.


>The assumption of mutually trusting nodes is not a profound one; it is
>part of our current plans of progressively introducing implementation
>security in Mozart.  The very first step is allowing encrypted
>communication.  This handles the mutually trusting nodes case, which is
>actually an important special case.

You may be able to implement security incrementally, but I doubt you could 
architect security incrementally.  Is there anything to read about Oz's 
planned security architecture?


>Well, I do enjoy the discussions on the E list, even though I can't read
>them all in detail.  Seif Haridi can probably respond better to your question
>than I.

I look forward to it.

>> Btw, to whom should I send an invitation to put Oz on the Capability
>> Security WebRing?
>
>Send it to users@mozart-oz.org, the interested Mozart developers will
>respond.

Good.  Done.  Looking forward to seeing you folk on the ring!



        Cheers,
        --MarkM