[E-Lang] Capabilities and XML-RPC

[Mark S. Miller]

At 12:42 PM Sunday 8/12/01, Brandon Wiley wrote:

>Blogger has a new XML-RPC API for posting which is capability-based.
>
>http://plant.blogger.com/api/
>
>This is where my personal interest in capabilities lies, exposing
>capability-based APIs via RPC.

When you say "RPC", I assume you mean remote object invocation?

If you want a capability-secure remote object invocation protocol, well, 
that's sort of the point of all distributed capability systems -- 
implementing the Granovetter operator when Alice, Bob, and Carol may be in 
three different locations  
http://www.erights.org/elib/capability/ode/ode-protocol.html .  The systems 
listed below are only the ones I know to be currently available, in use, or in 
development.  See the citations at the above URL for others.

* E uses such a protocol in the currently shipping 0.8.9.1b release.  An 
improved version of this protocol (with full message pipelining  ), 
described at http://www.erights.org/elib/distrib/index.html , will be in the 
upcoming 0.8.10 release.

* Waterken's system http://www.waterken.com uses a capability protocol 
that follows approximately the same security rationale, a similar but 
different concurrency rationale, and is thoroughly standard based.  The 
capabilities are based on "https:" URLs, the underlying secure data pipes are 
therefore provided by https/SSL, and the encoding format is based on XML-SOAP.

* Mozart http://www.mozart-oz.org apparently plans to go in a similar 
direction as E, though you wouldn't know it from their current web site.

* Toontalk http://www.toontalk.com is a capability-based pervasively 
concurrent language for kids, semantically much closer to E's ancestor Joule 
http://www.agorics.com/joule.html .  (For kids who haven't been corrupted by 
sequential programming, it seems to be easier to teach pervasively 
concurrency than sequentiality, and probably much easier than mixed 
sequentiality/concurrency.)  It's now distributed, with a protocol that 
could easily be made capability secure as well.  However, I don't think the 
protocol is currently publicly documented.

* E-Speak2.2 http://www.e-speak.hp.com/developers/beta22_readme.asp (Alan, 
is this a good URL for 2.2?), is based on distributed "split capabilities" 
http://www.hpl.hp.com/personal/Alan_Karp/publications/keyslocks.pdf .  As 
someone once said of Algol-60, "It's an improvement over most of its 
successors."


Distributed capability protocols that, AFAIK, are not invocation protocols:

* MojoNation http://www.mojonation.net .  (Jim, Zooko, what's a good URL for 
the MojoNation protocol specifically?)

* SPKI http://www.ietf.org/rfc/rfc2693.txt is an almost capability system, and 
is the basis for the production version of E-Speak http://www.e-speak.net/ . 
http://www.erights.org/elib/capability/ode/ode-pki.html explains the sense 
in which SPKI is like a capability system.  http://www.capcert.org explains 
the sense in which it isn't, and takes steps towards proposing how to repair 
the problems.


>This particular implementation is quite crude, but I think that some great
>things can be done in this vein. Using RPC between virtual machines allows
>for good security as objects in different process spaces can't modify
>things in each other's space without going through RPC. If capabilities
>are built directly into the RPC mechanism then you can get security almost
>for free. You just need to codify the methods by which you gain
>capabilities.

I'm glad to see further appreciation for this idea.  Before reinventing the 
wheel, I suggest you see if your goals can be met within one of the above 
frameworks.  If you instead build your own capability-based remote 
invocation system, and if you get serious about security, then please let us 
know, and apply for inclusion in the Capability Security WebRing 
http://nav.webring.yahoo.com/hub?ring=capabilitysecuri .


>Additionally, by using something like XML-RPC you get secure access to
>remote objects in 13 different languages with no additional effort.

Would you not need per-language effort to speak the capability secure 
protocol securely, even if it is based on XML-RPC?


        Cheers,
        --MarkM