Re: "Ambient capabilities"

On Mon, Nov 24, 2014 at 12:18 PM, David Nicol <[email protected]> wrote:

> Is that important? Must all method calls include a "by what authority"
> parameter?
>

In object capability model, this parameter is the object reference. Hence,
object 'methods' don't need any "by what authority" parameters. If you mean
'method' in a more general sense of action, then yes, it's important.


> That seems unusable
>

If authority and available actions were loosely coupled, then yes, that
would be unusable.

A major benefit of object capability model derives from its structure,
which tightly couples actions and authority. You cannot even express an
action without also providing the correct authority to perform it (the
object reference). And you cannot grant an authority without providing an
obvious means to wield it. This structure ensures a very high degree for
usability.

It is possible to explicitly decouple these features, e.g. via rights
amplification patterns [1], and sometimes it is useful to do so. However,
the common case remains very usable.

[1] http://erights.org/elib/capability/ode/ode-capabilities.html#rights-amp



rapidly degenerate into a "try everything in my bag" call wrapper
>

There are cases where having a grab-bag of authorities to build an
application can make plenty of sense. This can be modeled even within a
capability system, e.g. as a collection of capabilities each with a little
bit of metadata. This pattern relates to context objects and dependency
injection.

To avoid confused deputy, we must still have many small "bags" rather than
just dumping everything together. And an ability to precisely designate a
specific object rather than a full bag of them remains very useful.


> imagine a system where one prepares to make a method call by requesting
> from the method call preparation service a capability to call method M with
> args A given the authorities in bag B
>

Could be pretty useful. I'm very interested in this sort of 'stone soup
programming' [2], leveraging constraint models to create applications that
accomplish a goal based on available capabilities.

[2] https://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/



When is that safe or not safe?
>

It can be safe if you control what goes into your bag of authorities in the
first place, and the metadata surrounding each authority. For example, we
wouldn't want to confuse an authority for private storage with an authority
for public storage.

It would likely help to use lots of smaller bags, such that you can wrap
each bag with its own metadata, and generally automate computation and
maintenance of the metadata.


> "By the authority of this name resolution capability, I request a
> capability to baz with to-be-determined parameters" could solve it -- there
> is no bag to iterate through. Is that the right way to do it?
>

There is some sense in which every object in conventional OOP can be
understood both as a namespace and as a bag of methods. Acquiring a
capability to call 'baz' in particular from a capability to the bag as a
whole would correspond to the facet pattern [3], an attenuation pattern. I
wouldn't say that's "the right way to do it". But it's probably a right way
to do something.

[3]
http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Facets

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