Re: [friam] Re: What is a capability?

On Thu, Jan 8, 2015 at 4:53 PM, Kevin Reid <kpreid-M/[email protected]> wrote:

> 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.
>

Agreed.


>
>
> 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.
>

There's nothing fundamental about the selector, although it is certainly
convenient. W7 is an object capability language without selector. The
message consists entirely of the argument list (and possibly the
continuation, depending on the level of abstraction you desire).



>
>
> KeyKOS is not an object-capability system because the way you interact
> with a capability varies depending on the type of the capability.


One of the elements I list as "omitted" is typing, in order to include in
ocaps systems that differ in this way.

Joe-E, Emily, and Safe Pict are statically typed.
W7, Joule, E, and SES are dynamically typed using trademarks.
The KeyKOS restrictions you list below can be modeled as a trademark check,
so I'd include the KeyKOS family as a dynamically typed ocap system.



> 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.
>

If what you mean by rights amplification here includes the trademarking
needed to explain addressable memory, then I'd say that, for ocap OSes, it
is typical.


-- 
    Cheers,
    --MarkM

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk