Re: Access Control

Yes, I largely agree. However, I had previously considered the option of a
cron job but then was uncomfortable that this would mean that the security
of the system depends on the security and reliability of the cron daemon.
(Could a rogue system administrator temporarily disable cron in order to
preserve existing privileges long enough to allow a co-conspirator to do
something bad?) Relying on cron seems a bit fragile to me, but I do accept
that it is a potential, although perhaps risky, solution to Alice's problem.

bob wyman


On Mon, Aug 25, 2025 at 1:03 PM Alan Karp <alanhkarp@gmail.com> wrote:

> I updated the delegation section to include the hazard of expensive
> mechanisms.  Does the following capture your thinking?
>
> Yet another hazard is the need to enforce complex policies.  Mechanisms
> that are too inconvenient or that cost too much in time or resources are
> unlikely to be used.  Say that Alice wants a delegation to be valid only
> during business hours.  That policy is unlikely to be enforced if Alice
> must manually issue or revoke the delegation at each change.  Automation
> is commonly used to mitigate this problem.  For example, Alice can set up
> a cron job to make the changes to the ACL.
>
> --------------
> Alan Karp
>
>
> On Sat, Aug 23, 2025 at 8:34 AM Bob Wyman <bob@wyman.us> wrote:
>
>> Alan,
>> You wrote: "I should have focused on the hazards rather than the
>> mechanisms."
>> I think that when considering the hazards inherent in various mechanisms,
>> we need to evaluate not only technical risks, but also economic risks. And,
>> we should be aware that whatever may be the virtues of alternative
>> mechanisms, if the economic cost of their use is high enough, the real
>> "hazard" is that no mechanism will be used.
>>
>> When evaluating technical risks due to a mechanism's design, we normally
>> make the dangerous assumption that implementations of the mechanism's
>> components and dependencies will operate as designed. Some risks will be
>> inherent to the design of the mechanism itself. (e.g. Composition has
>> issues that we've touched on.) However, an important class of risks are due
>> to the inevitable fragility of systems' implementations. We are all too
>> well aware that essentially all systems can be hacked or circumvented.
>> (e.g. Any system that relies on the difficulty of breaking some crypto
>> algorithm is exposed to the risk that someone will make the economic
>> decision that it is worthwhile to spend sufficient resources to overcome
>> the difficulty.)
>>
>> Economic risks often dominate the risk horizon. Cumbersome systems, even
>> if technically well designed, are often not used. It is probably Alice's
>> desire to avoid the cost of having Bob forward long lists of proposed
>> actions to her that motivates her to empower Bob, via delegation, to act on
>> his own. But, while avoiding the cost of serving as Bob's proxy, Alice
>> accepts the offsetting risk that Bob will do things that she's unaware of
>> or of which she would not approve. Nonetheless, she may accept the costs
>> associated with delegation if they appear to be "acceptable." Delegation
>> might not be perfect, but for Alice it may be good enough and "cheaper"
>> than any alternative. Others might evaluate the tradeoffs differently.
>>
>> The really big problem arises when the economic cost of the available
>> mechanisms is so high that no mechanism will be employed. For instance,
>> while Alice may wish that her 1,024 international employees only have some
>> capability during their assigned working hours, the economic cost of Alice
>> making thousands of delegations and revocations each day is likely to be so
>> high that, unless an automated mechanism is available, Alice simply won't
>> even attempt to implement her desired policy. In this case, the hazard and
>> risk is that no mechanism will be used to address the problem. Of course,
>> Alice might regret her tradeoff analysis on the day after some employee
>> goes rogue after-hours...
>>
>> So, I think the hazards (costs) evaluated should include both technical
>> and economic costs and risks. We must be aware of the risk that even
>> well-designed mechanisms will either not be used or will be circumvented if
>> they are cumbersome (i.e. have high economic cost).
>>
>> bob wyman
>>
>>
>>
>> On Fri, Aug 22, 2025 at 6:50 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>
>>> You're right.  I used the wrong criterion.  I should have focused on the
>>> hazards rather than the mechanisms.  The question I should have asked is if
>>> the example introduces a new hazard.  Relying on existing mechanisms was a
>>> poor way of deciding.
>>>
>>> Most, if not all, of your examples can be handled by the verifier, the
>>> PDP for those of you in the know.  Nothing says the verifier can only look
>>> at the authentication for ACLs or the certificates for capabilities.  It's
>>> free to include whatever additional information it needs, such as whether
>>> the US is at war with Canada.  (That used to be funny.)
>>>
>>> While the verifier is part of the access control system, Cedar shows it
>>> is possible to enforce complex policies without specialized code.  That
>>> means examples such as blocking certain compositions don't represent new
>>> hazards; they just need to be included in the policy.  On the other hand,
>>> the verifier can't deal with the confused deputy example.  It sees a
>>> legitimate request from Bob but has no way to know Bob made that request
>>> because Alice asked.  That makes it a hazard.
>>>
>>> As your list demonstrates, there's an unbounded set of policies.  We
>>> certainly don't want to include a specific mechanism in our design for each
>>> one of them.  Instead, we want our access control system to deal with cases
>>> that the verifier may not see, such as delegations, or that can't be
>>> expressed as policies, as with the confused deputy.  Which of your examples
>>> do that?
>>>
>>> Thanks for the insightful comments, Bob.  They've helped me clarify my
>>> thinking.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>> On Fri, Aug 22, 2025 at 1:59 PM Bob Wyman <bob@wyman.us> wrote:
>>>
>>>> Alan,
>>>> You wrote: "The question is whether the policy introduces a new hazard
>>>> or *if it can be enforced with an existing mechanism*"
>>>>
>>>> I think this constraint (i.e. "enforced with an existing mechanism")
>>>> needs a bit more elaboration. Isn't delegation largely a convenience which
>>>> could be enforced with an existing mechanism?  It seems to me that the
>>>> effect of delegation could be provided by having delegatees simply send
>>>> messages to the object owner, asking the owner to perform the desired
>>>> actions. (e.g. Instead of Alice delegating to Bob, she could tell Bob to
>>>> send her a list of commands that Alice would then issue herself and
>>>> then forward the results to Bob. This "existing mechanism" would be
>>>> effective, but would be terribly cumbersome.)
>>>>
>>>
>>>> Similarly, as you suggest, Alice could delegate each day to Bob at the
>>>> start of Bob's work day and then revoke that delegation at the end of Bob's
>>>> work day. However, that would require Alice to get to work each day before
>>>> Bob does and to stay at work until after Bob's work day ends. Of course, if
>>>> she were the manager of an international organization with hundreds of
>>>> members, she might be doing dozens of delegations and revocations at every
>>>> hour of the day, every day. While cumbersome, this is an "existing
>>>> mechanism" that is technically feasible, although not very practical.
>>>>
>>>> Rather than using your somewhat ambiguous definition of policy, I think
>>>> it might be useful to distinguish between two classes of states or
>>>> conditions:
>>>>
>>>>    - Things that can be detected by a machine (i.e. time of day, use
>>>>    of user account, existence of intruder threat, outside temperature,
>>>>    employee database status, etc.)
>>>>    - Things that can only be detected by people, or that rely on
>>>>    judgements made by people. (i.e. personhood, trust,  assessed competence,
>>>>    etc.)
>>>>
>>>> It seems to me that an ideal access control system would be able to
>>>> handle an arbitrarily complex set of machine-detectable states and
>>>> conditions while we have no choice but to insist that only humans do those
>>>> things that only humans (or their AI proxies?) can do. Now, I'll admit that
>>>> one might wish to distinguish between an "ideal" access control system and
>>>> a "practical" or implementable system... But, it is often good to
>>>> understand the ideal before deciding how much less than ideal is one's goal.
>>>>
>>>> bob wyman
>>>>
>>>>
>>>>
>>>> On Fri, Aug 22, 2025 at 12:52 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>>>
>>>>> On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>
>>>>>> So, if policy determines "how those permissions get assigned," but
>>>>>> not the permissions themselves, then I assume that the following use cases
>>>>>> would not involve policy:
>>>>>>
>>>>>
>>>>> The question is whether the policy introduces a new hazard or if it
>>>>> can be enforced with an existing mechanism.  I'm not saying that what I
>>>>> suggest below is the best or even a good way, just that the mechanism can
>>>>> enforce the policy.   The "verifier" I talk about below is the component
>>>>> that makes the access decision based on Bob's permissions and his request.
>>>>>
>>>>>>
>>>>>> After following some written policy guidelines, Alice delegates to
>>>>>> Bob, but the delegated permissions she provides are constrained to work:
>>>>>>
>>>>>>    - Only for the two-weeks that she's out on vacation.
>>>>>>
>>>>>> Alice delegates to Bob before she leaves and revokes when she returns.
>>>>>
>>>>>>
>>>>>>    - Only between the hours of 6pm and 9am during weekdays which are
>>>>>>    workdays.
>>>>>>
>>>>>> Alice delegates to Bob at 6 PM and revokes at 9 AM on every work
>>>>> weekday.
>>>>>
>>>>>>
>>>>>>    - Only if Bob has received a complimentary delegation from Dave.
>>>>>>    (i.e. composition required)
>>>>>>
>>>>>> Alice asks Dave what he delegated to Bob before she delegates to Bob.
>>>>>
>>>>>>
>>>>>>    - Only if Bob can't compose Alice's delegation with any other
>>>>>>    delegation. (i.e Bob can't do anything Alice couldn't do.)
>>>>>>
>>>>>> The verifier can enforce this policy.  (This approach is used in
>>>>> consulting firms to implement a Chinese Wall between employees doing work
>>>>> for competing clients.)
>>>>>
>>>>>>
>>>>>>    - Only a maximum of three times
>>>>>>
>>>>>> Alice tells the verifier to tell her each time Bob uses the
>>>>> permission and revokes after the 3rd use.
>>>>>
>>>>>>
>>>>>>    - Only a maximum of three times during any 24-hour period
>>>>>>
>>>>>> Ditto
>>>>>
>>>>>>
>>>>>>    - Only while the intrusion detection system is reporting a
>>>>>>    suspected intruder.
>>>>>>
>>>>>> The verifier can enforce this rule.  (This approach is used in Risk
>>>>> Adaptive Access Control.)
>>>>>
>>>>>>
>>>>>>    - Only when the outside temperature is above 99 degrees.
>>>>>>
>>>>>> Ditto
>>>>>
>>>>>>
>>>>>>    - Only if Bob's continued employment by Alice's employer can be
>>>>>>    confirmed.
>>>>>>
>>>>>> Bob gets permission to invoke Bob-agent, and any delegations are to
>>>>> Bob-agent.  You revoke Bob's permission to invoke Bob-agent when he leaves
>>>>> the company.
>>>>>
>>>>>>
>>>>>>    - Only if Bob uses the permissions to manipulate one or more of
>>>>>>    an enumerated list of objects.
>>>>>>
>>>>>> The delegation only gives Bob permission to the enumerated list of
>>>>> objects.
>>>>>
>>>>>>
>>>>>>    - etc.
>>>>>>
>>>>>> I agree that policies like these are important considerations, but do
>>>>> they introduce hazards that I didn't cover?  If so, then I should add use
>>>>> cases for them.
>>>>>
>>>>> --------------
>>>>> Alan Karp
>>>>>
>>>>>
>>>>> On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>
>>>>>> So, if policy determines "how those permissions get assigned," but
>>>>>> not the permissions themselves, then I assume that the following use cases
>>>>>> would not involve policy:
>>>>>>
>>>>>> After following some written policy guidelines, Alice delegates to
>>>>>> Bob, but the delegated permissions she provides are constrained to work:
>>>>>>
>>>>>>    - Only for the two-weeks that she's out on vacation.
>>>>>>    - Only between the hours of 6pm and 9am during weekdays which are
>>>>>>    workdays.
>>>>>>    - Only if Bob has received a complimentary delegation from Dave.
>>>>>>    (i.e. composition required)
>>>>>>    - Only if Bob can't compose Alice's delegation with any other
>>>>>>    delegation. (i.e Bob can't do anything Alice couldn't do.)
>>>>>>    - Only a maximum of three times
>>>>>>    - Only a maximum of three times during any 24-hour period
>>>>>>    - Only while the intrusion detection system is reporting a
>>>>>>    suspected intruder.
>>>>>>    - Only when the outside temperature is above 99 degrees.
>>>>>>    - Only if Bob's continued employment by Alice's employer can be
>>>>>>    confirmed.
>>>>>>    - Only if Bob uses the permissions to manipulate one or more of
>>>>>>    an enumerated list of objects.
>>>>>>    - etc.
>>>>>>
>>>>>>
>>>>>> bob wyman
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 21, 2025 at 8:34 PM Alan Karp <alanhkarp@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>
>>>>>>>> Alan Karp wrote:
>>>>>>>>
>>>>>>>>> "Policy is a topic I chose to avoid."
>>>>>>>>
>>>>>>>>
>>>>>>>> How is "policy" distinguished from access control?
>>>>>>>>
>>>>>>>
>>>>>>> Policy decides who gets which permissions when.  Access control is
>>>>>>> how those permissions are represented and used.
>>>>>>>
>>>>>>> For example, an ACL is an access control mechanism that represents
>>>>>>> permissions but it says nothing about how those permissions get assigned.
>>>>>>>
>>>>>>> --------------
>>>>>>> Alan Karp
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>
>>>>>>>> Alan Karp wrote:
>>>>>>>>
>>>>>>>>> "Policy is a topic I chose to avoid."
>>>>>>>>
>>>>>>>>
>>>>>>>> How is "policy" distinguished from access control?
>>>>>>>>
>>>>>>>> bob wyman
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 21, 2025 at 5:43 PM Alan Karp <alanhkarp@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>>
>>>>>>>>>> When addressing Composed Delegations, you say:
>>>>>>>>>>
>>>>>>>>>>> Composable: Dave needs to be able to get one permission from
>>>>>>>>>>> Alice, another from Bob and use them both in the same API call.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Imagine that Bob and Alice both have Q,U, and D privileges in
>>>>>>>>>> respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D
>>>>>>>>>> to Dave. Neither Bob nor Dave
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think you mean Alice
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> are aware that the other had delegated privileges to Dave. Now,
>>>>>>>>>> Dave needs to do something to X that requires both U and D. Are you really
>>>>>>>>>> comfortable with letting him combine the Q from Alice with the D from Bob?
>>>>>>>>>> Doing this would allow Dave to do something that neither Bob nor Alice
>>>>>>>>>> intended him to do. In fact, both Bob and Alice might be very surprised to
>>>>>>>>>> learn that Dave had, in fact, done that thing.
>>>>>>>>>>
>>>>>>>>>> You could also ask if Alice's delegation to Dave violates some
>>>>>>>>> policy.  Policy is a topic I chose to avoid.
>>>>>>>>>
>>>>>>>>> If you want policy enforcement, you'll have to mediate delegations
>>>>>>>>> in some way.  However, you still need to deal with credential sharing to
>>>>>>>>> get around blocked delegations.
>>>>>>>>>
>>>>>>>>> --------------
>>>>>>>>> Alan Karp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>>
>>>>>>>>>> When addressing Composed Delegations, you say:
>>>>>>>>>>
>>>>>>>>>>> Composable: Dave needs to be able to get one permission from
>>>>>>>>>>> Alice, another from Bob and use them both in the same API call.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Imagine that Bob and Alice both have Q,U, and D privileges in
>>>>>>>>>> respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D
>>>>>>>>>> to Dave. Neither Bob nor Dave are aware that the other had delegated
>>>>>>>>>> privileges to Dave. Now, Dave needs to do something to X that requires both
>>>>>>>>>> U and D. Are you really comfortable with letting him combine the Q from
>>>>>>>>>> Alice with the D from Bob? Doing this would allow Dave to do something that
>>>>>>>>>> neither Bob nor Alice intended him to do. In fact, both Bob and Alice might
>>>>>>>>>> be very surprised to learn that Dave had, in fact, done that thing.
>>>>>>>>>>
>>>>>>>>>> bob wyman
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 21, 2025 at 1:49 PM Alan Karp <alanhkarp@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I have followed a variety of access control systems off and on
>>>>>>>>>>> for some 30 years, including the recent discussion on this list of the use
>>>>>>>>>>> of OAuth 2.0 and 2.1.  I have concluded that many, if not all of them,
>>>>>>>>>>> suffer from being based on use cases that are too simple.
>>>>>>>>>>>
>>>>>>>>>>> In an attempt to address that problem, I've constructed a bunch
>>>>>>>>>>> of use cases <https://alanhkarp.com/UseCases.pdf> that I think
>>>>>>>>>>> capture all the hazards an access control system must address.  Comments,
>>>>>>>>>>> criticisms, and corrections will be appreciated and resented in equal
>>>>>>>>>>> measure.
>>>>>>>>>>>
>>>>>>>>>>> --------------
>>>>>>>>>>> Alan Karp
>>>>>>>>>>>
>>>>>>>>>>