[cap-talk] How data can you get? A challenge
capability at webstart.com
Thu Jan 18 19:19:43 CST 2007
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?
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
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
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.
More information about the cap-talk