[E-Lang] Capabilities and XML-RPC

[Karp, Alan]

Mark Miller wrote:
>
> 
> * 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."

Kind words, indeed.  Unfortunately, with e-speak's move to HP's Middleware
Operation, the old links have been removed.  The open source site still has
the documents, though.  http://www.e-speak.net/library/library_white.html is
your best bet.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, August 13, 2001 8:59 AM
> To: Brandon Wiley
> Cc: E Language Discussions
> Subject: Re: [E-Lang] Capabilities and XML-RPC
> 
> 
> 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

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang