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

[Rob Meijer]

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

--

[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

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

[Rob Meijer]

On Fri, 30 Oct 2026, 00:27 Alan Karp, <alan...@gmail.com> wrote:

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?  

These would be complementary, I think.

Imagine a scenario where Alice wraps Bob in a caretaker (Carol) and delegates Carol to Dave. Dave invokes Carol, who invokes Bob. Bob does his work on a shadow resource until he is ready to commit his final state to resource Rachel.

But what if Alice revokes Carol after Carol already invoked Bob, but before Bob commits to Rachel?

In my draft approach, Bob is marked as 'diffusible' and receives a callable diffuse wrapper. 

When Dave invokes Bob through Carol, diffuse acts as a proxy for Carol's  revocation state. 

When Bob is finally ready, he passes his commit action on Rachel through diffuse.

If Carol has been revoked mid-flight, diffuse simply swallows the commit as a no-op.

It "might" also be useful to pass diffuse a second callable to trigger a clean rollback on the shadow resource if the commit is swallowed. I'm not sure if that mixes paradigms too much, though. Thoughts? 

A bigger concern though I think remains that in language context, my solution arguably only is least authority because the language plus the type system doesn't allow user code to inject a 'diffuse', because diffuse has a type that only the runtime (standard apply style diffuse) and a caretaker (self injected revokable diffuse) can fulfill. 

If you can do an equivalent with cert-caps, then it could be a good fit for your W3C efforts, but I'm too unfamiliar with your W3C efforts or cert-caps in general to have any idea if such equivalence would be within reach.

Regards,

Rob

To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z0Yjz8W6LL0nvM5nP%3DH8BnPD9LnKA_JtTn%3DPiPzG53g8g%40mail.gmail.com.

[Raoul Duke]

ignorant question (as ever from me): With lossy network connectivity, this is all best effort? Either everything is checked every time, or there will always be a window of time where things are allowed erroneously?

[Matt Rice]

On Fri, Oct 30, 2026 at 6:06 AM Raoul Duke <rao...@gmail.com> wrote:
>
> ignorant question (as ever from me): With lossy network connectivity, this is all best effort? Either everything is checked every time, or there will always be a window of time where things are allowed erroneously?

Section 11.5.3 of robust composition augments the caretaker with a
dead man's switch, to automatically disable the capability if the
delegated capability has
lost connectivity to its origin. So that is one way to fail safely.

[Alan Karp]

I actually view that as a simplification.  There is an unavoidable race between an invocation and a revocation request of the authorization.  Even with a perfect network, you could have sent the revocation request just after the invocation completed.  Hence, any network issues are equivalent to a delay in sending the revocation request.

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

On Fri, Oct 30, 2026 at 6:06 AM Raoul Duke <rao...@gmail.com> wrote:

ignorant question (as ever from me): With lossy network connectivity, this is all best effort? Either everything is checked every time, or there will always be a window of time where things are allowed erroneously?

--

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/CAJ7XQb6T3fqkZ%3Dgd7aKT5FksK7maLykbb4HxDMnTf2kxmJGfKw%40mail.gmail.com.

[Alan Karp]

I don't think you need all that complexity.  After all, you can't control whether the revocation request is received after the work was done instead of during execution.  

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1Ww1HSH1a%3DixVUiiB76aURUdyL7V2MPEPigdWZj%2BHa9Lw%40mail.gmail.com.

[Alan Karp]

On Fri, Oct 30, 2026 at 6:26 AM Matt Rice <rat...@gmail.com> wrote:

Section 11.5.3 of robust composition augments the caretaker with a
dead man's switch, to automatically disable the capability if the
delegated capability has
lost connectivity to its origin. So that is one way to fail safely.

And I recommend that certificate capabilities have an expiration time for the same reason.  The interesting question is what you do when the expiration happens while the task is running. 

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

[Rob Meijer]

On Fri, 30 Oct 2026, 16:20 Alan Karp, <alan...@gmail.com> wrote:

I don't think you need all that complexity.  After all, you can't control whether the revocation request is received after the work was done instead of during execution.  

My brain is disconnecting a bit on that statement. In my DSL caretaker revocation gets higher scheduling priority than caretaker invocation, but both are pretty close to do nothing compared to the work the actual callable will usually do, so there might be quite a few Carol (caretaker) approved queued invocations waiting for Bob when Carol changes state. 

If a commit on Rachel (resource) is resource intensive, then post revocation resource usage should be greatly reduced by such "complexity". 

Do you think I'm solving the wrong problem and something like my proposed 

diffusible/diffuse DSL language feature would be futile? Or is this a language only consideration that doesn't exist in the cert-caps universe?

Regards,

Rob

To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z26FrtBKTLrxfqZS%3DCZ2w1z09VjxRs37EB8ouFcEuVYGw%40mail.gmail.com.

[Alan Karp]

The code that sends the revocation request is concurrent (in the Lamport sense) with code that generates the invocation using that permission.  As a result, either one could occur first independent of any compute or network delays.

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1V5GWowGgF8zSQPGKMbKnBwTo1ho2fRQ2mH6NPv4EOaTQ%40mail.gmail.com.