[cap-talk] Reinterpreting POLA - "Authority Must Not Exceed Trust"

Ka-Ping Yee cap-talk at zesty.ca
Mon Sep 17 17:38:11 EDT 2007


On Mon, 17 Sep 2007, Toby Murray wrote:
> On Mon, 2007-09-17 at 18:18 +0100, David Hopwood wrote:
> > There are at least two problems with this:
> >
> > 1. This criterion is based on a stakeholder being able to make an accurate
> >    trust assessment for every component that they depend on. It assumes that
> >    each stakeholder has sufficient information and competence to make this
> >    assessment. But they very often don't.
>
> I don't follow. If a stakeholder has insufficient information, surely
> the only correct decision is to not trust the subsystem and, hence, be
> willing for it to wield almost zero authority. That's the point of my
> definition.

I think it the ideas from the "Actor-Ability Model" might be helpful in
this discussion.  (http://www.cs.berkeley.edu/~pingster/sec/uid/#state)

The basic idea is that the user's mental model contains a number of
actors and a set of abilities each actor has.  These actors and
abilities may or may not correspond to software abstractions (e.g.
modules, objects, processes) -- what matters is the mental model.

Two constraints follow from this concept:

  - One of the actors is the user himself/herself.  This actor must
    in real life have *at least* the abilities the user expects.

  - All other actors must in real life have *no more than* the
    abilities the user expects.

The design principles that follow from these constraints are:

 1. The user has to take an action to grant new abilities to other
    actors.  (This prevents other actors from exceeding their
    expected abilities.)

 2. The user has to have a way to review the abilities of other
    actors.  (This relieves the user of an unrealistic memory burden.)

 3. The user has to be able to revoke the abilities of other actors.
    (This prevents abilities from growing without bound.)

 4. The user has to be kept aware of what the user can do.
    (This prevents the user from making an invalid commitment.)

Does this help?


-- ?!ng


More information about the cap-talk mailing list