Three moments, one race: when a delegation's status is decided

2026-10-30 · RTTP · IQA

Reading the Draft · No. 20 · Sources cited in this piece · the question post, quoted verbatim: W3C Agent Protocol CG · post 0095 · Alan Karp · our reply, on the record: post 0096 · the second round of the same day: Reading the Draft · No. 21 · the mid-task rule this round extends: Reading the Draft · No. 18 · the lease semantics underneath: draft-li-rttp-iqa-addressing-01 (full text) · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

The exchange with the series' counterpart ran two rounds today; this piece takes the first. Alan Karp — whose questions have driven this series since No. 15 — posed the sharpest question the delegation thread has produced yet: when, exactly, is the status of a delegation decided?

The question on the record (post 0095), quoted verbatim · Alan Karp · source on the wall
“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.”
“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.”

Figure 1: the three relevant times, drawn on one line. Policy is expressed at the first moment, the condition is judged at the second — and between the second and the third lives the race: the departure or the revocation that lands just before or just after the invocation finishes.

The deciding moment converges

Our reply (post 0096) recorded the convergence first: with the 0095 correction, the two positions now share the same deciding moment. The access policy is expressed when the delegation is made, and the condition is judged when the resource is invoked. The wire reaches the same conclusion from the other direction: the condition may be the delegator's, but the freshness of the facts it consumes must be re-derivable at the moment of use — and that is exactly what the lease and its expiry timestamp exist to carry. The draft never had to be argued into this alignment; the timestamp was the design.

The race is not dissolved — it is made legible

The reply declined to claim the wire dissolves the race. A revocation arriving just before or just after an invocation ends is a boundary no protocol can erase, and pretending otherwise would be worse than the race itself. What the wire can do is make the boundary legible: the receipt records when the authority-side facts were effective and when they were observed; a read past expiry is answered as expired rather than replayed as fresh; and where the answer cannot arrive in time, residual semantics apply — the bytes state how old the claim is, so the caller decides with the age on the table instead of on a silent assumption. Nothing in that list removes the race; everything in it removes the excuse for not seeing it.

Figure 2: the boundary receipt. Two timestamps — effective and observed — pin down what the decision stood on; the expired read is answered as expired; and where the answer cannot arrive in time, the residual mode states the claim's age instead of hiding it.

The strongest argument for the readable refusal

His closing paragraph is an incentive analysis, and our reply took it as the strongest argument for the refusal design the series has been running since No. 15. If a refusal is fatal — if the refused delegation crashes the application — then sharing credentials becomes the rational shortcut, and attenuation dies of its own enforcement. So refusals are made legible instead: a closed set of reasons with an auditable receipt lets the caller degrade, retry or reroute rather than crash. Attenuation survives precisely because a DENY can be read, re-derived by a third party, and answered to — the same property the VOC experiment would demonstrate empirically hours later, in the second round of the same day.

Why this round helped

He supplied the map — three relevant times, one unavoidable race — and the reply bound each element to machinery that already exists: the expiry timestamp for the deciding moment, the effective-versus-observed receipt for the race, the closed-set refusal for the incentive. Nothing new had to be invented; the question only had to be asked precisely, and it was. The second round, hours later, carried the same design forward into the exception path — and that round is taken up in No. 21.

One line: the protocol cannot erase the race; it can make its boundary legible — and a denial that can be read, re-derived, and answered is the alternative to credentials that must be shared.