[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] [cap-talk] Regarding AMQP Messaging paradigm and
From:       Kevin Reid <kpreid () mac ! com>
Date:       2010-04-05 23:42:01
Message-ID: 05608418-C524-4AB1-A42F-1C4CFAB5E911 () mac ! com
[Download RAW message or body]

[Please note crosspost by the original author and me; I propose that  
further discussion go to cap-talk unless it is E-specific.]

On Apr 5, 2010, at 17:14, Yuvaraj Athur Raghuvir wrote:

> In Capability based systems (OCAP), the management of capability is  
> through explicit exchange of reference - the Granovetter diagram.  
> This defines a point-to-point interaction model. In the world of  
> messaging, this point-to-point seems to be one case of the possible  
> many. Further, it is now becoming important that the messages are  
> delivered not on a destination specification but on a pattern based  
> specification of the destination. This allows for time independence  
> of message creation and delivery.
>
> Since the AMQP decouples the publisher via the exchange and the  
> consumer via the queue, and manages the relation between the  
> exchange and queue via binding, I wonder what would be the  
> corresponding security pattern in E-Language. In particular, how to  
> create a binding between the exchange and queue so that the security  
> paradigm is not violated?


Think about 'being a capability system' as a sort of mathematical  
structure: it has a set of axioms, and given some definitions the  
axioms hold for a given instance (capability system) or not.

Then we can ask, not 'Is this a capability system', but 'What part of  
this is a capability system?'

There are two perspectives one can take on message-passing subsystems  
like AMQP:

1. As component of capability system.

Imagine an AMQP implementation running on top of a capability OS or  
VM; consider the 'exchange' and 'queue' (I have only briefly read  
about AMQP) as objects inside a capability universe. They receive and  
send low-level messages, each having its Granovetter diagram, in order  
to implement the AMQP protocol at a higher level. The AMQP  
implementation then cannot violate the capability universe, as it  
exists within it.

Given this perspective, the question is whether AMQP *is a useful  
abstraction*  to a capability programmer: are the particular  
characteristics it has what you want?

Answering this question tells you whether you can use AMQP as a  
component of a capability-structured application.

2. As substrate of capability system.

This is attempting to write capability-structured applications on top  
of AMQP. The question here is: does AMQP have the capability  
properties? For example, does it deliver messages only to recipients  
which were either designated by the sender or previously exercised  
permission to listen to some queue/hub/buffer/whateveryoucallit? Does  
it permit any participant to delegate authority to any other (that it  
has been introduced to)? (This can be worked around by forwarding  
proxies, but is undesirable for performance and robustness.)

Given this perspective, the question is whether AMQP can be viewed as  
a capability system - is doing so a *completely non-leaky*  
abstraction? Perhaps only some subset can be so viewed -- if so, does  
use of the excluded portion potentially violate the capability  
programmer's invariants?

Answering this question tells you whether you can write capability- 
structured applications using AMQP as a general message-passing layer  
for the entire application.

----

Using a message-passing system in *either* of the roles above has some  
general requirements: the most significant one I can think of is that  
all *identifiers* of objects which may carry authority must be:

  1. unforgeable - they are either opaque object references or they  
sre cryptographically strong (having enough random bits).

  2. undiscoverable - third parties should not be able to get a list  
of all the identifiers in the system.

----

I hope this helps. Please note that I know no more than two minutes'  
research on AMQP, and that I am not an expert in capability systems or  
their taxonomy and terminology in general.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>




_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]