[cap-talk] How data can you get? A challenge

[Jed Donnelley]

At 10:23 AM 1/18/2007, John Carlson wrote:
>Jed, this isn't taking your challenge, it's merely
>commenting on "how data" something can get.
>-----------------
>invoke what?  A sentence is data with a verb in it.
>
>I'm not sure there's ever going to be an entirely
>declarative full protocol, language, or what have you.
>UML and OCL?  I'd like to see more working examples.
>
>If you're trying to achieve the "key" metaphor,
>try creating a lock with pure data.  The lock
>is part of the object-capability system as well.
>
>What's the difference between this and an HTTPS POST,
>given you are using client side certificates?
>
>John

Hi John.  I'm not quite sure how to answer your question.
There is a lot of context in this area on the list, and in some
ways I'm feeding into those past discussions.

However, perhaps it would be useful for to put my challenge
into context in terms of the work we're doing on the Wikipedia
page:

http://en.wikipedia.org/wiki/Object-capability

What I'm arguing is that the mechanism I proposed has
all the "object-capability" properties in a distributed system
in which capabilities (references) appear as data in the
memory spaces of active objects (processes) and of course
serially as data going across the wires.  So I'm claiming
all these properties:
_____________________________
     * Objects are both accessed and designated through unforgeable references.
     * Computation is performed by sending messages along these 
references to objects.
     * A reference to an object can be obtained by:

    1. initial conditions (the system starts up with a set of objects 
that may have references to each other)
    2. parenthood (the creator of an object has access to the created object)
    3. receiving a message (objects can embed references in the 
messages they send)

In a pure object-capability system, all computation is performed by
objects that follow these rules, and these are the only ways that
objects can access each other and obtain access to each other.
______________________________

With regard to your question about HTTPS POST with a client side
certificate (assuming of course also a server side certificate) I think the
key difference is the need to communicate object references (capabilities)
in the messages.  Messages can contain data of course (a topic that we
seem to be waiting for a detailed language level resolution before clarifying),
but they must also be able to contain object references to allow delegation
to provide the value we look for from the object-capability model.

It's important that only capabilities (object references) enable communication

(now that I look for it, that notion may be implicit in the Wikipedia
description, but it doesn't seem to me to be explicit enough to make
it clear)

and that the only way to directly get more object references is to receive
them in a message.

Meet those simple requirements and you've got an object-capability
mechanism in my book.  There's been some debate on this list about
whether or how distributed systems can achieve such functionality
(though the DCCS was accepted) and whether capabilities as data
mechanisms (where capabilities can be stored in the memory of
an active object/process and not in a separate "c-list" as a
descriptor) can provide all the needed object-capability features.

Note that for this challenge I'm not addressing performance.
The costs of some or all cryptographic implementations might
be too high for practical use.  At this point I'm just interested
in functionality with the assumption that the usual conditions
for cryptographic safety (unguessability) have been achieved.