The "Please" question: where the delegator's policy lives

2026-10-28 · RTTP · IQA

Reading the Draft · No. 15 · Sources cited in this piece · the question, quoted verbatim from the public archive: W3C Agent Protocol CG · post 0058 · our answer on the same thread: post 0062 · the draft whose vocabulary the question touches: draft-li-rttp-iqa-addressing-01 (full text) · the series page: datatracker · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

On 27 October, a question arrived on the W3C Agent Protocol Community Group list from a veteran of the object-capability tradition — the school of thought that has spent decades on exactly this family of problems: how authority is delegated, carried, and revoked. The question was addressed to us directly, and it deserves to be read in full, because it is the sharpest formulation of a gap that everyone in agent authorization has been stepping around:

“Knowing why a request was rejected is useful. More useful is knowing the policy the delegator would like you to follow, e.g., only within the company. Most people (and agents) would obey your wishes if only they knew what they were. I have yet to see a system that has a place to put this information. As an aside, that policy is stated as a “Please.” Blocking a delegation that violates it leads to credential sharing, which means you'd also like a place to say why the policy is being violated.”

Figure 1: the two slots the exchange separated. The refusal reason is a closed, standardized set of authority facts; the delegator's standing policy is an open, unstandardized term of the grant — and a third slot, the reason a specific policy was violated, is open in every system either of us knows.

The gap is real — and the omission is deliberate

The first thing our answer did was concede the premise. There is no deployed system we know of that carries the delegator's standing policy as data a relying party could read — and our schemes do not fill that slot either. That is worth saying plainly, because the temptation in a public exchange is to claim the gap is already closed by something you shipped. It is not, and pretending otherwise would have cost the exchange its value.

But conceding the gap is not the same as conceding it should be filled at the layer the question assumed. The refusal reason of Section 8 of draft-li-rttp-iqa-addressing-01 is a closed five-value set with a fixed priority order, and every value in it is an authority fact: the evidence did not match, the evidence expired, the authority could not be determined, the authority was revoked, the operation is not permitted. “Only within the company” is not an authority fact. It is a term of the grant, or a preference of the delegator — it lives in the mandate the delegator hands over, not in the wire answer the verifier computes.

Why we will not enumerate the "Please"s

The draft applies the same rule to policy text that it applies to action verbs. Section 7.1.1 of the same draft, on the ACTION field: “this document deliberately defines no enumeration of verbs, because enumerating an open set would close it.” An action vocabulary frozen at whatever its authors thought of first stops being an open set the day it is published — every deployment with a verb the committee did not anticipate becomes nonstandard by definition. A standard vocabulary of "Please"s would die the same death: standardized, it would be closed by exactly the act of standardizing the ones we happened to think of first.

This is not obstinacy; it is the difference between a floor and a ceiling. The five refusal values work as a floor because authority facts are finite — there are only so many ways verification can fail, and the set names all of them. Policy is not finite. Delegators will want constraints nobody has imagined yet, and the architecture that serves them is one where the policy layer stays open on purpose.

Figure 2: the composition the draft actually states. The mandate layer carries the "Please" in whatever vocabulary the delegator likes; the verification layer answers one small question with a closed set of authority facts; and the two compose without either depending on the other.

The credential-sharing argument cuts our way

The question's closing move — blocking a delegation that violates policy leads to credential sharing, so you'd also want a place to say why the policy was violated — is, we think, independent support for the discipline the vocabulary already imposes. The draft requires implementations to emit nothing outside the set and to reinterpret nothing inside it, and it states the principle in one line: “a response that reports an outcome without its reason is not conformant: the reason is what makes a refusal auditable.” An articulable refusal gives the blocked party something to read and correct; a silent block gives them something to route around. On that point the exchange was entirely aligned — which is precisely why the answer names the boundary where alignment ends.

The honest gap

What no artifact in the thread carries yet — ours included — is the second slot the question named: a standard place for the reason a specific policy was violated. Policy vocabularies are deployments' own, open-ended, and belong to the calling layer, the same layer that owns action-time authorization, which the draft explicitly declines to claim. Naming that as an open question is the right first move; standardizing it would be a larger project than a thread, and our answer made no promise about it. The gap is real, it is now on the record, and the first step to filling a slot honestly is agreeing on where the slot is.

One line: the "Please" is real, the slot for it is deliberately not ours — authority facts go in the closed set, policy goes one layer up unstandardized, and the reason a specific policy was violated stays an honest open question, named and unanswered.