--MarkM]
Consult the documents posted at the erights site for the details, especially http://www.erights.org/elib/index.html , but here's a simplified version of the Pluribus protocol, identical from a security point of view, but less efficient:
Objects are aggregated together into units called Vats. Each E object exists in exactly one Vat -- we speak of an object being hosted by its Vat, A Vat typically hosts many objects. Each Vat exists on one machine at a time, but a machine may host many Vats. A good first approximation is to think of a Vat as a process (or address space) full of objects, except that it persists. Rather, think of a process as an incarnation of a Vat, but the Vat maintains its identity (and state) as it passes serially thru a sequence of incarnations.
On creation, each Vat generates a public/private key pair. (We're avoiding RSA for patent reasons. We're currently using DSS. Anyone like to contribute an Elliptic Curve implementation?) The fingerprint of the Vat's public key is the Vat IDentity, or VatID. What does the VatID identify? The VatID can only be said to designate any Vat that knows and uses the corresponding private key.
Within one Vat, an object reference (capability) is implemented by a traditional memory address. Capability security within as address space is built out of safe language techniques (made popular by Java, but having a history going back to Lisp 1.5 and Algol 60). An object reference can also go between Vats. On the fundamental diagram http://www.erights.org/elang/concurrency/images/fundamental.gif , if Alice, Bob, and Carol are in three separate Vats, then Alice can talk to Carol only because Alice's Vat can talk to Carol's Vat. An inter-vat data connection is secure and authenticated (+ integrity, defense from replay attacks, etc... Bill Frantz and Eric Messick did great work here). We care about inductive correctness -- assuming a pre-existing secure connection between Alice and Bob, and separately between Alice and Carol, can we establish a similarly secure connection between Bob and Carol?
When Carol's Vat first exported a pointer to Carol across the Vat boundary, Carol's Vat assigned an unguessable randomly chosen number to Carol. We call this a "swiss number", since it has the "knowledge is authority" logic of swiss bank accounts. When Alice's Vat first received the tail of this pointer, Alice's Vat thereby came to know Carol's swiss number and Carol's Vat's VatID.
When Alice gives Bob access to Carol, Alice's Vat tell's Bob's Vat Carol's swiss number and Carol's Vat's VatID. Bob's Vat now wishes to obtain the tail of a Vat-crossing pointer directly to Carol, so that it may deliver this tail to Bob. Bob's Vat first contacts an alleged Carol's Vat (using location routing/hint info beyond this description) and asks it for its public key. It verifies that it matches the fingerprint, ..., you can image the logic from here, through Diffee Hellman, to a shared encryption single-key, Mac, and IVs. *Only* once a secure data pipe is set up does Bob's Vat reveal Carol's swiss number to Carol's Vat.
A capability is an arrow, and an arrow has two sides. There is an imposter problem in both directions. The VatID ensures that the entity Bob is speaking to is the one Alice meant to introduce him to. The swiss number ensures that the entity allowed to speak to Carol is one Alice chose to enable to do so.
Notice how separate this part of the description is from how locations are identified and how data packets are actually conveyed.
Cheers,
--MarkM
