Re: Object Capability model for IoT

A few more thoughts:

I'm currently developing a capability secure, streamable bytecode and
language for open distributed systems, and the ability to serialize code
(including capabilities) is an important part of this. So all capabilities
are formally represented as strings, serialized in bytecode with
{capability text between curly braces}. Favoring cryptographic capability
text is useful to protect open or distributed systems against external
attacks.

Capability text cannot be forged or observed from within my language, and
hence there is no overhead for capabilities that never leave the machine -
the capability text can be lazily generated. It turns out (interestingly,
IMO) that a common case for lazy generation is when performing JIT
compilation of closures.

An interesting feature for capabilities represented as strings is that the
strings can have some conventional meanings or interpretations. For
example, I use a few conventions:

     {&annotation} - annotations are prefixed with `&` and have type a→a
     {#secure hash} - inline the bytecode resource identified by secure hash
     {:sealer} and {.sealer} - discretionary sealing (similar to type
wrappers)

E language typically models sealers using stateful mechanisms. I use
capabilities, but favor purely functional representations for sealed
values. It seems feasible to use value sealing to guide automatic
encryption. Annotations can be used for debug output, performance hints
(e.g. parallelization, dynamic compilation), and other things, but can also
be removed or ignored without affecting the meaning of the program. Secure
hash resources serve as my basis for linking, loading, and separate
compilation - in a manner compatible with streaming and open systems and
distributed hashtables.

IMO, there are a lot of advantages of using arbitrary strings for
capabilities, as - in addition to supporting easy serialization - it allows
development of simple, flexible, and useful conventions that are meaningful
across runtime instances.

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