How long is a delegation valid?

[Alan Karp]

I've been discussing attenuated delegation with a W3C group, where someone asked, "When should you consider the status of a delegation?"  There are 3 relevant times: when the delegation is made, when the resource is invoked, and when that invocation ends.  

Clearly, access policy is used at the time of delegation, and verifying the delegation is done on invocation.  There are then 2 interesting questions - what if the delegation condition is no longer true at invocation, and what if it changes during execution,

I worry about leaving the application in an inconsistent state if it's interrupted mid invocation, which leads me to favor using time of invocation as the deciding factor.  My excuse is that there is an unavoidable race between the steps and the state changes.  The person you delegated to might leave the company just after the invocation finishes or just before.  The same applies to revocation; the revocation request might reach the server just before the invocation finishes or just after.

I recognize the risk of this choice.  Allowing execution to continue after conditions change can lead to problems but so can interrupting the application.  If there's a danger that your application will crash because of a refused delegation, you have an incentive to share credentials.

--------------
Alan Karp

[Mark S. Miller]

> When should you consider the status of a delegation?

Who is "you"?

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z16XWoJwPBnnKXgyxMZzA9EqFZ3-_Gg52pco%3DGik66bRw%40mail.gmail.com.

[Matt Rice]

On Thu, Oct 29, 2026 at 11:13 AM 'Mark S. Miller' via friam
<fr...@googlegroups.com> wrote:
>
> > When should you consider the status of a delegation?
>
> Who is "you"?
>
>
>
> On Thu, Oct 29, 2026 at 10:57 AM Alan Karp <alan...@gmail.com> wrote:
>>
>> I've been discussing attenuated delegation with a W3C group, where someone asked, "When should you consider the status of a delegation?" There are 3 relevant times: when the delegation is made, when the resource is invoked, and when that invocation ends.
>>
>> Clearly, access policy is used at the time of delegation, and verifying the delegation is done on invocation. There are then 2 interesting questions - what if the delegation condition is no longer true at invocation, and what if it changes during execution,
>>
>> I worry about leaving the application in an inconsistent state if it's interrupted mid invocation, which leads me to favor using time of invocation as the deciding factor. My excuse is that there is an unavoidable race between the steps and the state changes. The person you delegated to might leave the company just after the invocation finishes or just before. The same applies to revocation; the revocation request might reach the server just before the invocation finishes or just after.
>>
>> I recognize the risk of this choice. Allowing execution to continue after conditions change can lead to problems but so can interrupting the application. If there's a danger that your application will crash because of a refused delegation, you have an incentive to share credentials.
>>

I'm not really familiar with any long or indefinitely running
invocations, like I can't immediately bring to mind an invocation
which never terminates.
But if there were such cases, doesn't this lead to effectively not
being able to be revoked?

Also, seems like there could be cases where revocation is an
invocation, and you are recursively revoking some capability, it would
seem like avoiding revocation until the end
such code could end up with some form of a loop revoking the same
capabilities over and over which is not taking effect?

Those seem like some additional corner cases at least that could be
impacted by your choice

[Alan Karp]

"You" depends on which of the 3 times it is.  "You" is the delegator at delegation time.  "You" is the verifier (the component that decides if the request is authorized) at invocation time.  "You" is the application or perhaps an external monitor during execution.

--------------
Alan Karp

On Thu, Oct 29, 2026 at 11:13 AM 'Mark S. Miller' via friam <fr...@googlegroups.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/friam/CAK-_AD6trmpAYvO2TdRUs-VbrYyq_KGeMqxrpfMi6pQT7x3%2Bnw%40mail.gmail.com.

[Alan Karp]

Can't you use one of the standard approaches for speculative execution where you apply any updates to shadow resources until you're ready to commit them?  

My concern is that not many applications are designed for that case.

--------------
Alan Karp

On Thu, Oct 29, 2026 at 1:36 PM Rob Meijer <pib...@gmail.com> wrote:

Hi Alan,

I’ve been wrestling with this exact "revocation during operation" problem for a DSL I'm building, specifically regarding the inconsistent states you mentioned.

I use a mostly standard caretaker pattern (with an  optional built in invocation quota), which is easy for people to grasp. 

But for mid-operation revocation, I’ve been experimenting with a function modifier for the v0.5 version of my language spec that I call 'diffusible'.

The goal is to allow the target object to finish executing so it doesn't leave the application in a bad state, but to safely and voluntarily "diffuse" any downstream actions it tries to take after revocation.

Under the hood, it works like this:

The diffusible modifier wraps all of the function's outgoing invocations in a special apply-like wrapper (an extra argument called diffuse).

When a caretaker invokes the function, it injects a clone of itself into the diffuse argument.

If the caretaker is still unrevoked, diffuse acts as a normal 'apply'.

If the caretaker is revoked mid-flight, diffuse instantly becomes a null function (a no-op).

The parent function finishes its local logic safely, but its ability to affect the outside world is cleanly severed.

I struggle to explain this intuitively, and I also have no idea how this would map to a non-language, cert-caps context like W3C. 

I have a type system on my side that ensures only built-in caretakers can overload diffuse. I fear it would be hard to find an equivalent mechanism in a distributed, certificate-based system to silently swallow outgoing requests mid-flight.

Maybe this is something worth brainstorming over though?

Regards,

Rob

--

You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z16XWoJwPBnnKXgyxMZzA9EqFZ3-_Gg52pco%3DGik66bRw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1XTccLu0tEJSne0jmn4Mj7WGf%2BLBN-jRGXdq0vy-nGinA%40mail.gmail.com.