[And my reply to him]
> So my question: Is a capability that which encapsulates or the
> encapsulated. Is a ticket/key the capability or the container?
It depends on what type of capability system you are using.
To first order, the ticket/key is the capability.
If, however, your system uses password-protected capabilities, and if the validation of such a capability results in a cached system-level capability that is the one you really use, then I would argue that the ticket was a reference to the capability.
This is probably a nit. For practical purposes, the ticket is the capability in either system and the cache is just a cache.
> "Capabilities are protected names" - hardy
> http://www.mediacity.com/~norm/CapTheory/What.html
By "protected", Norm means that they are unforgeable. In this context, he spoke incompletely, neglecting the fact that a capability also authorizes a set of operations. I'm pretty sure he would agree that this is a significant omission, but see what he says.
> "Capability - A protected pointer or name, implemented with bits but
> situated so that the holder and user lacks access to those bits...
> http://www.mediacity.com/~norm/CapTheory/Glossary.html
This definition is incorrect, as it excludes password capabilities and neglects operations. Norm will argue that the bits he meant to speak of were the decrypted bits, but the definition as written is ambiguous and therefore inaccurate.
A capability is more than a name. It is a (name, {operation*}) pair.
shap