Re: Access Control

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