[cap-talk] Good point, bad design, Sandro - delegation blocking?

Valerio Bellizzomi devbox at selnet.org
Sat Dec 16 17:07:22 CST 2006


On 15/12/2006, at 23.20, Sandro Magi wrote:

>Jed Donnelley wrote:
>> At 06:48 AM 12/15/2006, Sandro Magi wrote:
>> 
>>> Even long-time purchasing agents have a threshold. According to the
head
>>> of accounting, during their ordinary work they shouldn't have to order
>>> say, more than $100,000 worth of parts, so any purchases above that
>>> should be reviewed by someone higher up.
>> 
>> Fine.  As I say, it seems to me we're confusing the delegation of
>> authority at all with re delegation of existing authority.  I'm
certainly
>> not arguing that all authority should be granted without going
>> through human control.  What I am arguing is that once an
>> authority has been granted (e.g. approving purchases under
>> the threshold in your above example), it is counter productive
>> to try to block re delegation of all or part of such authority.
>
>Right, so we're in agreement there as I never meant to imply that.
>
>>> Ok sure, I was sort of talking about the other situation where the
full
>>> authority is not yet granted (training, company policy when lots of
>>> money is involved, etc.). It's an important case to enable
>> 
>> By "it" I take that to be the case of granting limited access and
>> requiring human interaction to get more authority when needed.
>
>Right. I suppose you're seeing it from the authority point of view
>whereas I'm looking at it from the "filter on permission" point of view,
>ie. they have permission to issue purchase orders, but that is filtered
>by a purchase threshold, and you're just saying the purchase threshold
>defines the limit of their authority.
>
>> We're trying to enable POLA access, so of course the case of
>> limited access fits perfectly.  It's the case of blocking delegation
>> of existing access (e.g. re delegation) that doesn't fit.
>
>Right. So the subsequent question that comes to mind: what if the user
>*thinks* they've been delegated an authority but they really haven't.
>For instance, in the above example the purchasing agents think they can
>issue any purchase order until they hit the threshold road block.
>
>In OpenCM's case, suppose it was a capability system where users had a
>semi-transparent forwarder/caretaker that applied a predicate similar to
>the above: checkout and commit are passed transparently, but a
>delegation request is first routed through a third-party for
>authorization (the third-parties being those who currently manage the
>OpenCM groups).

This delegation (or introduction) is somehow a sort of "moderation", are
you saying that delegation must be moderated ?
I can agree that delegation can be moderated, but checkout/commit have to
remain as they are, it would be too frustrating for a developer to wait
for moderation on checkout/commit.

>
>This is fully within the capability model as far as I can see, yet it
>might be a first step to addressing Jonathan's concerns with pure
>capabilities.

Do you mean pure capabilities vs. hybrid systems ?
As I understand, the difference between pure capabilities and hybrid
systems is respectively the absence/presence of some ACL-like mechanism.
Boebert introduced the undefined term "unmodified capability machine", and
Kain and Landwehr have been smart enought to circumvent a debate about the
meaning of the term "unmodified capability machine".
Someday this term will have to be defined.

>
>Sandro




More information about the cap-talk mailing list