[cap-talk] Is "Authority" Subjective?

[Toby Murray]

On Fri, 2007-06-22 at 13:31 -0400, Jonathan S. Shapiro wrote:
> On Fri, 2007-06-22 at 15:48 +0100, Toby Murray wrote:
> 
> > I think my original example was misleading. let me present the same
> > example but with concrete event names to try to show a clearer picture
> > of what I mean here.
> > 
> > Suppose we have 3 objects/subjects/actors/whatever, Alice, Bob and Carol
> > and the system is 
> > 
> > P = aliceInvokesCarol -> carolRespondsToAlice -> bobInvokesCarol -> STOP
> > []
> >     bobInvokesCarol -> STOP
> > 
> > i.e. initially either Alice or Bob can invoke Carol. Once invoked by
> > Alice, Bob can't invoke Carol until she responds to Alice. 
> 
> This may be getting closer, but this is still insufficient. This model
> states what events occurred, but it makes no statements about what
> permissions were required as a precondition for those events.

Thanks for all of the comments so far, Jonathan, it's a good discussion.

I should explain a few things that I've so-far left implicit, to the
detriment of the discussion.

The model on which I'm basing this is the standard semantics for CSP
processes. We presume that our system is modelled as a single process.
The system necessarily comprises a number of
subjects/objects/processes/actors. The process that represents the
system incorporates all possible behaviours of the system, which thus
includes all possible behaviours for each of our subjects.

Of course,  we make  assumptions about the behaviour of some subjects.
the more trusted a subject is, the more assumptions we can make about
its behaviour. THis constrains the different possible behaviours  of the
system and is what ultimately gives rise to the overall behaviour of the
system.

So how do we get a notion of subjects, when our model doesn't have an
explicit notion of subjects built into it? Let me explain.

Our model only has a process that describes the system as a whole. The
process just performs events. As you point out, all we have to go on
then is sequences of events (roughly -- strictly speaking CSP semantics
give us a but more but the details aren't relevant right now). The total
set of events is usually called Sigma. The actions of each subject in
the real system we're trying to model are mapped onto Sigma. For each
subject, we define some subset of Sigma called the subject's /alphabet/.

Hence in the process above, Bob's alphabet is {bobInvokesCarol}.
Alice's alphabet is {aliceInvokesCarol,carolRespondsToAlice}. Carol's
alphabet is {bobInvokesCarol,aliceInvokesCarol,carolRespondsToAlice}.
Each subject's alphabet contains exactly those events that the subject
is involved in.

If the occurrence of events in Bob's alphabet can cause some other event
e to (possibly) occur, then we say that Bob has authority to cause e. 


> Further, this model doesn't have any notion of a system "state" that is
> being updated. If you want to model authority, the interesting issue is
> not whether the event occurred, but what the effect on the system state
> was. Also, it is not important *who* performed the event. It is
> important what event occurred.

We model what effect the event had on other subjects. Otherwise, how can
we measure whether Alice has authority over Bob, for example, if we
can't measure what effect Alice's events have on Bob? We do so by
measuring whether the occurrence of Alice's events can cause Bob to do
anything -- ie. whether the occurrence of Alice's events can cause any
of Bob's events to occur.

We must be misunderstanding one another or talking about different
things with the same words. Of course it's important who performed an
event. If some event, a, happens that causes event b to occur, then all
of the subjects that have a in their alphabet could be said to have
caused b to occur -- hence it is they who have authority to cause b. I
can't see how *who* performed an event is anything  other than
absolutely relevant.

> 
> In effect, what you are describing above is a particular sequence of
> operations that was performed by some underlying operational semantics.
> What you *want* to be describing is the operational semantics and the
> system state that defines the meaning of these events.

Why?  I don't see the necessity. The sequences of actions are enough.
Perhaps see the paper referred to below.

Responding to other things Jonathan has said in this thead:

> the most we can say is that "Alice causes the preconditions to exist
> that might *permit* Bob to invoke Carol".

This is actually what I mean when I've been saying "Alice causes Bob to
invoke Carol". This is close enough for now and is what I'm trying to
answer.


> Assuming you mean subjects (processes) the problem is simple: your
> model
> doesn't have subjects anywhere. If you want to model subjects, you
> need
> to introduce a set of subjects. The resulting model will look very
> different

...

> Alice and Bob cannot be distinct subjects in the model because the
> model
> does not incorporate any notion of subjects. In the absence of a
> notion
> of subjects, there can be no notion of distinct subjects.

See above about subjects being implicit.

If you're interested, I would urge you to check out the paper we're
presenting next month which shows this stuff in action. We accurately
model the confused deputy scenario, including its distinct subjects, and
get expected results with the techniques so far. The case I'm bringing
up in this thread is a corner case that I'm unsure how to handle.

http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/AALPE.pdf
(see in particular Section 5, the theory is contained in Section 4)

I disagree with the notion that the model is not strong enough to admit
reasoning about distinct subjects -- the above paper is the existence
proof that it does.

Cheers

Toby