[Cap-Talk] Is there a capability RFC?

[Mark S. Miller]

[Apologies to those who get this twice.  I'm sending it again because of a 
problem at ietf-calendar@imc.org that should now be cleared up.  I'm keeping 
the rest of you on the addressee list so that replies to this resent message 
will still go to the right places.  --MarkM]


At 06:55 PM Monday 7/9/01, David L. Nicol wrote:
>[...] it occurs to me that a Standard Capability Protocol [...]

The rest of you message shows that you're not thinking of a protocol, but 
rather a standard representation for distributed capabilities that can be 
carried or stored in conventional non-capability media.  Let's call this an 
off-line capability representation.

For off-line capabilities in support of off-line protocols, start with SPKI:

* SPKI http://www.ietf.org/rfc/rfc2693.txt is approximately a capability 
system, as explained at 
http://www.erights.org/elib/capability/ode/ode-pki.html .  It fall short of 
being a capability system in the ways explained at http://www.capcert.org/ , 
especially http://www.eros-os.org/pipermail/e-lang/2000-October/003886.html .
HP's E-Speak system started as a capability system (actually, a "split 
capability" system, an interesting variant).  But starting with E-Speak 3.0, 
they are using SPKI certificates as if there are capabilities.

* If you're looking for a SPKI-like system, but not broken, keep your eye on 
http://www.capcert.org/ .  But don't expect to see anything happen there for 
at least a year.

For off-line capability representations in support of on-line capability 
protocols, there are two.

* Take a look at E's "cap://..." URI string.  E ( http://www.erights.org/ ) is 
already a very well functioning prototype or better, and should be ready for 
production use within a year.  The corresponding on-line protocol it 
supports is Pluribus 
http://www.erights.org/elib/capability/ode/ode-protocol.html , 
http://www.erights.org/elib/distrib/vattp/index.html , and 
http://www.erights.org/elib/distrib/captp/index.html .

* Waterken ( http://www.waterken.com/ ) has a very clever way to encode 
essentially the same information as E's "cap:.." URI into an "https:.." 
string, and then to layer their protocol on top of https.  It looks solid to 
me, and all the critical parts are open sourced.



        Cheers,
        --MarkM