Re: What is a capability?
Kevin Reid <kpreid-M/[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
On Jan 8, 2015, at 14:38, Karp, Alan H <[email protected]> wrote: > I'd like to make sure that we're not conflating object capabilities with capabilities, because I think there is a distinction. An ocap denotes an object and authorizes invocation of all that object's methods. If you want to authorize less, you create a new object with fewer methods that acts as a forwarder. In KeyKOS, if I understand correctly, a capability denotes some object and has bits specifying which method invocations are authorized. We did something similar in Zebra Copy; the SAML authorization assertion denotes the service and lists the authorized methods. Further, with ocaps you must set up a caretaker before delegating if you want separate revocability. I don't know about KeyKOS, but that's not the case with Zebra Copy. I believe this is not the proper distinction. Revocability-by-default of individual objects is a semantic choice independent of whether the system qualifies as a capability system. And as MarkM said, the permission bits are an implementation detail of particular capabilities. This is what I think of as the difference, and I hope MarkM would agree: A capability system is one which has the laws of locality, designation-and-authority-are-not-separated, etc. An object-capability system is a capability system in which the primary operation on a capability is "send a message", the message has a "selector"/"method name"/"verb" field, and all capabilities are on an equal footing in this way. And, more subjectively, the capabilities correspond to objects in an object-oriented programming language. KeyKOS is not an object-capability system because the way you interact with a capability varies depending on the type of the capability. For example, if my understanding is correct, capabilities to memory pages are never interacted with by sending messages to them, but rather by inserting them in page tables. Start keys are more ocap-ish, since they are implemented by application code, but (I am assuming) there is no expectation of any commonality of protocol or a notion of "selector" between different start keys. Obviously one can design a protocol within an object-capability system in which its clients never send messages to certain objects (i.e. those objects are given to other objects which internally use rights amplification patterns), but that is not the _typical_ case. -- Kevin Reid <http://switchb.org/kpreid/>