[Cap-Talk] Is there a capability RFC?
Mark S. Miller
Tue, 10 Jul 2001 16:18:59 -0700
[Apologies to those who get this twice. I'm sending it again because of a
problem at firstname.lastname@example.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/distrib/vattp/index.html , and
* 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.