Re: Access Control

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
>>>>>>>>>
>>>>>>>>