An independent prototype proposal, not an official AAuth document and not endorsed by its authors.

Prototyped on AAuth; examples derived from the public AAuth-10 protocol draft; applies to any case where an agent must decide whether to proceed or escalate to a person.

Note, updated 5 October 2026. The body below is the 17 September 2026 version of this design. AAuth draft-11 (25 September 2026) renumbers the sections cited here and introduces a Supervisor: the person by default, or a supervision server the person server may delegate to, judging each request against the mission, the mission log and “the person's policy”. The draft leaves that policy, and how a supervision server decides, to a companion specification. This design would likely sit at or beside that supervision server, with the person's behavioral specification as the policy: where everything the person server cannot decide waits on the person, it would sort which requests the specification can answer and which still go to the person.

Note, 1 October 2026. Parts of stages 02 and 03 below (indexing which claims a situation can activate, and checking whether claims hold together) are being worked into the behavioral specification pipeline, to avoid overburdening runtime. Those stages are tagged below.

The verdict examples reproduce public issues from the AAuth GitHub repository, for illustration; quoted text and names are the original authors', who have not reviewed or endorsed this page.

Sources: 33 public issues

#101 How should a proactive strategy agent read company context 24/7 securely?
#103 Move the person token endpoint into §8; keep the token structure in §6
#104 Lingering agent-token references where the person token is now authoritative
#105 429 from a resource invocation has no defined semantics — the only 429 in -11 is polling slow_down
#106 README.md Slack invitation links are expired
#107 How does AAuth relate to fine-grained authorization beyond scopes?
#108 Pending grant lifetime, and key rotation across a pending grant
#109 Personal PS profile: the minimal single-person Person Server
#110 Define what a governance policy is — the decision procedure behind auth token issuance and requirement=clarification
#111 Interaction completion out of band: the PS completes on its own channel and the code is never presented
#112 Proxy deployment: specify the verifying-proxy-to-origin hop
#113 Cross-namespace key binding: say where an agent's other-keys attestation would live
#114 Deferred verification: point queued-consumption verifiers at the signed created timestamp
#115 Bootstrap: many agents, one operator — self-hosted key layout and custody
#116 Bootstrap: sub-agent token acquisition is deferred here but not covered
#117 State the minimal conformant PS floor in ps-metadata
#118 Warn that policy keyed on the agent identifier does not survive across access modes
#119 The person-token-before-resource-token prerequisite is stated once and easy to miss
#120 Replace budget_consumed records with a single claim for the presented token's spend
#121 Mission-bound token expiry cannot be derived by the Resource or Access Server
#122 Budgets: an omitted PS ceiling is indistinguishable from extension non-participation
#123 No error code for the PS reporting an unreachable or failed AS to the agent
#124 Terminology: distinguish supervision (per-act evaluation) from governance (the mission framework)
#125 Parties diagram: Resource → Agent arrow labeled "resource" instead of "resource token"
#127 Budgets: update Implementation Status for Regent Protocol (in production)
#134 Discovery: Support discovery of resource metadata via Link relation so dev portals can use them in case agents hit them first.
#145 requirement=agent-token cannot say which claim the agent token must carry
#146 Revocation request carries no exp, so a recipient cannot bound its revocation state
#151 Settlement of a revoked auth token: is revocation an early exp?
#152 presented_jti should name the token actually presented, and the agent should pass it to the PS
#154 revocation_endpoint: RECOMMENDED for PS and AS, and for a resource that accepts person tokens
#155 Remove Third-Party Login and login_endpoint
#160 Linking a person to an upstream service a resource brokers

Prototype design · built on AAuth draft‑10

AAuth Governance Escalation via a PS-based Conformance Layer

Decision flow for qualifying governance escalation using a behavioural specification. An independent prototype proposal, not an official AAuth document and not endorsed by its authors.

Overview

01Covered by a deterministic rule?

permits → access server forbids → mission agent unclear → stage 02

02Which Active_When tags activate?Moving to specification pipeline

nothing → governance no coverage something → stage 03

03Evaluate the activated claims and their facts for coherence and contestationMoving to specification pipeline

evidence packet → stage 04 no escalation from this stage

04What is the verdict on this packet?

approve → access server deny → mission agent full or partial escalate → governance agent held

05What did governance decide?

allowed → access server refused → mission agent

Three destinations throughout: the access server when the request advances, the mission agent when the agent has work to do, governance when the layer declines to decide. Coherence and contestation are read together inside stage 03 to build the packet that stage 04 rules on.

01Deterministic rulesno model callno tokens

Covered by a deterministic rule? Rules are consulted before the conformance layer.
§7.1.3 · §7.1.2 · §8.2

whenRule permitsresultRouted to access server payloadAuth Token

exampleFix a spelling error in §3.1 of the draft. An editorial-changes rule permits it outright.

whenRule forbidsresultReturned to mission agent payloadMission Agent Refusal

exampleSend mail to an address outside the approved recipient list. A rule forbids it outright.

whenUnclearresultEscalate to conformance layer stage 02 payloadProposed Action + Mission + Rules

exampleReply to a working group comment proposing a normative change to §6.2. No rule permits it and no rule forbids it.

02ActivationMoving to specification pipeline1 api call~1,900 in · ~1,000 out

Is anything the person reasons from engaged? The request is evaluated against the behavioural specification's Active_When tags.
§7.1 · §14.12

receivesProposed Action
Mission
Rules
the specification's Active_When tags, and nothing else

Worked example

proposed action: working group comment, oauth@ietf.org §9.4 returns a generic 403 for every authorization failure. Implementers cannot tell an expired grant from a scope mismatch from an unknown agent. Should the spec enumerate distinct error codes?

The check reads the 76 Active_When tags against that action. Seven activate:

Specifying or documenting how something must behave for others to implement. P10
Whenever one party must understand what another needs, refused, or is waiting on. A9
Producing or reviewing any artefact intended for others to implement or follow. C11
Another party must understand a requirement, a capability, or an outcome they did not directly observe. P11
Any interaction where two parties must coordinate without prior arrangement. C12
Anything a person will read, approve, or be notified by. C18
Disclosing capability or failure detail to an unauthenticated or unknown caller. P27

Anchors and core are read at this stage. Predictions are held back for the verdict. This example predates that split and will be rerun once the pipeline is settled.

whenNo Active_When tagresultEscalated to governance agent held payloadProposed Action + Mission + Coverage Gap Record (no rule, no claim)

gateMechanical, not a judgement. An empty packet cannot proceed to a verdict. Nothing downstream is asked whether silence means yes.

whenOne or more Active_When tags resultPassed to case and mitigation stage 03 payloadProposed Action + Mission + Activated Claim IDs

03Case and mitigationMoving to specification pipeline1 api call~10,200 in · ~400 out

Build the case, then mitigate its weaknesses Two contradictions are looked for: between claims, and inside a claim's own facts. Each one found is written down with the evidence that answers it.

How the stage is structured

One call. One brief asks for both searches and returns one JSON object per item, holding coherence, contestation and mitigation. Coherence reads claim against claim and never looks at a fact. Contestation reads one claim against its own cited facts and never compares two claims. Mitigation is built only for what those two found.

Only the divided claims carry facts. Of 763 activated claims across the 33 items, 280 arrive flagged as having a divided record, and those are the only ones whose individual facts are in the packet. An unflagged claim is present as its trigger and its body.

The flag is a starting point, not a finding. Each of the 280 is tested against this item: does it divide on the point this action raises? 97 of 280, 35%, survived. The rest are logged with the reason they were set aside.

receivesProposed Action
Mission
Activated Claim IDs

loadsEvery activated claim in full: trigger and body
The cited facts of the claims flagged as divided, and only those

Conflict

across all activated claims

Do the activated claims disagree with each other about this proposed action, one saying do it and another saying do not?

Division

per claim, against its own cited facts

Is a claim that takes a side here one whose own record answers both ways? If so, its cited facts are sorted into the two sides, for this action specifically.

Worked example

proposed action: github issue, open requirement=agent-token cannot say which claim the agent token must carry. A resource that needs the agent token to carry a vouched-for extension claim, such as a trust grade, can only answer that an agent token is required. The agent already holds one. It holds the wrong one, and the challenge gives it no way to learn that.

finding 1Between claims: coherence

A9	SAY IT EXPLICITLY	with
C12	EXPLICIT SIGNALS OVER INFERENCE	with
P27	WITHHOLDS DETAIL FROM STRANGERS UNEASILY	against

About: whether the challenge should tell the caller which claim its token lacks, or return a failure that does not say which part went wrong.

finding 2Inside a claim: contestation

C6 DECENTRALIZE YET CONCENTRATE CONTEXT divides on this action: whether a new extension point needs formal registry governance, or should be left to URI namespacing with no central owner.

Eight other flagged claims were examined and rejected as off-axis. A divided record is not a weakness unless it divides on the point this action raises. Three of the eight:

A11 the record is uniform here: unrecognised-parameter tolerance is the exact mechanism the proposal relies on, and no strict-side fact opposes an ignorable parameter
C10 the flagged split is over retention and identifier correlation; the parameter names a claim and says nothing about contents, records, or retention
C8 the flagged split is autonomy against human oversight; no human sits in this loop

mitigationBuilt only for the two live weaknesses

for A9+C12 vs P27

3 facts answer it

P27's condition is an unauthenticated or unknown caller, and this challenge answers an agent that has already presented a valid agent token, so the disclosure is to a known party

for C6

1 fact one side, 5 the other

a URI-valued claim name keeps the extension point open without AAuth owning a registry, which is the arrangement the decentralising facts call for while still standardising the slot the registry fact wants

Across three passes over all 33 items the call sorted 941 facts into sides, a median of 8 per weakness. It examined 280 divided claims and found 97 of them, 35%, divided on the point the item actually raised. Only findings appearing in at least two of the three passes travel on, which is what the verdicts below ran against: 42 divided claims and 378 sorted facts across 30 items.

whenBetween claims: coherenceresultTravels in the evidence packet stage 04 payloadCoherence Finding = which claims point which way on this action + Fact IDs + the mitigating evidence for it

Example

Item§6.2 requires a key-bound credential for every agent introduction. Permit trust-on-first-use for constrained IoT devices, with pinning thereafter.

P1	REFUSES PRIOR SETUP REQUIREMENT	with
C12	EXPLICIT SIGNALS OVER INFERENCE	with
C3	VERIFICATION OVER TRUST	against
C4	ADVERSARIAL BY DEFAULT	against
P2	DEMANDS PROOF NOT POSSESSION	against
P12	TREATS ALL INPUT AS HOSTILE	against
A16	SELF CONTAINED VERIFICATION	against

2 with, 5 against → CONFLICT NAMED

whenInside a claim: contestationresultTravels in the evidence packet stage 04 payloadContestation Finding = the point it divides on + its mitigating evidence: the claim's own cited facts sorted into the two sides + Fact IDs

Example

Item§6.2 requires a key-bound credential for every agent introduction. Permit trust-on-first-use for constrained IoT devices, with pinning thereafter.

Active_WhenAsking whether a requirement can be relaxed.

C15FLEXIBILITY WITH HARD FLOORScore · CONTESTED · 24 cited facts

claimThey generally favour graceful degradation, runtime adaptation, and backward compatibility over hard failure, yet they hold a small set of absolutely non-negotiable requirements: fixed signature components, transport encryption only, strict identifier normalization, rejection of on-wire algorithm negotiation and weak or deprecated cryptography. Read their flexibility as broad but bounded; when they refuse to bend, it is on a floor they consider foundational rather than a preference.

Side A: relax it

9 of the 24 cited facts

F-565897b7 values flexibility and runtime adaptability over strict protocol enforcement
F-acb6a340 values flexibility and composability of trust establishment mechanisms over rigid pre-registration requirements
F-c70241a5 values capability negotiation and graceful degradation over assuming universal feature support
F-c4f12f40 values flexibility and adoption without requiring coordination between parties
F-6dca01cf values incremental adoption paths where each step provides immediate value without requiring full implementation

Side B: hold the floor

15 of the 24 cited facts

F-161f3f8d believes cryptographic signature verification is a foundational requirement that all conformant agents must support
F-17ab0502 believes security requires rejecting underspecified or deprecated cryptographic schemes even if they complicate implementation
F-22739a09 believes every agent should have its own cryptographic identity independent of any particular server or pre-registration
F-57d3779f believes agents require cryptographic proof of identity via signed requests and JWT tokens
F-717d8d40 values mandatory coverage of four specific request components over optional or negotiated ones

The action asks whether a requirement can be relaxed, which is C15's trigger exactly. Its own record answers both ways, and the action lands on the split, so its 24 cited facts are sorted into the two sides → MITIGATING EVIDENCE

whenBoth searches are doneresultThe packet goes to the verdict stage 04 payloadEvidence Packet = Proposed Action + Mission + Activated Claims + Fact IDs + each finding with its own mitigating evidence + the divided claims set aside as off-axis, with the reason

04Verdict1 api call~5,300 in · ~700 out

What is the verdict on this packet? The evidence packet is reviewed alongside the specification's predictions for a final verdict.

receivesEvidence Packet
Conflicts
Mitigating Evidence
Predictions

Completeness gate

Runs before any verdict issues. It asks whether the verdict addressed all the evidence in the packet, never whether it agreed.

every weakness in the packet is in the verdict's open points, or named in its reason
a deny states full or partial, and a partial names the change
a no-action verdict quotes the words that show it

A failure returns the packet to the same verdict agent. It does not escalate. No-action verdicts are exempt from the first check, because a verdict that rules nothing was proposed never engages the claims.

⚠ One gap it does not close. 10 of the 250 claims the verdict cited across 30 items never activated, so no packet entry backs them. Comparing cited claims against the activated set is arithmetic. Log it, do not block it: reaching past the activated set may be right; doing it invisibly is not.

Outcome	Sub-type	When	Goes to	Of 33
APPROVE		The packet supports the action	Access server	20
All 20 approvals I104Lingering agent-token references where the person token is now authoritativeAPPROVE Proposed action, in full · 480 words Second half of Jared Hanson's feedback — lingering references to agent tokens that should now be person tokens. He said he would post his own list once he confirms it; these are the ones I found while checking. Companion to #103. The rule the draft states three times §5.2.2, on the agent token's `ps` claim: "The PS of an issued authorization is the `iss` of the person token the resource verified (#person-token-structure), not this claim." §7.8.1, on the resource token's `ps` claim: "The `iss` of the person token the resource verified — the person server whose namespace `sub` belongs to" §4.6: "The `ps` claim in the agent token tells the resource the agent has a person server, before the resource has anything else to go on. The PS a resource acts on is the `iss` of the person token it verifies" Three places in §7 that still route on the agent token §7 intro: "If the resource has no AS but the agent has a PS (`ps` claim in agent token): `aud` = PS URL (three-party)" §7.2 intro: "The resource can handle authorization itself, or it can issue a resource token when the resource has an AS or the agent token includes a `ps` claim." §7.2.2: "If the resource has no AS but the agent has a PS (`ps` claim): `aud` = PS URL (three-party)" All three set `aud` from the agent token. They should read from the person token the resource verified. The paragraph immediately above (1) already says a resource MUST have verified a person token before it issues a resource token — at that point the resource holds `iss` and does not need the hint. The agent token's `ps` claim decides whether challenging with `requirement=person-token` is worth the round trip; it does not decide the audience. Related, §7.1 An agent with no person server cannot obtain a person token and so cannot use the authorization endpoint. It calls the resource's endpoints directly and takes whatever the resource challenges with — identity-based access (#requirement-agent-token) or resource-managed authorization (#resource-managed-auth). The `401` path (#requirement-auth-token) is reached with an agent token as before. The last sentence contradicts the section it is in. A `requirement=auth-token` 401 carries a resource token, §7 says a resource MUST NOT issue one without a verified person token and MUST challenge with `requirement=person-token` instead, and an agent with no PS has nowhere to redeem a resource token anyway. The sentence should be dropped or replaced with the statement that identity access and resource-managed access are the whole of what is available without a PS. Related, §8.1.3 The subsection is titled "Agent Token Request" but is the request for an auth token — the agent presents its agent token there, and since #75 the draft has two other agent-presented credentials. Retitle to "Auth Token Request", matching the `auth_token_endpoint` rename in #81. reasoningThe item corrects the draft so it follows a rule the draft already states three times: the PS a resource acts on is the iss of the person token it verified, not the agent token's ps claim. The fix makes the three §7 audience rules read from the verified person token and demotes the agent-token ps claim to a hint about whether to challenge. Full reasoning The item corrects the draft so it follows a rule the draft already states three times: the PS a resource acts on is the iss of the person token it verified, not the agent token's ps claim. The fix makes the three §7 audience rules read from the verified person token and demotes the agent-token ps claim to a hint about whether to challenge. That matches `C3`verification over trust/`A1` (act on what was verified, not on a self-asserted hint), `P12` (don't take the sender's word for a routing-critical value), `C23` (strict issuer matching), and `A16` (the resource already holds iss, so the check needs nothing more). Dropping or replacing the §7.1 sentence removes an internal contradiction: it would send a no-PS agent down a 401 auth-token path that §7 forbids and that has nowhere to redeem. That fits `A9`say it explicitly/`C12`explicit signals over inference, which want requirements stated consistently rather than inferred. Retitling §8.1.3 to 'Auth Token Request' to match the auth_token_endpoint rename is the same kind of consistency fix. The packet has no coherence conflict and no divided contestation, and every rejected contestation is about where decisions sit or whether mediation is mandatory, not which verified token a value comes from. It also keeps identity-based and resource-managed access for agents without a PS, as `A3`nothing is two party wants (several access modes coexisting). what in the item it read'All three set aud from the agent token. They should read from the person token the resource verified... The agent token's ps claim decides whether challenging with requirement=person-token is worth the round trip; it does not decide the audience.' Also the proposed removal of the §7.1 sentence 'The 401 path (#requirement-auth-token) is reached with an agent token as before' and the retitle of §8.1.3. 23 activated claims 8 named in the reasoning named in the reasoning · 8`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A3`Nothing Is Two Party41 facts activated, not named · 15`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts No contradictions identified 5 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A19 whether an intermediary is mandatory, not which verified token supplies the authoritative ps valuedick-aauth10:C10 audit retention versus privacy of identifiers, which this routing correction does not touchdick-aauth10:C20 mandatory mediation of onward authority, not the source of an already-verified claimdick-aauth10:C6 where a decision is made, whereas this action only resolves which token a value is read fromdick-aauth10:C8 autonomy versus human control, untouched since identity and resource-managed access remain available without a PS 3 open points logged, did not change the decision *`A19`mediation over direct contact/`P6`mediation required and refused: the person both requires and refuses mediation without naming what distinguishes the cases. Rejected as not on this point.did not change the decision: The edit doesn't change whether a PS is required. It only fixes which already-verified token supplies the PS URL, and access without a PS stays intact.For §7.1 the item offers two options, dropping the sentence or replacing it with a statement that identity and resource-managed access are all that is available without a PS, and doesn't choose.did not change the decision: Either option removes the contradiction. The replacement is slightly better under `A9` (say it explicitly), but both represent the person faithfully.The list may be incomplete. Jared Hanson said he would post his own list once confirmed.did not change the decision: Being incomplete doesn't make the corrections given here wrong. Further stragglers can be fixed on the same principle. I105429 from a resource invocation has no defined semantics — the only 429 in -11 is polling slow_downAPPROVE Proposed action, in full · 592 words Problem* -11 has no way for a resource to say "I am rate limited" as the outcome of an invocation. `429` appears in the draft in exactly one role: `slow_down` in (#polling-error-codes), meaning the agent is polling a pending URL too frequently and should add 5 seconds to its interval. That is a statement about polling cadence, not about the resource's capacity to do the work. There is also no resource error-code table. (#token-endpoint-error-codes) and (#polling-error-codes) are the only two enumerations. A resource that wants to refuse an invocation for capacity reasons has no registered `error` value to put in the RFC 9457 body, and an agent receiving a `429` from a resource endpoint cannot tell whether it means "you are polling too fast" or "this resource cannot serve you right now." Why it matters A proxy resource fronting a third-party API inherits that API's limits. Those limits are frequently scoped to the OAuth client, not the calling agent — so every agent using that proxy shares one quota. This changes what the agent should do, and the agent currently has no way to know: Limit is the agent's own → back off, retry later, the quota recovers because you stopped. Limit is shared across all agents using this resource → backing off may not help within any useful horizon, because other agents are still consuming it. Retrying is close to useless; the agent should plan around the resource, tell the user, or pick a different resource. Same status code, same `Retry-After`, opposite correct behaviour. Suggested direction A resource error-code table, with at least a rate-limit code (`rate_limited` / `too_many_requests`), so the `error` member in the problem+json body is defined for the invocation case rather than borrowed from the polling table. A scope indicator — whether the exhausted quota is attributable to this agent, to this user, or shared across the resource's clients. This is the field that makes the response actionable. Disambiguate `429`. Either register the invocation meaning explicitly alongside `slow_down`, or use a distinct status for the invocation case. As written, an agent that shares 429 handling between polling and invocation will apply linear polling backoff to a capacity refusal. `Retry-After` requirements. State whether it is REQUIRED on a rate-limit refusal and what the agent does when it is absent. Upstreams differ: some send `Retry-After` in seconds, some send a reset timestamp in a proprietary header, some send nothing. Relationship to `202`. (#deferred-responses) already lets a resource hold an invocation rather than refuse it, and (#deferred-auth-token) already specifies the replay rule — the resource retains the result and answers a repeat presentation from that result rather than executing twice. A rate-limited invocation looks like a natural fit: hold it, return `202` with `Retry-After`, execute when the window opens. Worth stating explicitly that a resource MAY defer for capacity reasons and that the same replay requirement applies, so implementers do not have to infer it. `Prefer: wait=N` then covers short waits without a round trip. If (5) is the recommended shape, the guidance is roughly: short wait → hold and defer via `202`; long or shared-quota exhaustion → refuse with the new error code and a scope, so the agent can plan instead of poll. Context Found while designing 429 handling for an AAuth proxy fleet that fronts ~40 third-party APIs (Slack, GitHub, Google, Asana, Calendly, X, Dropbox, …). Each has its own rate-limit dialect, and normalizing them to something an agent can act on ran straight into this gap. reasoningThe proposal replaces an ambiguous signal with explicit, registered semantics. It adds a resource error-code table with a rate-limit code, separates the invocation meaning of 429 from polling slow_down, and requires a statement on Retry-After and what to do when it is absent. Full reasoning The proposal replaces an ambiguous signal with explicit, registered semantics. It adds a resource error-code table with a rate-limit code, separates the invocation meaning of 429 from polling slow_down, and requires a statement on Retry-After and what to do when it is absent. That is `A9`say it explicitly and `C12`explicit signals over inference directly: structured error codes and stated signals instead of making the agent guess. Separating polling cadence from resource capacity also fits `A6`separate the concerns strictly, which keeps distinct questions in distinct structures. The scope indicator (agent, user, or shared quota) is the kind of explicit signal the person would supply so the receiver doesn't have to infer. Deferring capacity-limited invocations via 202, with the existing replay rule stated explicitly, fits `P7` (decouple instead of block) and `P22` (recovery over simplicity). The divided `A11`tolerate the unrecognised finding (tolerate ambiguity vs strict semantics) doesn't cut against the item. The proposal keeps graceful handling (defer, back off, defined behavior when Retry-After is missing) and makes only the meaning of the signal strict, which is the pattern `P21`flexible except where mandatory predicts: tolerant by default, strict on specific points. A 429 carrying two meanings is also close to the 'polymorphic identifier' the record already rejects (F-98573ee1). what in the item it readSuggested direction items 1-5: 'A resource error-code table, with at least a rate-limit code', 'A scope indicator — whether the exhausted quota is attributable to this agent, to this user, or shared', 'Disambiguate 429', 'Retry-After requirements', and 'Worth stating explicitly that a resource MAY defer for capacity reasons and that the same replay requirement applies, so implementers do not have to infer it.' 13 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts activated, not named · 6`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts 1 contradiction identified 1 divided claim set aside as off-axis claim vs its own recorddick-aauth10:A11 divides on whether an ambiguous 429 should be tolerated and degraded through or given strict unambiguous registered semanticsmitigating evidenceits own cited facts, sorted for this action: 7 one side `F-565897b7F-641f9358F-e516ee69`+4 4 the other `F-98573ee1F-717d8d40F-8c8dfad1`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:C8 autonomy versus human control, not how a resource signals a capacity refusal 3 open points logged, did not change the decision *Divided `A11`tolerate the unrecognised: whether an ambiguous 429 should be tolerated and degraded through, or given strict registered semantics.did not change the decision: The proposal does both. It gives strict meaning to the signal and graceful agent behavior (defer, back off, handle a missing Retry-After). Side A's tolerance facts are about surviving unknowns, which the proposal keeps.The item leaves choices open: register the invocation meaning next to slow_down or use a different status, and whether Retry-After is REQUIRED.did not change the decision: Every branch it offers ends with explicit, unambiguous semantics, which is what the person's commitments require. Which branch to take is editorial, not a question of fidelity.The scope indicator tells the caller something about the resource's client arrangement and quota sharing. Under `C23`identifiers are opaque handles* and `P17`blocks cross context correlation the person is careful about what a signal reveals. Under `P12`treats all input as hostile agents should treat a resource's self-reported scope as untrusted input.did not change the decision: The indicator is a coarse category, not an identifier that can be correlated, and it goes to an agent already calling the resource. The spec text should note it is advisory, but that is a refinement, not grounds to deny. I108Pending grant lifetime, and key rotation across a pending grantAPPROVE Proposed action, in full · 286 words Problem (#pending-url-security) says only that pending URLs "SHOULD have limited lifetime." Day-scale human consent is a real deployment shape, and the draft states no relationship between the pending record's lifetime and the lifetimes of the tokens flowing through it. The sharp case is key rotation. Under bootstrap's two-key refresh, the agent's ephemeral key changes on every agent token refresh — so "same `sub`, different key" is the normal case over a multi-day consent window, not an anomaly. An agent token refreshes to a fresh key while a grant is pending, and the pending record is bound to the old key. Nothing says what happens next. Suggested direction Pick one and say it: The PS binds pending state to the durable (AP-verified) identity rather than the ephemeral key, or The agent MUST NOT rotate its key across a pending grant (which constrains bootstrap refresh timing), or Re-presentation with a new key under the same `sub` gets defined behavior — what the PS verifies before transferring the pending record to the new key, and what PoP guarantee survives that transfer. Whichever way, state the required relationship between pending-record lifetime and resource/auth token lifetimes. (#deferred-auth-token) already handles the expired-resource-token half; the pending-record half is unspecified. Note: honoring bare "any holder of a key for the same `sub` may collect" would demote PoP to identity-level — the answer has to preserve what `cnf` binding is for. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] This is one of the deployers' two priority asks for -11: their consent path routinely takes longer than an agent token lifetime. Natural home may be the personal PS profile (see companion issue), but the rotation semantics are protocol. reasoningThe operative ask is that the draft stop leaving a real failure mode unspecified. It must define what happens when an agent's key rotates while a grant is pending, and state how pending-record lifetime relates to resource and auth token lifetimes. Full reasoning The operative ask is that the draft stop leaving a real failure mode unspecified. It must define what happens when an agent's key rotates while a grant is pending, and state how pending-record lifetime relates to resource and auth token lifetimes. That is faithful to `A9`say it explicitly/`C12` (say it explicitly), `C4` (name the attack surface; the item names the risk of PoP being demoted to identity level), `C22` (let a human decision take as long as it takes while naming the friction), `P7`decouples when humans must wait, and `P22` (the design must let the waiting party recover). It also respects the person's hard floor. It says outright that 'any holder of a key for the same sub may collect' is unacceptable and that the answer 'has to preserve what cnf binding is for'. That is the `A1`proof not possession/`C3`verification over trust/`C15`flexibility with hard floors proof-of-possession line held, not relaxed. The coherence finding (day-scale pending vs short lifetimes) and the divided `A11`tolerate the unrecognised/`A15`interaction is asynchronous/`A20`autonomy versus control persists/`C15`flexibility with hard floors/`C22`asynchronous with known friction findings are about which resolution the spec should adopt. The item doesn't commit the spec to any one resolution. It requires a choice and a stated lifetime relationship, which is the layered expiry `A14`authority expires by default and `C21`time bounds instead of promises already favor. what in the item it read'Pick one and say it' over the three enumerated options, together with 'Whichever way, state the required relationship between pending-record lifetime and resource/auth token lifetimes' and the constraint 'the answer has to preserve what cnf binding is for.' 29 activated claims 13 named in the reasoning named in the reasoning · 13`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts activated, not named · 16`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts cited without activating · 1: no packet entry backs these`dick-aauth10:C12`Explicit Signals Over Inference10 factsdid not activate 6 contradictions identified 4 divided claims set aside as off-axis claim vs claimA15, C22, A4, C7 with, A14, C21 against: whether a pending consent record may persist on a day scale, past the lifetimes of the tokens flowing through itno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A11 divides on whether a PS meeting an unrecognised new key under the same sub should degrade and accept or refusemitigating evidenceits own cited facts, sorted for this action: 6 one side `F-4b4ebce6F-565897b7F-641f9358`+3 4 the other `F-8c8dfad1F-98573ee1F-717d8d40`+1claim vs its own recorddick-aauth10:A15 divides on whether a day-scale pending record is the deferred flow they want or the stored state they avoidmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-0d93d672F-14d17816F-993b99e5`+3 1 the other `F-071b0c3c`claim vs its own recorddick-aauth10:A20 divides on whether recovery of a pending grant across rotation is worth the added specification complexitymitigating evidenceits own cited facts, sorted for this action: 1 one side `F-b3ddfbd0` 1 the other `F-8da3426f`claim vs its own recorddick-aauth10:C15 divides on whether per-key proof-of-possession is a relaxable requirement or a floor that transfer to a new key would breachmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-565897b7F-641f9358F-c70241a5`+3 6 the other `F-161f3f8dF-17ab0502F-1c1b3c13`+3claim vs its own recorddick-aauth10:C22 divides on whether long-lived pollable pending state is acceptable against their preference for stateless verificationmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-0d93d672F-993b99e5F-5e9c8700`+3 4 the other `F-071b0c3cF-74e0ec63F-48c95aa0`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A4 silent authority versus cascading consent, not what a pending record binds to or how long it livesdick-aauth10:C10 record retention versus correlation, whereas this action turns on the binding target of a grantdick-aauth10:C20 bounds on onward delegation, which this single-agent rotation case does not raisedick-aauth10:C8 autonomy versus human control, not the mechanics of carrying a grant across rotation 5 open points logged, did not change the decision The menu omits the answer `C21`time bounds instead of promises most directly predicts: key rotation invalidates the pending grant and forces a fresh request ('key rotation forcing re-authorization'). Options 1 and 3 lean toward carrying the grant across keys, which pulls against `C21`time bounds instead of promises and the per-instance keyed-proof floor (`C15`flexibility with hard floors side B).did not change the decision: The approved action is 'define the behavior', not 'adopt option 1 or 3'. Option 2 and a rotation-forces-re-request answer both satisfy the item's own requirement to preserve cnf binding, so the item doesn't close off the resolution the person would likely pick. The eventual normative choice is a separate decision and should be checked against `C21`time bounds instead of promises when it is made.Coherence finding: `A15`interaction is asynchronous, `C22`asynchronous with known friction, `A4`human veto is non negotiable, `C7` (day-scale human consent is legitimate) against `A14`authority expires by default, `C21` (authority should lapse quickly) on whether pending records may outlive the tokens flowing through them.did not change the decision: The item doesn't ask for long-lived pending state. It asks for a stated relationship between the lifetimes, which is how the person manages this tension through layered expiry. The packet's `A14`authority expires by default evidence says the record 'already names the gap... rather than resolving it either way', and the item names it too.Divided `C15`flexibility with hard floors/`A11`tolerate the unrecognised: whether a PS meeting a new key under the same sub should accept it or refuse, and whether per-key PoP is a floor.did not change the decision: The item treats PoP as the floor and asks only that the non-floor behavior be specified. That is the `P21`flexible except where mandatory pattern and doesn't resolve the division against the person.Divided `A20`autonomy versus control persists: whether recovering a pending grant across rotation is worth the extra spec complexity.did not change the decision: Option 2 (no rotation across a pending grant) is a simple answer the item offers, so the item doesn't force added complexity. The trade-off stays open for the eventual choice.The item suggests the personal PS profile as the 'natural home' while saying the rotation semantics belong to the protocol.did not change the decision: Where the text lives is editorial and doesn't affect whether the action represents the person. I109Personal PS profile: the minimal single-person Person ServerAPPROVE Proposed action, in full · 216 words Problem The protocol already permits a minimal single-person PS — `issuer`, `auth_token_endpoint`, `person_token_endpoint`, `jwks_uri`, plus `interaction_endpoint` for consent; everything else in (#ps-metadata) is OPTIONAL — but no document says so. A reader sizing a self-hosted PS infers the full endpoint surface is required. Suggested direction A short profile document (informational, like bootstrap): the minimal metadata floor, no missions, no audit endpoint, no mission control, consent completed on whatever surface the person already reads (phone tap, chat message), one person per deployment. It is also the natural home for two protocol clarifications with their own issues, since a personal PS is where slow consent is the normal case rather than the exception: pending-grant lifetime and key rotation across a pending grant out-of-band interaction completion and the single-use code semantics A personal PS without a governance policy is a queue with a protocol on it; the profile should say how it composes with the governance policy work (separate issue) so it can answer routine requests without waking the person. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] One of the deployers' two priority asks for -11. Their existing "decision docket" is a valid backing store for this profile: the docket holds pending decisions, the phone tap resolves them, polling delivers the result. reasoningThe proposal fits this person well. It creates no new requirement; it writes down, in an informational profile routed through open review, a minimal PS that the protocol already permits (`A17`earned through open process, `A9`say it explicitly). Full reasoning The proposal fits this person well. It creates no new requirement; it writes down, in an informational profile routed through open review, a minimal PS that the protocol already permits (`A17`earned through open process, `A9`say it explicitly). It makes complexity optional and gives a zero-configuration, self-hosted starting point (`C13`complexity must be optional). It treats slow, pollable consent as the normal case (`A15`interaction is asynchronous, `C22`asynchronous with known friction, `P7`decouples when humans must wait). It keeps the cryptographic and transport floors (`C15`flexibility with hard floors: jwks_uri, HTTPS). It preserves the human's explicit approval on a surface they already use (`A4`human veto is non negotiable, `C7`human oversight as structure). It also ties itself to the governance-policy work so the PS is a decider rather than a bare queue, which keeps governance a separate layer (`A5`governance is its own layer). The coherence finding (`C9`accountability ends at person, `A5`governance is its own layer, `A7`accountability traces to persons against) raises whether a conformant PS may ship with no audit endpoint and no missions. The packet's resolution holds: with one person per deployment, every decision already traces to that one identifiable person. The profile drops an exposed endpoint, not the record itself; its named backing store, the docket, holds the decisions. The `C13`complexity must be optional split is over what counts as the simple case, and this profile exists to settle exactly that. what in the item it readThe suggested direction: 'A short profile document (informational, like bootstrap): the minimal metadata floor, no missions, no audit endpoint, no mission control, consent completed on whatever surface the person already reads ... one person per deployment', documenting a PS the Problem section says 'The protocol already permits'. 31 activated claims 12 named in the reasoning named in the reasoning · 12`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts activated, not named · 19`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P29`Names Autonomy Control Tension Unresolved14 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts 3 contradictions identified 8 divided claims set aside as off-axis claim vs claimC13, C15, C5 with, C9, A5, A7 against: whether a conformant PS may ship with no audit endpoint, no missions and no mission controlno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A7 divides on whether accountability permits a deployment that keeps no durable audit recordmitigating evidenceits own cited facts, sorted for this action: 3 one side `F-0ca5c63cF-31a34badF-95029c50` 8 the other `F-061a5376F-652efd28F-6bb0e92c`+5claim vs its own recorddick-aauth10:C13 divides on whether the single-person deployment is the simple case that may skip the machinerymitigating evidenceits own cited facts, sorted for this action: 8 one side `F-42750aaeF-3ccf1eadF-5ede3010`+5 2 the other `F-8488b23eF-a22050cc`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A15 its stateless fact concerns token verification, not held consent state, so every fact favours deferred consent heredick-aauth10:A2 a self-hosted single-person PS satisfies both the no-gatekeeper facts and the context-holding facts at oncedick-aauth10:A20 its facts are struggle statements with no position on whether a minimal profile may be documenteddick-aauth10:C10 not divided here: its privacy facts concern cross-resource identifier correlation, not whether one deployment keeps recordsdick-aauth10:C15 its hard floors are cryptographic and transport ones, which the profile's floor keeps (jwks_uri, HTTPS)dick-aauth10:C20 the action passes no authority onward, so the mediation split is not reacheddick-aauth10:C22 the friction facts name a struggle without taking a side, and the action decides deployment scope rather than polling mechanicsdick-aauth10:C6 the action does not move where a decision is made; the PS remains the decider for its one person 4 open points logged, did not change the decision `A7`accountability traces to persons, `C9`accountability ends at person and `P15`one name on the record: this person will not treat accountability as optional and arranges durable, timestamped records. The profile lists 'no audit endpoint' in its floor without saying what durable record of consent decisions and issued tokens remains.did not change the decision: The proposal omits an exposed endpoint, not record-keeping. Its named backing store (the docket) holds the decisions. With one person per deployment, attribution ends at that person, as the packet's answer notes. The profile would represent this person better by stating the retained record explicitly, but leaving that out of an issue's suggested direction does not misrepresent them.`C13`complexity must be optional is divided on whether a single-person deployment is the simple case that may skip the machinery.did not change the decision: The split is over what counts as the simple case, and the profile is the document that would define it. The side that favours skipping (progressive disclosure, no mandatory intermediaries, self-hosting) is far more heavily supported, and the dissenting facts concern OAuth shortcuts, not deployment scope.`A7`accountability traces to persons is also divided by privacy facts: short-lived keys, directed identifiers, and no long-term non-repudiation.did not change the decision: Those facts are about correlation across domains and about key persistence, not about whether one personal PS keeps records. `A7`accountability traces to persons names the conflict as unresolved in its own text.The two folded-in clarifications (pending-grant lifetime and key rotation, out-of-band completion) and the link to governance policy are only pointers.did not change the decision: They are handled in their own issues, and pointing to them fits the async and explicit-signalling claims. I110Define what a governance policy is — the decision procedure behind auth token issuance and requirement=clarificationAPPROVE Proposed action, in full · 259 words Problem (#policy-evaluation-points) says the PS decides "based on user consent and, when the agent is operating under a mission, the mission's intent and prior log entries against the PS's governance policy." Nothing defines what a governance policy is or how a PS reaches a decision. "Why Missions Are Not a Policy Language" explains what missions deliberately do not do, and no document picks up what does. `requirement=clarification` exists on the wire with no described decision procedure behind it. Suggested direction Start with the interface, not the policy language. The shape that fits without new protocol objects: the PS evaluates (or calls a governance service with) the mission, prior decisions under that mission, and the resource token; the result is granted, denied, or clarification required, with the warrant and the claims relied on. Each result maps onto an existing wire artifact — auth token issuance, denial, `requirement=clarification`. Two consequences worth stating even in a first pass: Consent tiers ("mechanical batch is pre-approved, judgment calls are per-item") are a governance-policy question, not a mission-syntax question. The PS holds the standing rule; the resource declares which operations are per-call (R3 (#operation-access-annotations)). Readers keep trying to put this split in the mission. A personal PS (separate issue) without this is a queue with a protocol on it; with it, it is a decider that answers routine requests without waking the person. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] One of the deployers' two priority asks for -11, and they have offered to be a first deployment. reasoningThe proposal treats governance as its own layer, separate from the machinery (`A5`governance is its own layer). It deliberately defines the interface before any policy language, and lets the PS either evaluate or call a governance service. Full reasoning The proposal treats governance as its own layer, separate from the machinery (`A5`governance is its own layer). It deliberately defines the interface before any policy language, and lets the PS either evaluate or call a governance service. That keeps open whether the decider is a person or an automated judge while still requiring a recorded result with a warrant and the claims relied on (`P28`keeps approver identity open, `A9`say it explicitly, `C9`accountability ends at person). Every outcome maps onto an existing explicit wire signal: issuance, denial, or requirement=clarification. That treats a question as a legitimate move in an ongoing exchange (`P30`treats authorisation as conversation) and adds no new protocol objects. Evaluation stays at the PS, the party holding full context, as the cited spec text already says. Meanwhile the R3 per-call annotation leaves the resource its own enforcement point (`C6`decentralize yet concentrate context, `P5`spreads authority then names one owner, `C19`separate conflated roles). The coherence finding (`C7`human oversight as structure, `C5`power is the real question against) and the `A4`human veto is non negotiable and `C8`autonomy against human control splits turn on whether a standing rule may settle routine requests without waking the person. This person's own record includes time-bounded standing approval and consent-fatigue reduction through scoped pre-approval, alongside the ban on silent authorization. The proposal keeps judgment calls per item, keeps mechanical batches under a rule the person holds, and lets the resource force per-call review. So it lives inside the tension this person maintains rather than resolving it against human control. what in the item it read'Start with the interface, not the policy language ... the result is granted, denied, or clarification required, with the warrant and the claims relied on. Each result maps onto an existing wire artifact', together with the consent-tier split 'mechanical batch is pre-approved, judgment calls are per-item' held at the PS, with the resource declaring per-call operations via R3. 39 activated claims 12 named in the reasoning named in the reasoning · 12`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts activated, not named · 27`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P29`Names Autonomy Control Tension Unresolved14 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P4`Plain Language Over Fixed Vocabulary12 facts`dick-aauth10:P6`Mediation Required And Refused9 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts 5 contradictions identified 9 divided claims set aside as off-axis claim vs claimA5, A9, C19 with, C7, C5 against: whether a standing decision procedure held at the PS should resolve routine requests in place of the person's judgmentno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A19 divides on whether the judgment must route through the PS or may rest with the resource and agentmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-914283f6F-8d907b74F-0de145f8`+2 2 the other `F-2779740bF-425f4dde`claim vs its own recorddick-aauth10:A4 divides on whether a standing rule may pre-approve a mechanical batch the person never sees per itemmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-3941348dF-6905183fF-da5053f6`+1 5 the other `F-df51060eF-f3c789f7F-2b89bf03`+2claim vs its own recorddick-aauth10:C6 divides on whether governance evaluation belongs at one context-holding party or distributed across independent partiesmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-aae731c5F-f4a44a4eF-061a5376`+2 6 the other `F-ed6af5afF-aaf39f88F-c761a49e`+3claim vs its own recorddick-aauth10:C8 divides on whether routine authorization may proceed without a per-request human gatemitigating evidenceits own cited facts, sorted for this action: 4 one side `F-e96c9e2cF-54222ab3F-3941348d`+1 4 the other `F-db4c9782F-dc5945d2F-0831ece4`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A13 the downstream scope-expansion fact is not reached; the action concerns issuance at one hopdick-aauth10:A15 all its facts favour a clarification-required outcome that resolves later; nothing opposesdick-aauth10:A2 not divided separately here: its split on this point is carried by the same pivot facts C6 already divides on, so it is one division under two claim idsdick-aauth10:A20 its facts are struggle statements with no position on defining a decision proceduredick-aauth10:A7 the action defines a decision interface and decides no retention or correlation question, which is where this record splitsdick-aauth10:C10 reliance on prior log entries is already in the cited spec text; the action adds no retention decisiondick-aauth10:C15 no cryptographic or transport floor is relaxed by defining an interfacedick-aauth10:C20 no authority is passed onward by this actiondick-aauth10:C22 its stateless fact concerns token verification, not the governance evaluation this action shapes 4 open points logged, did not change the decision `A4`human veto is non negotiable and `C8`autonomy against human control are divided on whether a standing rule may pre-approve a mechanical batch the person never sees item by item, and `C7`human oversight as structure prefers human contextual judgment over deterministic policy engines.did not change the decision: The proposal does not choose a deterministic policy language. It defines where a decision is produced and requires a warrant. The per-item human gate stays for judgment calls and for resource-declared per-call operations. This person's record already accepts a consent event that covers later acts without re-asking, so this is their standing tension, not a break from it.`P29`names autonomy control tension unresolved predicts they would explicitly record the loss of human control whenever a delegate gains latitude. The proposal frames the outcome positively ('answers routine requests without waking the person') without naming that cost.did not change the decision: This is a first pass at an interface, and the tension belongs in the document it produces. Leaving it out of an issue's suggested direction does not misrepresent the person the way deciding it against them would.`C6`decentralize yet concentrate context and `A19`mediation over direct contact are divided on whether governance judgment belongs at one context-holding party or spread across independent parties.did not change the decision: The proposal does not move where decisions are made; the spec already places them at the PS. R3 keeps a separate enforcement point at the resource, so both sides of the split keep a control point.`C4`adversarial by default: the proposal names no failure modes of automated standing decisions, such as a mechanical batch being used to smuggle judgment calls.did not change the decision: The item defines an interface shape, not a finished policy. Failure modes are expected in the drafted text and do not make the direction unfaithful. I111Interaction completion out of band: the PS completes on its own channel and the code is never presentedAPPROVE Proposed action, in full · 176 words Problem The interaction `code` is defined only in terms of the user arriving at the URL: "once the user arrives at the URL with a valid code, the code is consumed and cannot be reused," and the single-use rule in (#interaction-endpoint) is likewise keyed on arrival at the interaction URL. That does not describe a PS that completes the interaction on a channel it already controls — a phone tap, a chat approval — where the person never visits `url` and the code is never presented. Suggested direction State that a PS MAY complete an interaction on any channel it controls without the person visiting `url` or presenting `code`, and define what happens to the single-use code in that case (invalidated at completion; later presentation returns `invalid_code`). Polling already carries the completion signal, so this is a clarification plus code semantics, not a new mechanism. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] Belongs in the protocol, referenced from the personal PS profile (separate issue), where out-of-band completion is the normal case. reasoningNo coherence or contestation finding stands against this item. Letting the PS complete an interaction on a channel it already controls, and reporting completion through existing polling, matches this person's default of deferred, decoupled consent (`A15`interaction is asynchronous, `C22`asynchronous with known friction, `P7`decouples when humans must wait). Full reasoning No coherence or contestation finding stands against this item. Letting the PS complete an interaction on a channel it already controls, and reporting completion through existing polling, matches this person's default of deferred, decoupled consent (`A15`interaction is asynchronous, `C22`asynchronous with known friction, `P7`decouples when humans must wait). It keeps sensitive state off a URL passed through the agent (`P12`treats all input as hostile). The person still approves explicitly, just on another surface, so the human veto and the ban on silent authorization are untouched (`A4`human veto is non negotiable, `C7`human oversight as structure). The proposal also closes the gap the adversarial posture would flag: it states what happens to the unused single-use code (invalidated at completion) and gives later presentation an explicit error, invalid_code (`C4`adversarial by default, `A9`say it explicitly, `C12`explicit signals over inference). That keeps a stale code from being replayed after the interaction has finished, which fits short-lived authority that lapses (`A14`authority expires by default, `C21`time bounds instead of promises). It is framed as a clarification of existing mechanics, not a new mechanism, which suits the flexible-with-floors posture (`C15`flexibility with hard floors, `P21`flexible except where mandatory). what in the item it read'State that a PS MAY complete an interaction on any channel it controls without the person visiting url or presenting code, and define what happens to the single-use code in that case (invalidated at completion; later presentation returns invalid_code).' 29 activated claims 12 named in the reasoning named in the reasoning · 12`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts activated, not named · 17`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P6`Mediation Required And Refused9 facts cited without activating · 1: no packet entry backs these`dick-aauth10:C12`Explicit Signals Over Inference10 factsdid not activate No contradictions identified 9 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 its strict-form facts are cryptographic surfaces, not interaction code presentationdick-aauth10:A15 its out-of-band and no-sensitive-state-in-transit facts both favour completing off the URL; nothing in the record opposesdick-aauth10:A4 the person still explicitly approves, only on another surface, so the silent-authorization fact is not engageddick-aauth10:C10 invalidating a code decides no retention or correlation questiondick-aauth10:C15 no hard floor is touched; permitting an alternate completion channel is the flexibility side onlydick-aauth10:C20 no authority passes onward by this actiondick-aauth10:C22 the action leans on polling that the record already carries; its friction facts state a struggle, not a position againstdick-aauth10:C6 the PS already owns interaction completion; the action moves no decisiondick-aauth10:C8 the human remains the one who completes; autonomy is not extended 2 open points logged, did not change the decision `C4`adversarial by default and `P13`layers controls never one checkpoint: the proposal does not name how an out-of-band tap is bound to the specific pending interaction, or the risk of a person approving the wrong request on a separate surface (a confused-deputy or consent-phishing path). `P13`layers controls never one checkpoint also warns against a single channel serving as sufficient proof.did not change the decision: Only a channel the PS already controls and authenticates the person on is permitted, and completion is reported through the existing polling path. The binding detail belongs in the drafted text, and nothing in the record opposes the direction.`P27`withholds detail from strangers uneasily: whether a later invalid_code response tells an unauthenticated caller more than a uniform failure would.did not change the decision: invalid_code is already an existing error, and the proposal only adds the out-of-band case to when it applies. It reveals nothing new about capabilities. I113Cross-namespace key binding: say where an agent's other-keys attestation would liveAPPROVE Proposed action, in full · 200 words Problem An agent can be known in more than one key namespace: met over an x402 payment signature, recognized later by AAuth agent identity. Nothing binds the two, so "can pay" and "is the agent we have met" cannot be connected even when both facts are established. On payment-only routes, payment is the only identity, which conflates ability to pay with recognition. Suggested direction The coherent ask is an AP metadata or agent-token claim by which an agent identity attests to other public keys it controls, verifiable in both directions (the AAuth identity lists the x402 key; possession of the x402 key can be challenged). This is not protocol-draft scope, but the draft should spend a paragraph saying where it would live — likely a companion document — so the gap is acknowledged rather than rediscovered. Related but distinct from #71 (sharing activity and compromise signals): that is about parties exchanging signals, this is about one identity attesting to its own keys. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — their CR-8. Concrete case: an agent first seen paying over x402, later presenting an agent token; the deployment wants one reputation record, not two strangers. reasoningThe action is small: one paragraph acknowledging the gap and pointing to a companion document for the mechanism. It fits the commitment to saying things explicitly rather than leaving gaps to be rediscovered (`A9`say it explicitly, `C12`explicit signals over inference) and to routing new structures through reviewed, specification-based documents (`A17`earned through open process). Full reasoning The action is small: one paragraph acknowledging the gap and pointing to a companion document for the mechanism. It fits the commitment to saying things explicitly rather than leaving gaps to be rediscovered (`A9`say it explicitly, `C12`explicit signals over inference) and to routing new structures through reviewed, specification-based documents (`A17`earned through open process). It is grounded in a concrete deployment case (`C16`legitimacy through running code). The problem it names is a conflation this person would object to: on payment-only routes, ability to pay stands in for recognition (`A6`separate the concerns strictly). The suggested mechanism is proof-based and verifiable in both directions: the identity lists the key, and possession of the key can be challenged (`A1`proof not possession, `C3`verification over trust, `P2`demands proof not possession). The coherence finding (`C23`identifiers are opaque handles against) and the `A7`accountability traces to persons and `C10`audit versus privacy unresolved splits are about whether linking identities across key namespaces is correlation to be prevented or a trail to be kept. The action does not decide that. It places the question in a companion document, and the linking is self-attested by the agent rather than imposed by a third party. `C10`audit versus privacy unresolved's own balancing fact treats this as a per-deployment policy question, not a rule, which an optional self-issued attestation leaves to the deployer. what in the item it read'This is not protocol-draft scope, but the draft should spend a paragraph saying where it would live — likely a companion document — so the gap is acknowledged rather than rediscovered', describing an attestation 'verifiable in both directions'. 20 activated claims 10 named in the reasoning named in the reasoning · 10`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts activated, not named · 10`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts cited without activating · 1: no packet entry backs these`dick-aauth10:A9`Say It Explicitly16 factsdid not activate 3 contradictions identified 2 divided claims set aside as off-axis claim vs claimC12, A1, C3, C9 with, C23 against: whether one agent identity should be made linkable across key namespacesno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A7 divides on whether attribution across two key namespaces should be anchored durably or left unlinkablemitigating evidenceits own cited facts, sorted for this action: 5 one side `F-652efd28F-81f343d1F-ed0f9803`+2 5 the other `F-31a34badF-95029c50F-0ca5c63c`+2claim vs its own recorddick-aauth10:C10 divides on whether one reputation record across namespaces is correlation to be prevented or a trail to be keptmitigating evidenceits own cited facts, sorted for this action: 2 one side `F-127f28a2F-1b082c00` 4 the other `F-31a34badF-95029c50F-16955367`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 its polymorphic-identifier and key-coexistence facts split on mechanism, which this action defers to a companion documentdick-aauth10:C8 the action decides nothing about autonomy or human control 3 open points logged, did not change the decision `C23`identifiers are opaque handles and `P17`blocks cross context correlation: namespace isolation and refusal of identifiers that link activity across contexts point against making one agent linkable across key namespaces.did not change the decision: The action only says where a mechanism would live. `P17`blocks cross context correlation targets linking a person or device across separate parties, whereas this is an agent choosing to attest to its own keys so that one deployment can keep one record. Whether and how to limit that linkage is left to the companion document.`A7`accountability traces to persons and `C10`audit versus privacy unresolved are divided between durable attribution across namespaces and preventing correlation.did not change the decision: `A7`accountability traces to persons names this conflict as unresolved in its own text, and `C10`audit versus privacy unresolved calls for active balancing rather than a default. An acknowledging paragraph that settles neither side is consistent with both.`C4`adversarial by default: the proposal does not name failure modes such as an agent claiming a key it does not control, or linkage exposing an agent's payment history.did not change the decision: The two-way verification requirement already covers the key-claiming threat, and the full threat analysis belongs in the companion document, which this action only points to. I115Bootstrap: many agents, one operator — self-hosted key layout and custodyAPPROVE Proposed action, in full · 231 words Problem Bootstrap (#self-hosted-agents) assumes one agent per domain: a single key serves as both the AP signing key and the agent's `cnf` key. The common self-hosted shape is many agents, one operator — one domain running N distinct agents (per-lane, per-task) under one self-hosted AP. The document does not cover it, and readers get the key model wrong: the reviewed deployment planned to publish per-agent keys in the JWKS, reading "each agent holds a signing key published at a well-known URL" out of the current text. Suggested direction Add the many-agents-one-operator layout to (#self-hosted-agents): one AP signing key, published in the JWKS the AP self-issues N agent tokens with distinct `sub` and distinct `cnf` keys agent keys are NOT published — they appear only in `cnf.jwk` of each agent token custody guidance: where the per-agent keys live (per-lane signing proxy, per-process keystore), and that compromise of one agent key is contained to that `sub` while compromise of the AP key mints identities for the whole domain Mostly this is stating the AP-key/agent-key distinction the protocol already makes, in the place self-hosters actually read. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — the custody half of their CR-4, which they call the single most useful bootstrap addition. Their deployment is exactly this shape: ~ten lane agents, lane keys in signing proxies, one domain. reasoningThe proposal separates two roles the protocol already distinguishes: one AP signing key published in the JWKS, and per-agent `cnf` keys that are never published. That is `A6`separate the concerns strictly and `C19` (keep distinct concerns in distinct structures) applied to key custody. Full reasoning The proposal separates two roles the protocol already distinguishes: one AP signing key published in the JWKS, and per-agent `cnf` keys that are never published. That is `A6`separate the concerns strictly and `C19` (keep distinct concerns in distinct structures) applied to key custody. It names the attack surface directly, as `C4`adversarial by default expects: compromising one agent key affects only that `sub`, while compromising the AP key mints identities for the whole domain. Custody in per-lane signing proxies gives the independent, layered containment `P13`layers controls never one checkpoint predicts. Distinct `sub` and `cnf` per agent keep proof-of-possession per agent (`A1`proof not possession, `P2`demands proof not possession) and attribution per agent (`C9`accountability ends at person, `P15`one name on the record). It comes from a real deployment that got this wrong from the current text (`C16`legitimacy through running code) and moves through the open issue process (`A17`earned through open process). There are no coherence findings, and all six contestation candidates were ruled not on this point. what in the item it read"agent keys are NOT published — they appear only in `cnf.jwk` of each agent token" and "compromise of one agent key is contained to that `sub` while compromise of the AP key mints identities for the whole domain" 23 activated claims 10 named in the reasoning named in the reasoning · 10`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:A17`Earned Through Open Process5 facts activated, not named · 13`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts No contradictions identified 6 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A2 inter-party gatekeeping and pre-registration, which a single operator's internal key layout does not raisedick-aauth10:A7 durable records versus minimised traceability; only the per-account side (F-6bb0e92c) speaks to distinct agent subs, nothing answers againstdick-aauth10:C10 user pseudonymity versus audit retention, not agent key custodydick-aauth10:C13 what a newcomer must do first; this action adds no prerequisite, it states an existing key distinctiondick-aauth10:C20 mandatory mediation in delegation, not sibling agents' key custody under one providerdick-aauth10:C8 autonomy versus human control, which a key layout does not turn on 2 open points logged, did not change the decision *A single AP key that can mint identities for the whole domain concentrates power (`C5`power is the real question, `A2`no single central authority).did not change the decision: The proposal does not create this concentration; the protocol's AP model already has it. The proposal states it openly as a named compromise consequence, which is what `C4`adversarial by default* asks for. `A2`no single central authority was ruled not on this point because the layout is internal to one operator and involves no gatekeeping between parties.`A7` (durable records versus minimised traceability) was examined.did not change the decision: Only the per-account side (F-6bb0e92c) applies, and it supports distinct per-agent subs. Nothing on the other side answers it. I116Bootstrap: sub-agent token acquisition is deferred here but not coveredAPPROVE Proposed action, in full · 128 words Problem The protocol defers sub-agent token acquisition to bootstrap: "Acquisition of a sub-agent token from the agent provider is platform-dependent and is described in [@?I-D.hardt-aauth-bootstrap], parallel to top-level agent token acquisition" ((#sub-agents)). Bootstrap does not cover it. The pointer dangles. Suggested direction Add a sub-agent acquisition section to bootstrap. For the self-hosted case the answer is one paragraph: the operator's self-hosted AP is the parent's AP and self-issues the sub-agent token (`sub` with the `+` delimiter, `parent_agent` claim, fresh `cnf` key) exactly as it self-issues top-level tokens. The hosted-AP case (parent requests a sub-agent token from its AP) needs its own short pattern. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] Pairs with the many-agents-one-operator issue — same section of bootstrap, same self-issue mechanics. reasoningThe item repairs a dangling normative reference. (#sub-agents) already assigns sub-agent token acquisition to the agent provider, 'parallel to top-level agent token acquisition', and points to bootstrap, which does not cover it. Full reasoning The item repairs a dangling normative reference. (#sub-agents) already assigns sub-agent token acquisition to the agent provider, 'parallel to top-level agent token acquisition', and points to bootstrap, which does not cover it. The suggested content restates mechanics the protocol already has. The sub-agent gets a fresh `cnf` key, so it signs for itself (`P18`every hop signs for itself, `A1`proof not possession). The `parent_agent` claim and `+`-delimited `sub` keep the parent-child chain explicit and traceable (`A13`delegation must be bounded, `C20`delegation must stay bounded, `C9`accountability ends at person). The hosted-AP case has the parent request the token, which keeps the parent in the path. It is grounded in a deployment review (`C16`legitimacy through running code) and handled as an open issue (`A17`earned through open process). Adding the section is consistent with how the person already built delegation. what in the item it read"Acquisition of a sub-agent token from the agent provider is platform-dependent and is described in [@?I-D.hardt-aauth-bootstrap] ... Bootstrap does not cover it. The pointer dangles." together with "self-issues the sub-agent token (`sub` with the `+` delimiter, `parent_agent` claim, fresh `cnf` key) exactly as it self-issues top-level tokens" 28 activated claims 5 named in the reasoning named in the reasoning · 5`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C9`Accountability Ends At Person28 facts activated, not named · 23`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts cited without activating · 2: no packet entry backs these`dick-aauth10:C16`Legitimacy Through Running Code8 factsdid not activate`dick-aauth10:A17`Earned Through Open Process5 factsdid not activate 3 contradictions identified 7 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A4 divides on whether spawning and credentialing a sub-agent needs a fresh human approval or is covered by consent to the parentmitigating evidenceits own cited facts, sorted for this action: 3 one side `F-3941348dF-e96c9e2cF-da5053f6` 6 the other `F-df51060eF-3490df53F-0f167199`+3claim vs its own recorddick-aauth10:C20 divides on whether a sub-agent token may be issued straight by the AP or must route through the parentmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-ac162c1cF-22f2a7d5F-0de145f8`+2 2 the other `F-2779740bF-a3095e3d`claim vs its own recorddick-aauth10:C8 divides on whether a sub-agent may be minted autonomously or requires a control point at each spawnmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-3941348dF-54222ab3F-e96c9e2c`+1 5 the other `F-7d67edb7F-5d952808F-dc5945d2`+2set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A13 downstream scope expansion, which this acquisition path does not touchdick-aauth10:A15 deferred versus synchronous decisions; token acquisition mechanics raise no waiting questiondick-aauth10:A2 whether a third party must be asked first; here no independent party is involveddick-aauth10:A7 audit durability versus minimised traceability, not how a token is obtaineddick-aauth10:C10 privacy versus logging, which this acquisition section does not raisedick-aauth10:C13 prerequisites before value; the action documents a path rather than imposing onedick-aauth10:C6 concentration of governance context, not the issuance path for a sub-agent token 4 open points logged, did not change the decision *`A4`human veto is non negotiable* is divided on whether spawning and credentialing a sub-agent needs fresh human approval or is covered by consent to the parent.*did not change the decision: The mitigating evidence shows the claim's own facts hold both positions, and `P19`parent consent covers children* predicts that parent consent covers children. More importantly, this item governs how an identity token is obtained, not how resource authority is granted. Consent at the PS still applies whenever the sub-agent seeks access, so no silent authorisation over resources is introduced.`C20`delegation must stay bounded is divided on whether the AP may issue a sub-agent token directly or it must route through the parent.did not change the decision: The parent-mediation facts (F-ac162c1c, F-22f2a7d5) concern sub-agents contacting authorization servers, not the agent provider. The protocol already names the AP as the issuer. In the self-hosted case the operator's AP is the parent's own AP, the simple case where F-2779740b declines to mandate intermediaries. The hosted pattern keeps the parent in the path.`C8`autonomy against human control is divided on whether a sub-agent may be minted autonomously or needs a control point at each spawn.did not change the decision: `C8`autonomy against human control is the person's standing, deliberately unresolved tension, not something this item should settle. The item keeps the protocol's existing parent-control structure (the `parent_agent` claim) and adds no new autonomy.The hosted-AP pattern is only gestured at ('needs its own short pattern'), and parent revocation is not restated in the self-hosted paragraph.did not change the decision: This is a direction for an issue, not final text, and revocability already comes from (#sub-agents). It is something to check when the section is drafted, not a reason to block closing the gap. I117State the minimal conformant PS floor in ps-metadataAPPROVE Proposed action, in full · 133 words Problem A conformant PS is four metadata fields — `issuer`, `auth_token_endpoint`, `person_token_endpoint`, `jwks_uri` — plus `interaction_endpoint` if it wants consent. `mission_endpoint`, `permission_endpoint`, `audit_endpoint`, `mission_control_endpoint` are all OPTIONAL. (#ps-metadata) marks each field's requirement level but never says "this is the floor," so readers sizing an implementation infer the full endpoint surface is required and conclude a PS is a big build. Suggested direction One or two sentences in (#ps-metadata): the minimal conformant PS is the four REQUIRED fields; a PS that issues tokens and nothing else is conformant; the optional endpoints add missions, permission checks, and audit, not conformance. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — the main ask of their CR-6 once the redirect misreading is set aside. Also the premise of the personal PS profile issue. reasoningThe item changes no requirement level. It states in one place what (#ps-metadata) already implies field by field: four REQUIRED fields, with the mission, permission, audit and mission-control endpoints OPTIONAL. Full reasoning The item changes no requirement level. It states in one place what (#ps-metadata) already implies field by field: four REQUIRED fields, with the mission, permission, audit and mission-control endpoints OPTIONAL. That is `C13`complexity must be optional's progressive disclosure stated plainly, where the elaborate machinery is opt-in rather than a precondition, and it is supported by F-5ede3010, F-436a0042 and F-2779740b (no mandatory full deployment, no requirement that all parties implement all modes). The misreading it corrects comes from real implementers sizing a build, and the fix goes through open review (`A17`earned through open process). `C3`verification over trust, `C4`adversarial by default and `C5`power is the real question are not undermined: token issuance, JWKS and proof-of-possession verification stay mandatory, which is the strict core `P21`flexible except where mandatory predicts inside an otherwise accommodating design. what in the item it read"the minimal conformant PS is the four REQUIRED fields; a PS that issues tokens and nothing else is conformant; the optional endpoints add missions, permission checks, and audit, not conformance." 7 activated claims 6 named in the reasoning named in the reasoning · 6`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts activated, not named · 1`dick-aauth10:P2`Demands Proof Not Possession28 facts 1 contradiction identified claim vs its own recorddick-aauth10:C13 divides on whether a token-issuing-only PS is the legitimate simple case or too thin to countmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-42750aaeF-5ede3010F-436a0042`+3 3 the other `F-8488b23eF-a22050ccF-3ccf1ead` 2 open points logged, did not change the decision `C13`complexity must be optional is divided on whether a PS that only issues tokens is the legitimate simple case or too thin to count. Side B's facts (F-a22050cc) rule out some simple shapes for bypassing oversight.did not change the decision: The division is about which simple shapes the person accepts, and they already decided this one when they marked those endpoints OPTIONAL. The item neither demotes any requirement nor introduces a mechanism that bypasses resource oversight; it only makes an existing floor readable. Side B's objection targets authorization codes and refresh tokens, not a PS with optional governance endpoints.The wording 'plus `interaction_endpoint` if it wants consent' and 'add ... audit, not conformance' could be read as downplaying oversight.did not change the decision: The claims activated for this item do not include the oversight anchors, and the statement accurately reflects the existing requirement levels. If it matters, the drafting could note what a floor-only PS gives up, but that does not stop stating the floor. I118Warn that policy keyed on the agent identifier does not survive across access modesAPPROVE Proposed action, in full · 224 words Problem In agent identity mode a resource verifies the agent token and sees `sub`, so it is natural to key resource-side policy on the agent identifier (identifier → allowlist). That policy does not survive the move to auth tokens: an auth token deliberately carries no agent identifier and no delegation chain ((#why-no-agent-identifier), added in -11), and the resource enforces against `sub` (the person), `scope`, and `r3_granted`. Nothing in the draft warns that policy pinned to the agent identifier has to be re-expressed as scopes or R3 operations before those endpoints leave agent identity mode. This is the failure mode a real deployment walked into: a per-agent label allowlist at the resource, designed in agent identity mode, silently unenforceable in their planned auth-token phase. Neither of their own review passes noticed; the design reads fine until you know where agent identity stops flowing. Suggested direction A short paragraph in (#resource-access-modes) or (#why-no-agent-identifier), addressed to resource implementers: agent identity mode is the only mode in which the agent identifier reaches you; if your authorization decisions use it, they are mode-local by construction; express durable per-operation policy as scope or R3 operations, which flow in every mode. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — the most consequential finding of the review, and as much a doc failure as a reader failure. reasoningThis is the person's own adversarial habit (`C4`adversarial by default, `P13`layers controls never one checkpoint) applied to their own design. It names a concrete failure mode, policy that becomes silently unenforceable, that followed from the -11 decision to keep the agent identifier out of auth tokens, and one a real deployment walked into (`C16`legitimacy through running code). Full reasoning This is the person's own adversarial habit (`C4`adversarial by default, `P13`layers controls never one checkpoint) applied to their own design. It names a concrete failure mode, policy that becomes silently unenforceable, that followed from the -11 decision to keep the agent identifier out of auth tokens, and one a real deployment walked into (`C16`legitimacy through running code). The advice fits `A6`separate the concerns strictly and `C23`identifiers are opaque handles: the agent identifier is a handle that does not reach the resource in every mode, so durable authorization should rest on structures that do flow (`scope`, R3 operations, the person `sub`), not on an identifier that is only present locally. It fits `A3`nothing is two party's requirement that multiple access modes coexist, and `A5`governance is its own layer's treatment of governance as its own layer. It changes no flow; it tells resource implementers where agent identity stops. what in the item it read"agent identity mode is the only mode in which the agent identifier reaches you; if your authorization decisions use it, they are mode-local by construction; express durable per-operation policy as scope or R3 operations, which flow in every mode." 28 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts activated, not named · 21`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts 2 contradictions identified 6 divided claims set aside as off-axis claim vs claimA6, C23, A16 with, C9, C20 against: whether a resource may rest authorization and records on the agent identifierno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A7 divides on whether per-agent enforcement at the resource is required or agent-supplied identifiers must not drive decisionsmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-706eeacaF-72aade66F-6bb0e92c`+1 4 the other `F-95029c50F-7d673d60F-31a34bad`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A19 whether intermediaries are mandatory, not which identifiers reach the resourcedick-aauth10:A4 human veto and cascading consent, absent from this warningdick-aauth10:C10 privacy versus logging; its only affirmative fact (F-127f28a2) asks for comprehensive trails, which does not require the agent identifier at the resourcedick-aauth10:C20 bounded delegation; its facts point one way here (agent identity is essential), so it is a side rather than a divisiondick-aauth10:C6 where decisions are made, not how policy is expressed across modesdick-aauth10:C8 autonomy versus human control, which mode-local policy does not turn on 3 open points logged, did not change the decision *The coherence finding puts `C9`accountability ends at person* and `C20` (full delegation-chain visibility, per-agent accountability) against resting resource decisions off the agent identifier.*did not change the decision: That conflict belongs to the earlier (#why-no-agent-identifier) decision, which this item documents and does not make. The warning adds no traceability loss. It stops implementers from relying on per-agent enforcement that is already absent in auth-token mode, which serves accountability better than a silent gap. Chain visibility still sits with the party holding full context (`P5`spreads authority then names one owner, F-706eeaca).`A7`accountability traces to persons* is divided on whether per-agent enforcement at the resource is required or agent-supplied identifiers must not drive decisions.did not change the decision: The mitigating evidence shows the claim's own facts hold both positions. The item takes no side on whether per-agent enforcement is desirable; it states where it is possible. A resource that truly needs per-agent policy can still read the warning as telling it to stay in agent identity mode or rely on upstream enforcement.Per-agent restrictions cannot always be re-expressed as scopes, and the suggested text does not say where such policy should live instead, for example at the PS.did not change the decision: The item is scoped to per-operation policy, and adding a pointer to upstream enforcement would be a drafting refinement, not a correction of the direction. Omitting it does not misrepresent the person. I119The person-token-before-resource-token prerequisite is stated once and easy to missAPPROVE Proposed action, in full · 164 words Problem "A resource MUST have verified a person token before it issues a resource token" is stated once, in prose, in the person token section. A reader focused on resource tokens — following the 401 → resource token → PS token endpoint path — can build the whole flow without ever meeting the requirement. A real deployment's writeup did exactly that: both their numbered flow and their wire trace go straight from 401 to resource token with no person token, and they had read the draft carefully. Suggested direction Restate the prerequisite where those readers are: in the resource token issuance requirements, and in the flow overview's step list. Possibly one line in the `AAuth-Requirement`/challenge section too, since that is where the 401 path starts. This may fold into #103 (moving the person token endpoint into §8) — filing separately so the visibility problem is tracked even if the restructure lands differently. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] reasoningThe proposal takes an existing MUST (verify a person token before issuing a resource token) and restates it where readers of the resource-token path will actually see it. `A9`say it explicitly and `C12`explicit signals over inference treat stating requirements outright as an obligation, and they count leaving the reader to infer a requirement as a failure. Full reasoning The proposal takes an existing MUST (verify a person token before issuing a resource token) and restates it where readers of the resource-token path will actually see it. `A9`say it explicitly and `C12`explicit signals over inference treat stating requirements outright as an obligation, and they count leaving the reader to infer a requirement as a failure. The deployment evidence shows careful readers really did miss it. `A1`proof not possession, `C3`verification over trust and `C4`adversarial by default also favour this: a resource that skips person-token verification would issue resource tokens on trust it never checked, so making the prerequisite hard to miss supports proof over assumption. No gate is added, removed or moved. The requirement just becomes easier to see. what in the item it read"Restate the prerequisite where those readers are: in the resource token issuance requirements, and in the flow overview's step list. Possibly one line in the AAuth-Requirement/challenge section too" 19 activated claims 5 named in the reasoning named in the reasoning · 5`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts activated, not named · 14`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts No contradictions identified 4 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A4 whether one consent event cascades downstream, not the visibility of the person token stepdick-aauth10:C20 whether person server mediation is required at all, not where an existing MUST is printeddick-aauth10:C22 deferred versus stateless interaction, untouched by restating a prerequisitedick-aauth10:C8 autonomy versus oversight; the action moves no gate, only its placement 2 open points logged, did not change the decision The proposal notes it may fold into #103 (moving the person token endpoint into §8), so the final placement depends on a restructure that is still open.did not change the decision: The action is to make the requirement visible wherever it ends up. That holds however #103 lands, and the proposer filed it separately for exactly that reason.`P6`mediation required and refused says this person sometimes mandates mediation and sometimes refuses it, and the packet notes `C20`delegation must stay bounded on whether person server mediation is required at all.did not change the decision: The contestation findings rejected these as off this point. The proposal only reprints an existing MUST and does not reopen whether the person server step should exist. I121Mission-bound token expiry cannot be derived by the Resource or Access ServerAPPROVE Proposed action, in full · 272 words Problem The mission rules require every token carrying `mission_s256` to expire no later than the mission's `expires_at`, and require each issuer to shorten the token lifetime accordingly ([`a99d353`, line 1623]([link] The Person Server can satisfy this for a Person token because it holds the mission ([line 721]([link] The next issuers cannot derive the same ceiling: A Resource copies `mission_s256` from the Person token, but receives neither the mission blob nor `expires_at`. It must nevertheless cap its Resource token at the mission expiry ([lines 1024 and 1030]([link] In four-party access, the Access Server receives the Resource token and the digest, but not the mission expiry. It must nevertheless cap its Auth token at that expiry ([lines 1993–2000]([link] No rule requires either downstream token to inherit the earlier expiration. A literal implementation therefore cannot satisfy the mission-expiry requirement from its authenticated inputs. Example A mission expires in one minute. The PS correctly issues a Person token expiring in one minute. The Resource's ordinary five-minute Resource-token lifetime then violates the mission rule unless the Resource independently knows the mission expiry. The same problem repeats when an Access Server issues the Auth token. Suggested direction Make the ceiling transitive instead of exposing the private mission: A Resource token carrying `mission_s256` must not outlive the authenticated Person or Auth token from which that mission binding was copied. An Auth token carrying `mission_s256` must not outlive the Resource token from which the binding was copied. The PS already caps the first Person token at `expires_at`, so these two rules propagate the bound without disclosing the mission blob or adding a claim. reasoningThe proposal closes a real gap: downstream issuers are told to cap tokens at the mission expiry but cannot see it. It closes the gap by making the ceiling transitive, so no party receives the private mission blob. Full reasoning The proposal closes a real gap: downstream issuers are told to cap tokens at the mission expiry but cannot see it. It closes the gap by making the ceiling transitive, so no party receives the private mission blob. This fits `A14`authority expires by default and `C21`time bounds instead of promises, where authority lapses by layered expiry and short lifetimes are a main safeguard. It fits `A13`delegation must be bounded's requirement that onward authority be capped, backed by F-8862bd78 and F-c2d5ab81. It fits `A16`self contained verification and `P32`avoids live dependence at check time, because each issuer can derive the bound from the authenticated token in front of it without a live lookup. `C23`identifiers are opaque handles and `C10`audit versus privacy unresolved are also satisfied, since no claim is added and no mission content is disclosed. It keeps `C3`verification over trust's preference for verifiable inputs over an issuer 'independently knowing' something. what in the item it read"Make the ceiling transitive instead of exposing the private mission: A Resource token carrying mission_s256 must not outlive the authenticated Person or Auth token from which that mission binding was copied. An Auth token carrying mission_s256 must not outlive the Resource token from which the binding was copied." 32 activated claims 8 named in the reasoning named in the reasoning · 8`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C3`Verification Over Trust19 facts activated, not named · 24`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts 1 contradiction identified 8 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A13 divides on whether a downstream token must stay inside the limits of the grant it was derived from or may exceed themmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-8862bd78F-c2d5ab81F-7d67edb7`+2 1 the other `F-dc24102c`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 degradation on unrecognised input; the ceiling is derivable from authenticated inputsdick-aauth10:A15 deferred interaction, not expiry inheritancedick-aauth10:A20 names the downstream autonomy versus upstream constraint tension without answering it for lifetimedick-aauth10:A4 the consent cascade, not the lifetime ceilingdick-aauth10:C10 records and identifiers; the proposal discloses no mission blob and adds no claimdick-aauth10:C20 mediation and revocability, not whether expiry is inheriteddick-aauth10:C6 where a decision is made; the ceiling propagates without relocating any decisiondick-aauth10:C8 the standing autonomy versus control tension, not the expiry rule 2 open points logged, did not change the decision `A13`delegation must be bounded is divided: F-dc24102c accepts downstream scope growing past the upstream grant in multi-hop scenarios, which could be read as allowing downstream tokens to exceed upstream limits.did not change the decision: That record is about scope, not lifetime. The mission-expiry ceiling is already a MUST in the spec, and the proposal only makes it satisfiable. Five side-A facts back capping downstream tokens at the inherited bound.`A20`autonomy versus control persists and `C8`autonomy against human control name the standing tension between downstream autonomy and upstream constraint.did not change the decision: The packet found them off this point. The proposal moves no decision and only lets an existing lifetime rule propagate. I122Budgets: an omitted PS ceiling is indistinguishable from extension non-participationAPPROVE Proposed action, in full · 262 words Problem In four-party access, the PS-to-AS `budget` parameter is optional ([`a99d353`, line 545]([link] When the Resource token carries a Budget and the PS omits that parameter, the AS must treat the Resource's Budget as the PS's ceiling ([line 566]([link] That makes two materially different cases identical on the wire: The PS understands Budgets and deliberately grants the Resource's full offer. The PS does not implement or recognize the Budgets extension, ignores the Resource-token claim, and forwards the ordinary token request without a `budget` parameter. In both cases the AS is required to issue against the Resource's full offer. The second case silently upgrades extension non-participation into the maximum Budget grant. This is especially surprising because the base protocol's extensibility posture tells recipients to ignore fields they do not recognize. Example The Resource token offers USD 10. A Budget-aware PS would grant USD 2. A PS that has not implemented this extension ignores the Budget claim and sends no `budget` parameter. The AS interprets the omission as an explicit USD 10 ceiling and may issue the full amount. Suggested direction Require an affirmative PS value in four-party access: when a Resource token contains `budget`, the AS may include a Budget in its Auth token only when the PS-to-AS request also contains `budget`. Omission should produce no Budget grant or a defined error, rather than accepting the Resource's offer. That preserves ordinary extension negotiation: a PS that does not understand Budgets cannot accidentally authorize one, while a PS that wants to grant the full offer can echo it explicitly. reasoningToday a PS that does not recognise the Budgets extension, and so says nothing, is read as granting the Resource's full offer. That is authority by silence, which `A4`human veto is non negotiable, `C7`human oversight as structure and `P3`inserts the human back in rule out, and inference instead of a stated signal, which `A9`say it explicitly and `C12`explicit signals over inference treat as a failure mode. Full reasoning Today a PS that does not recognise the Budgets extension, and so says nothing, is read as granting the Resource's full offer. That is authority by silence, which `A4`human veto is non negotiable, `C7`human oversight as structure and `P3`inserts the human back in rule out, and inference instead of a stated signal, which `A9`say it explicitly and `C12`explicit signals over inference treat as a failure mode. The fix requires an affirmative budget value from the PS before the AS grants a Budget. That puts the ceiling decision with the party representing the person (`C19`separate conflated roles, `P5`spreads authority then names one owner). It also gives `C3`verification over trust and `P12`treats all input as hostile what they want: no grant rests on an unverified assumption about what the other side meant. It fits `A11`tolerate the unrecognised's tolerance too, since a non-participating PS degrades to no Budget grant, not to a silent maximum grant. what in the item it read"Require an affirmative PS value in four-party access: when a Resource token contains budget, the AS may include a Budget in its Auth token only when the PS-to-AS request also contains budget. Omission should produce no Budget grant or a defined error, rather than accepting the Resource's offer." 36 activated claims 10 named in the reasoning named in the reasoning · 10`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts activated, not named · 26`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P29`Names Autonomy Control Tension Unresolved14 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts 1 contradiction identified 8 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A11 divides on whether a party that has not implemented an extension may be read as granting it by silence or must signal participation affirmativelymitigating evidenceits own cited facts, sorted for this action: 4 one side `F-c70241a5F-717d8d40F-8c8dfad1`+1 6 the other `F-fdddc32cF-565897b7F-641f9358`+3set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A13 downstream scope expansion, not whether an omitted parameter counts as a grantdick-aauth10:A15 deferred interaction, not the presence of a request parameterdick-aauth10:A2 gatekeeping and pre registration; the person server is already in the four party pathdick-aauth10:A20 autonomy versus oversight, not the reading of an omissiondick-aauth10:A4 whether a real human consent event covers later steps, not whether a missing machine parameter authorises anythingdick-aauth10:C20 mediation and revocability, not extension negotiationdick-aauth10:C6 where the decision sits; the person server already decides and the proposal only requires it to say sodick-aauth10:C8 autonomy versus control, not silence as grant 2 open points logged, did not change the decision *`A11`tolerate the unrecognised* is divided: side B's facts (tolerating unrecognised parameters, flexible adoption, legacy survival) could be read as favouring the current permissive default.*did not change the decision: The packet notes that side B is the posture that produces the silent maximum grant. Under the proposal, a PS ignoring an extension it does not know still degrades gracefully, to no Budget, so tolerance is kept without turning silence into a grant. `P21`flexible except where mandatory* expects firm floors on exactly this kind of point.The proposal leaves open whether omission yields no Budget grant or a defined error.did not change the decision: Either outcome removes the silent upgrade, which is what this verdict turns on. Choosing between graceful omission (`A11`tolerate the unrecognised) and an explicit error (`A9`say it explicitly) can be settled in the drafting. I123No error code for the PS reporting an unreachable or failed AS to the agentAPPROVE Proposed action, in full · 256 words Context In four-party Federated Authorization Access, the PS calls the AS's `auth_token_endpoint` on the agent's behalf (§PS-AS Federation). When that call fails — the AS is unreachable, times out, returns malformed responses, or the returned auth token fails Auth Token Delivery verification — the PS has to answer the agent's pending token request with something, but the Token Endpoint Error Codes table has no value for this class of failure. `invalid_resource_token` is wrong (the token was fine), `server_error` is misleading (the PS did not fail), and passing the AS's problem+json through verbatim conflates "the AS denied you" with "the PS could not complete federation". Proposal Add to §Token Endpoint Error Codes, for PS token endpoints: \| Error \| Status \| Meaning \| \|-------\|--------\|---------\| \| `as_unreachable` \| 502 \| The PS could not obtain an auth token from the access server named by the resource token's `aud` — connection failure, timeout, or a malformed/unverifiable response. The agent MAY retry with a fresh resource token after a backoff. \| Distinct from an AS denial: when the AS returns a well-formed terminal error (e.g. `403`), the PS SHOULD propagate that outcome to the agent rather than reporting `as_unreachable`. The spec could also say explicitly what the PS relays on AS denial — today nothing normative covers the PS→agent leg of a failed federation. Encountered while Implementing AS federation in a PS (Hellō Wallet) against the reference AS at access.aauth.dev, mapping every branch of the §Deferred Responses state machine to a response on the agent's pending request. reasoningAdding a structured error code for the PS-to-agent leg of a failed federation is what `A9`say it explicitly and `C12`explicit signals over inference require: errors signalled outright with structured codes, and no party left to infer what happened. It separates 'the AS denied you' from 'the PS could not complete federation', which matches `A6`separate the concerns strictly and `C19`separate conflated roles keeping distinct concerns in distinct structures. Full reasoning Adding a structured error code for the PS-to-agent leg of a failed federation is what `A9`say it explicitly and `C12`explicit signals over inference require: errors signalled outright with structured codes, and no party left to infer what happened. It separates 'the AS denied you' from 'the PS could not complete federation', which matches `A6`separate the concerns strictly and `C19`separate conflated roles keeping distinct concerns in distinct structures. The retry-with-fresh-token-after-backoff guidance supports `P22`prioritises recovery over simplicity and `P21`flexible except where mandatory, where a broken flow should be recoverable. The proposal also comes from a real implementation against the reference AS, which `C16`legitimacy through running code and `A17`earned through open process value. what in the item it readAdding "as_unreachable \| 502 \| The PS could not obtain an auth token from the access server ... The agent MAY retry with a fresh resource token after a backoff", kept "Distinct from an AS denial: when the AS returns a well-formed terminal error (e.g. 403), the PS SHOULD propagate that outcome" 36 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:A17`Earned Through Open Process5 facts activated, not named · 29`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts cited without activating · 1: no packet entry backs these`dick-aauth10:C16`Legitimacy Through Running Code8 factsdid not activate No contradictions identified 11 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 degradation on an unavailable dependency; a named code with backoff is what its retry facts already assumedick-aauth10:A13 downstream scope expansion, not failure reportingdick-aauth10:A15 deferred interaction; naming a terminal branch changes no polling behaviourdick-aauth10:A19 whether mediation is mandatory, not how the mediator reports its own failuredick-aauth10:A2 gatekeeping and pre registration, not error semanticsdick-aauth10:A4 the consent cascade, untouched by an error codedick-aauth10:A7 audit durability versus minimised traceability; only its explicit error semantics side reaches this pointdick-aauth10:C20 mediation and revocability, not error codesdick-aauth10:C22 polling and disclosure to unauthenticated callers; the agent here holds an authenticated pending requestdick-aauth10:C6 where decisions are made, not how a failed federation call is reporteddick-aauth10:C8 autonomy versus control, not error semantics 2 open points logged, did not change the decision The proposed code groups an unreachable AS with a returned auth token that fails Auth Token Delivery verification. Under `C4`adversarial by default and `P12`treats all input as hostile, a verification failure could signal an attack, and it is arguably not the same concern as unreachability.did not change the decision: The packet raised no finding here. From the agent's side, both cases mean the PS could not get a usable auth token, and the fix is the same (a fresh resource token after backoff). Whether to split out a verification-failure code can be refined in drafting without undoing the explicit-error move.The proposal notes that nothing normative covers what the PS relays on an AS denial, and only suggests the spec 'could also say' so.did not change the decision: It is flagged as an adjacent gap, not a condition of this action, and leaving it for later does not make the new code less explicit. I124Terminology: distinguish supervision (per-act evaluation) from governance (the mission framework)APPROVE Proposed action, in full · 362 words The draft uses "governance" for at least three distinct things. A companion specification for the delegated evaluator (draft-hardt-aauth-supervisor) needs the per-act sense to have its own name, and the ambiguity is already visible within this document. Sense A — the orthogonal layer. Missions plus permission, audit, and interaction relay. Abstract, §Introduction, §Incremental Adoption, §Protocol Overview, #agent-governance, #ps-governance-endpoints, the adoption table, §Comparison with OAuth. Proposal: no change. This is a governance framework and the word is right. Sense B — the per-act evaluation. The PS deciding whether this specific act is consistent with the mission's intent and prior log entries: #policy-evaluation-points: "against the PS's governance policy" #mission-log: "the governance decisions made" #call-chaining: "The PS provides the governance constraint" Design rationale: "Contextual governance", "concentrates governance evaluation at the PS", "governance-based constraints", "mission governance" (PS/AS separation, ps claim rationale) "As AI decision-making matures, governance can shift from human review to agent evaluation" Proposal: change to supervision. "the PS's supervision policy", "the supervision decisions made", "the PS provides the supervision constraint", "Contextual supervision", "concentrates supervision at the PS". This aligns with draft-hardt-aauth-budgets, which already uses supervision as a term of art for exactly this and already attaches it to the PS: sizing the allocation is where the PS's supervision happens; the return to the PS is the supervision point; the supervision interval tracks whichever of expiry or exhaustion moves faster. Sense C — AP fleet control. "centralized governance over a distributed agent fleet" and "eliminating the governance point" in the agent-provider rationale. This is neither the mission framework nor per-act evaluation; it is fleet-level token issuance policy. Proposal: reword to avoid the collision. "centralized control over a distributed agent fleet", "eliminating the enforcement point". Related: the design rationale says the PS "presents the mission context, the justification, and the resource request to whatever decision-maker is appropriate: a human reviewing a consent screen, an AI agent evaluating policy on behalf of an organization, or an automated system applying heuristics." That decision-maker is the Supervisor. Once the companion draft exists, this paragraph should name the role rather than describing it anonymously. Flagging here so the two documents don't diverge; the naming itself can wait for the companion draft. reasoning`A6` (separate the concerns strictly) is the operative claim: the draft currently uses one word for three distinct things (the mission framework, per-act evaluation at the PS, and AP fleet token-issuance policy), and this person treats conflation as a defect before any argument about convenience. The proposal gives each distinct question its own name while leaving the framework sense of 'governance' untouched. Full reasoning `A6` (separate the concerns strictly) is the operative claim: the draft currently uses one word for three distinct things (the mission framework, per-act evaluation at the PS, and AP fleet token-issuance policy), and this person treats conflation as a defect before any argument about convenience. The proposal gives each distinct question its own name while leaving the framework sense of 'governance' untouched. It aligns with a term of art that draft-hardt-aauth-budgets already attaches to the PS, which keeps the vocabulary consistent across the reviewed document set (`A17`earned through open process). No coherence conflict was found. All three contestation candidates (`C20`delegation must stay bounded, `C6`decentralize yet concentrate context, `C8`autonomy against human control) were examined and rejected: the rename moves no authority, keeps the concentration of evaluation at the PS as it is, and puts off the human-versus-automated supervisor question. what in the item it readThe three-sense split: 'Sense A ... Proposal: no change'; 'Sense B ... Proposal: change to supervision' (e.g. 'the PS's supervision policy', 'concentrates supervision at the PS'); 'Sense C ... reword to avoid the collision' ('centralized control over a distributed agent fleet', 'eliminating the enforcement point'). Also the explicit deferral: 'the naming itself can wait for the companion draft.' 7 activated claims 5 named in the reasoning named in the reasoning · 5`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts activated, not named · 2`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C7`Human Oversight As Structure40 facts No contradictions identified 3 divided claims set aside as off-axis None. No activated claim contradicted another, and no divided claim divided on the point this action raises.set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:C20 the action renames one sense of a word and moves no authority, so the mediation-versus-direct-contact split is untoucheddick-aauth10:C6 its split is over whether evaluation should be concentrated at the PS; the action takes that allocation as given and only relabels itdick-aauth10:C8 the human-versus-automated supervisor question is expressly deferred to the companion draft, so the autonomy split does not bear on the rename 3 open points logged, did not change the decision *`A17`earned through open process: part of the motivation is a companion specification (draft-hardt-aauth-supervisor) that has not yet been through open review.did not change the decision: The rename stands on its own. The ambiguity is 'already visible within this document', and the term is taken from the existing budgets draft. The one change that depends on the companion draft, naming the Supervisor role in the decision-maker paragraph, is expressly held back until that draft exists.`C6`decentralize yet concentrate context: the person holds decentralized authority and concentrated evaluation at the PS as an unresolved tension, and relabelling that evaluation could look like settling it.did not change the decision: The contestation stage rejected this. The action takes the existing allocation as given and only relabels it, so neither side of the tension gains or loses anything.`C7`human oversight as structure/`C8`autonomy against human control: 'supervision' might suggest a particular answer to whether the per-act decision-maker is human or automated.did not change the decision: The proposal keeps the existing text that lets the decision-maker be a human, an AI agent, or an automated system, and it puts off role naming. No oversight gate is added or removed. I145requirement=agent-token cannot say which claim the agent token must carryAPPROVE Proposed action, in full · 664 words Problem* §Agent Token Required says: The header carries no additional parameters: the agent already holds its agent token and need only present it. That premise fails as soon as a resource requires the agent token to carry something an agent provider vouches for. The agent does hold an agent token; it holds the wrong one, and the challenge gives it no way to learn that. The concrete case is the CSA Verifiable Agent Summit demo. An agent provider issues an ordinary `aa-agent+jwt` carrying an extension claim, `[link] in which it asserts a trust grade an evaluator assigned to that agent's runtime evidence. A resource requires a minimum grade. Today that resource can only answer: [code block] to an agent that already presented a valid agent token. The agent has no way to distinguish "you sent nothing" from "your token lacks a claim I need," and re-presenting the same token loops. ATF is the first instance, not a special case. Any framework in which an AP vouches for a property of the agent — an assurance level, a jurisdiction, a certification, an operator binding — lands in the same place. Proposal Define one parameter on the `requirement` member of `requirement=agent-token`: [code block] Type: String. Requirement-specific data are parameters on the `requirement` member (§AAuth-Requirement Header Structure), and RFC 8941 parameter values are bare items, so an Inner List is not available. Value: one or more claim names the agent token must carry, space-delimited. Claim names here are URIs, which cannot contain a space, so the delimiter is unambiguous — same construction as OAuth `scope`. Semantics: the resource requires an agent token carrying each named claim. It says nothing about the claim's contents. Recipients MUST ignore unknown parameters already, so this is backward compatible: an agent that does not implement it sees today's bare challenge. The parameter names the claim and stops there. What acceptable values look like is the claim's own specification's business, and which of them this resource wants belongs in its `aauth-resource.json` — under the same URI, e.g.: [code block] So AAuth learns exactly one framework-neutral fact — the agent token must carry claim X — and acquires no vocabulary from, and no opinion about, any particular framework. §Agent Token Required's sentence changes from "carries no additional parameters" to permitting parameters, with `agent-claims` the one defined. Naming Not `claims`: that is already a `requirement` value (`requirement=claims`, 202, identity claims at an AS). Distinct slot, so no grammar collision, but two unrelated meanings for one word in one header field is not worth it. `agent-claims` names the token that is short. Alternatives considered A second top-level dictionary member — `requirement=agent-token, agent-claims=("[link] "[link] Legal RFC 8941, gives a real Inner List with per-item parameters, no space-delimiting. Rejected because §AAuth-Requirement Header Structure establishes that requirement-specific data hang off the` requirement` member, and a receiver iterating members would need a second shape. Worth reopening if per-claim parameters are ever needed. Framework-specific parameters — `atf-profile="csa-atf:0.9.1"; atf-level="senior"`. One round trip instead of two, but parameter keys cannot hold a URI (`lcalpha / digit / _ - . `), so every framework takes a prefix out of one flat space and AAuth needs a parameter registry and an opinion about who gets one. A durable obligation for one round trip. A separate `ATF-Required` header* — no AAuth change at all, but an unregistered field name in the global HTTP namespace, and undiscoverable: an agent that does not know the field sees a bare 401 and cannot find out why. Nothing; put it only in `aauth-resource.json` — zero spec change, and sufficient when the requirement is a static property of the resource. It cannot express a per-endpoint or per-req reasoningThe proposal fixes a failure of explicitness that `A9`say it explicitly and `C12`explicit signals over inference treat as an obligation: today an agent 'has no way to distinguish "you sent nothing" from "your token lacks a claim I need," and re-presenting the same token loops.' The fix fits the rest of the profile closely. It is backward compatible because unknown parameters are already ignored (`A11`tolerate the unrecognised, `P21`flexible except where mandatory). Full reasoning The proposal fixes a failure of explicitness that `A9`say it explicitly and `C12`explicit signals over inference treat as an obligation: today an agent 'has no way to distinguish "you sent nothing" from "your token lacks a claim I need," and re-presenting the same token loops.' The fix fits the rest of the profile closely. It is backward compatible because unknown parameters are already ignored (`A11`tolerate the unrecognised, `P21`flexible except where mandatory). Claim names are URIs that are matched, not parsed (`C23`identifiers are opaque handles). Trust still rests on the AP-signed agent token, with nothing self-asserted (`A1`proof not possession, `C3`verification over trust, `P2`demands proof not possession). It takes no framework vocabulary and no opinion on acceptable values, in line with `P4`plain language over fixed vocabulary's refusal to fix a shared vocabulary in advance. It rejects framework-specific parameters because they would need a registry and 'an opinion about who gets one' (`C5`power is the real question). Of the two DIVIDED contestations, `A2`no single central authority does not bite: the resource can already require such a claim, and the rejected `C13`complexity must be optional finding notes that the action changes only whether the newcomer is told what it must hold, not what it must hold. On `C6`decentralize yet concentrate context, the proposal takes side A's metadata-driven, resource-decided route and does not touch side B's concentration of evaluation at the PS. what in the item it read'Define one parameter on the requirement member of requirement=agent-token ... one or more claim names the agent token must carry ... It says nothing about the claim's contents', and 'So AAuth learns exactly one framework-neutral fact — the agent token must carry claim X — and acquires no vocabulary from, and no opinion about, any particular framework.' 26 activated claims 13 named in the reasoning named in the reasoning · 13`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P4`Plain Language Over Fixed Vocabulary12 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts activated, not named · 13`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts 2 contradictions identified 5 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A2 divides on whether conditioning access on an AP-vouched claim the agent must already hold is a prerequisite of the kind first contact must not requiremitigating evidenceits own cited facts, sorted for this action: 5 one side `F-9b9e4569F-3a545c16F-c761a49e`+2 5 the other `F-914283f6F-8d907b74F-aae731c5`+2claim vs its own recorddick-aauth10:C6 divides on whether a new claim and parameter extension point belongs in a formal central registry or is left to each resource's own metadatamitigating evidenceits own cited facts, sorted for this action: 4 one side `F-aaf39f88F-c761a49eF-d77e8899`+1 4 the other `F-aae731c5F-f4a44a4eF-007e0c91`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 the parameter is optional and unknown parameters are already ignored, so only the tolerance side answersdick-aauth10:A15 no deferral, polling or waiting is at issue; the challenge-retry exchange is unchanged in kinddick-aauth10:C10 no record, retention or correlating identifier is created; the parameter names a claim and says nothing of its contentsdick-aauth10:C13 it shares the A2 axis, and on its own point the action changes only whether the newcomer is told what it must hold, not what it must holddick-aauth10:C8 nothing turns on human oversight; the exchange is agent-to-resource and no consent gate is added or removed 4 open points logged, did not change the decision *`A2`no single central authority* divided: whether requiring an AP-vouched claim the agent must already hold is the kind of prerequisite first contact must not require.*did not change the decision: The proposal does not create that requirement. A resource can already refuse a token that lacks the claim. The parameter only signals that existing requirement explicitly, which removes guesswork and adds no prerequisite.`C6`decentralize yet concentrate context* divided: whether a new claim and parameter extension point belongs in a formal central registry or in each resource's own metadata.did not change the decision: The proposal defines one fixed parameter and puts value semantics in the claim's own spec and the resource's aauth-resource.json. The record holds both registry acceptance and resource-side metadata as legitimate, and the proposal's route rules out neither. 'Worth reopening if per-claim parameters are ever needed' leaves room for the registry question later.`C4`adversarial by default/`P27`withholds detail from strangers uneasily: the proposal names no failure modes, and the challenge tells the caller which claim the resource needs.did not change the decision: The disclosure goes to an agent that has already presented a valid agent token, not an unknown caller. It reveals only a claim name the resource would publish in its metadata anyway. No new trust path is created, since the claim is still verified inside the AP-signed token. Security Considerations wording can be added in drafting without changing the design.The item text is cut off partway through 'Alternatives considered'.did not change the decision: The Problem, Proposal, and Naming sections are complete. The missing text is the tail of a rejected alternative, which does not affect the action being judged. I152presented_jti should name the token actually presented, and the agent should pass it to the PSAPPROVE Proposed action, in full · 679 words Problem `presented_jti` in a resource token is defined as the `jti` of the person token whose verification established `ps` and `sub`. §Resource Token Structure says that on a step-up or per-call challenge, where the request carries an auth token, "the resource supplies the value from its record of the person token it verified earlier." The resource has no such record it can key. §Token Revocation says an auth token "carries no reference to that person token, so nothing on the wire recovers the link." The auth token also carries no resource token `jti`. The only tuple the resource holds when it receives an auth token is `(ps, sub, agent key)`, which §Why a Resource Token Names the Person Token says is exactly the tuple that does not identify one person token under concurrent missions. So the rule in §Resource Token Structure cannot be implemented on a step-up. Separately, the PS resolves `presented_jti` by lookup: §Resource Token Verification step 6 has the PS "resolve `presented_jti` against its retained records of issued person tokens," and §Person Token Endpoint makes the PS retain every person token it issues, beyond `exp` by the longest resource token lifetime, so the lookup can succeed. That retention exists for the request path. The AS, by contrast, gets the person token on the wire (`person_token` in §PS-to-AS Token Request) and verifies it statelessly. The two verifiers do the same check two different ways. The -11 changelog renamed `person_token_jti` to `presented_jti` (issue #95) because the presented credential is an auth token on step-up, but kept the value as the person token's `jti`. The rename is half done. Proposal `presented_jti` names the token that was actually presented. On the first request of a grant that is the person token. On a subsequent request, a step-up or an R3 per-call challenge, it is the auth token the request carried. Both token types carry `sub`, `mission_s256`, and `tenant`, and the PS as `iss` (person token) or `ps` (auth token), so the resource copies the same claims from either. The resource names the token it just verified and keeps no record. The agent passes `presented_token` to the PS. The auth token request at `auth_token_endpoint` gains `presented_token`, REQUIRED: the token the agent presented to the resource, whose `jti` the resource token's `presented_jti` names. The agent holds it already; it is cached per (resource, mission) for a person token, or is the current auth token. The PS-to-AS request's `person_token` becomes `presented_token`, passed through. One verification paragraph at PS and AS. Verify `presented_token` by its `typ`: signature against its issuer, `aud` equals the resource token's `iss`, `cnf.jwk` matches `agent_jkt`, `jti` equals `presented_jti`, and `sub`, `ps`, `mission_s256`, `tenant` match the resource token. This is the AS's existing check with the person-token-only assumption removed; PS step 6 becomes the same paragraph. Mission stripping is still caught, since `mission_s256` is under the issuer's signature in either token type. Expiry. The new auth token's `exp` is capped at the presented token's `exp`, whichever type it is. An auth token's `exp` was already capped by the person token's, so the bound is sound. A step-up on a nearly expired auth token yields a nearly expired auth token; the existing refresh guidance (fresh person token five minutes early, re-obtain through the authorization endpoint) is how an agent gets a full-length chain. Retention. The PS's retention MUST narrows from "so resource token verification can resolve it" to what revocation and the dashboard need. `unknown_person_token` goes; a bad `presented_jti` is a signature failure or a `jti` mismatch. `expired_person_token` becomes `expired_presented_token`. Revocation. An AS can now record which `presented_jti` each auth token was issued against and walk a chain of step-ups back to the person token, which eases the "nothing on the wire recovers reasoningThe proposal fixes a rule that cannot be implemented: the resource has no record it can key to recover the person token on a step-up. It does so by moving the verifiers from a stateful lookup to checking the credential on the wire. Full reasoning The proposal fixes a rule that cannot be implemented: the resource has no record it can key to recover the person token on a step-up. It does so by moving the verifiers from a stateful lookup to checking the credential on the wire. The PS no longer resolves presented_jti against retained records. It verifies the presented token by signature, aud, cnf.jwk, jti and the matching claims, the same way the AS already does. This person strongly prefers to verify a signature rather than look up state elsewhere, and to verify without a live dependency (`A16`self contained verification, `C3`verification over trust, `P2`demands proof not possession, `P32`avoids live dependence at check time). Every verifier checks the presented credential itself, and two independent parties run the same check (`P12`treats all input as hostile, `P13`layers controls never one checkpoint). Mission stripping is still caught under the issuer's signature (`C4`adversarial by default). Errors are renamed to say what failed (`A9`say it explicitly). The expiry cap keeps layered expiry intact (`A14`authority expires by default). Retention is kept for revocation and the dashboard, which preserves the audit trail (`A7`accountability traces to persons, `C9`accountability ends at person). The rename from #95 was half done, and this finishes it. No activated claims contradict each other. what in the item it read'presented_jti names the token that was actually presented' together with 'The agent passes presented_token to the PS' and 'One verification paragraph at PS and AS... This is the AS's existing check with the person-token-only assumption removed; PS step 6 becomes the same paragraph.' 37 activated claims 11 named in the reasoning named in the reasoning · 11`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C9`Accountability Ends At Person28 facts activated, not named · 26`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P16`Audit And Privacy Left Pulling10 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts 1 contradiction identified 10 divided claims set aside as off-axis claim vs its own recorddick-aauth10:C15 divides on whether presented_jti may be relaxed to a polymorphic identifier or held to a fixed formmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-161f3f8dF-896e1426F-57d3779f`+1 5 the other `F-80cf7e3cF-c4f12f40F-6dca01cf`+2set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 unrecognised input; both token types are declared in advance and selected by typdick-aauth10:A15 stateful exchange versus stateless verification; its deferred facts do not speak to PS retentiondick-aauth10:A19 mediation versus direct contact; the PS stays in the flowdick-aauth10:A4 consent and veto; no consent step changesdick-aauth10:A7 durable records versus minimised traceability; retention for revocation and the dashboard is keptdick-aauth10:C10 audit retention versus privacy; the narrowing keeps what audit needs and is not privacy-drivendick-aauth10:C20 bounded delegation; the chain is unchanged and easier to walk backdick-aauth10:C22 deferred versus immediate answers; the change is where evidence comes from, not whendick-aauth10:C6 where a decision is made; both verifiers run the same checkdick-aauth10:C8 autonomy versus human control; its record only names the tension 3 open points logged, did not change the decision `C15`flexibility with hard floors divided: whether presented_jti may become a polymorphic identifier that names either a person token or an auth token, given this person's rejection of polymorphic or shape-shifting identifiers (F-98573ee1).did not change the decision: Both token types are declared in advance and selected by an explicit typ, and jti is still matched literally as an opaque handle (`C23`identifiers are opaque handles). It is a declared discriminated choice, not an identifier whose meaning has to be inferred. The floor facts ask that every verifier check the presented credential itself, which this proposal delivers.The adoption-flexibility facts (F-80cf7e3c, F-c4f12f40) favour rollout without coordination, but the proposal makes presented_token REQUIRED and renames person_token in the PS-to-AS request, which is a coordinated change.did not change the decision: The current rule cannot be implemented on a step-up, so there is no working behaviour for a coordinated change to break. Signature verification is a floor this person does not bend on (`C15`flexibility with hard floors, `P21`flexible except where mandatory).The item text is cut off in the Revocation paragraph.did not change the decision: The cut falls after the operative content (naming, passing, verification, expiry, retention). The missing part describes a side benefit for revocation, not a requirement the verdict depends on. I154revocation_endpoint: RECOMMENDED for PS and AS, and for a resource that accepts person tokensAPPROVE Proposed action, in full · 307 words Problem `revocation_endpoint` is OPTIONAL in PS, AS, and resource metadata, and §Token Revocation opens with "Any AAuth server that issues tokens MAY provide a revocation endpoint." Since #146 the endpoint is where every cascade lands: A PS's endpoint is where the agent provider revokes an agent token and where a resource withdraws a resource token. Without it an agent provider that has decided an agent can no longer be trusted has no way to say so, and the agent runs until its token expires. An AS's endpoint is where a PS revokes a person token it federated. Without it the four-party cascade in §Token Revocation cannot start, and the AS keeps issuing auth tokens against a revoked person token until its `exp`. A resource's endpoint is the only place a person token or an auth token is revoked. Without it a revoked person token or auth token is honored for up to an hour. OPTIONAL says none of that matters. It also says the same thing to a resource that accepts only agent tokens, for which the endpoint has no possible caller: the #146 changelog already notes that the agent provider has no way to find such a resource, and §Token Revocation says the PS is the only recipient of an agent token revocation. Proposal PS metadata: `revocation_endpoint` RECOMMENDED. AS metadata: `revocation_endpoint` RECOMMENDED. Resource metadata: `revocation_endpoint` RECOMMENDED for a resource that accepts person tokens, and therefore auth tokens. A resource that accepts only agent tokens receives no revocations and has no reason to publish one; say so rather than call it OPTIONAL. §Token Revocation: replace "MAY provide" with the same rule, and say what the absence costs: the revoked token is honored until its `exp`. Minimal PS appendix: the sentence calling it OPTIONAL follows the metadata section. reasoningSince #146, every revocation cascade lands on these endpoints. Calling them OPTIONAL hides that without them delegated authority cannot be withdrawn before exp. Full reasoning Since #146, every revocation cascade lands on these endpoints. Calling them OPTIONAL hides that without them delegated authority cannot be withdrawn before exp. This person treats revocability by the delegator as a structural precondition of delegating (`C20`delegation must stay bounded, `A13`delegation must be bounded) and names unbounded revocation delay as a concrete threat (`C4`adversarial by default). Raising the endpoint to RECOMMENDED respects that without making it a hard requirement. The proposal also requires the spec to say outright what absence costs. That is this person's own move: signal the state explicitly (`A9`say it explicitly, `C12`explicit signals over inference) and state plainly that termination is not instant rather than hide the cost (`C21`time bounds instead of promises, `P14`expiry over active revocation). Exempting resources that accept only agent tokens is explicit rather than implied, and it leaves those resources free to serve without added infrastructure. what in the item it read'revocation_endpoint RECOMMENDED' for PS, AS and 'a resource that accepts person tokens', together with '§Token Revocation: replace "MAY provide" with the same rule, and say what the absence costs: the revoked token is honored until its `exp`.' 33 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts activated, not named · 26`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts 2 contradictions identified 7 divided claims set aside as off-axis claim vs claimC20, A13, C4 with, A14, C21 against: whether a revocation endpoint is a structural precondition of delegating or a secondary mechanism behind expiryno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:C20 divides on whether revocability obliges each party to stand up an endpoint or a resource may serve without added infrastructuremitigating evidenceits own cited facts, sorted for this action: 3 one side `F-7d67edb7F-22f2a7d5F-a0cf5af0` 2 the other `F-a3095e3dF-2779740b`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A13 bounded delegation versus downstream scope expansion, not the reachability of withdrawaldick-aauth10:A19 who mediates, not who publishes an endpointdick-aauth10:A2 gatekeeper control; RECOMMENDED mandates no architecturedick-aauth10:A20 autonomy versus oversight; its record only names the tensiondick-aauth10:A4 consent and veto; withdrawal is not the consent eventdick-aauth10:C6 where a decision is made; each party publishes at its own scopedick-aauth10:C8 autonomy versus human control; its one revocation fact points one way 2 open points logged, did not change the decision Coherence finding `C20`delegation must stay bounded/`A13`delegation must be bounded/`C4`adversarial by default against `A14`authority expires by default/`C21`time bounds instead of promises: whether a revocation endpoint is a structural precondition of delegating or a secondary mechanism behind expiry.did not change the decision: RECOMMENDED does not make revocation primary or mandatory. Expiry stays the backstop, and the proposal names 'honored until its exp' as the stated consequence of absence. That keeps withdrawal secondary while making it reachable, so both sides of the finding are respected.`C20`delegation must stay bounded divided: whether revocability obliges each party to stand up an endpoint, or a resource may serve without added infrastructure (F-a3095e3d, F-2779740b).did not change the decision: A recommendation obliges no one. A party can still omit the endpoint and accept the stated cost, and resources that accept only agent tokens are explicitly told they need not publish one. The no-infrastructure path stays open. I155Remove Third-Party Login and login_endpointAPPROVE Proposed action, in full · 256 words Problem §Third-Party Login and the `login_endpoint` metadata field, on agent providers and resources, describe a flow the protocol can no longer run. §Login Flow has the agent or resource "create a resource token with `aud` = PS URL, binding the request to its own identity" and POST it to `auth_token_endpoint`. A resource token is issued only after verifying a person token or an auth token, and copies `ps`, `sub`, and `presented_jti` from it (§Resource Token). There is nothing to copy. And only an agent, signing with an agent token, calls `auth_token_endpoint`. A resource cannot run this flow at all. The `ps` query parameter lets the third party choose the PS. An agent's PS is the `ps` claim of its agent token. Nothing for a third party to choose. The section was OIDC third-party-initiated login (OpenID Connect Core 1.0 §4) carried over. Its use cases are covered elsewhere or are not protocol: a portal launching an agent for a person is agent-person binding, which the PS establishes at first interaction (§Agent-Person Binding); a PS dashboard directing a person to an agent is the agent's own UI; an agent that needs the person calls the resource's `authorization_endpoint` and follows the requirement it gets back. No companion draft references `login_endpoint`. Proposal Remove §Third-Party Login, its figure, and `login_endpoint` from Agent Provider Metadata and Resource Metadata. The `login_hint`, `domain_hint`, `tenant`, and `prompt` parameters of the auth token request stay; they serve the first interaction, where binding happens, and do not depend on this section. reasoningThe section describes a flow the current protocol cannot run. A resource token can only be issued by copying ps, sub and presented_jti from a verified person token or auth token, and in this flow there is none to copy. Full reasoning The section describes a flow the current protocol cannot run. A resource token can only be issued by copying ps, sub and presented_jti from a verified person token or auth token, and in this flow there is none to copy. Only an agent calls auth_token_endpoint, so a resource cannot run the flow at all. This person grounds legitimacy in running code and would not keep text that cannot execute (`C16`legitimacy through running code). The 'ps' query parameter lets a third party choose the PS, which is the hijack path this person already worries about (F-c80a49fc, `C4`adversarial by default, `P12`treats all input as hostile). Removing it keeps binding with the context-holding PS (`A19`mediation over direct contact, F-8d907b74, F-914283f6). The proposal maps each use case to a mechanism that survives: agent-person binding at the PS, and agent-initiated requests at authorization_endpoint (F-df5cb82c). It keeps the first-interaction parameters, so it removes inherited OIDC machinery without removing any capability (`C13`complexity must be optional). what in the item it read'Remove §Third-Party Login, its figure, and `login_endpoint` from Agent Provider Metadata and Resource Metadata', justified by 'A resource token is issued only after verifying a person token or an auth token, and copies `ps`, `sub`, and `presented_jti` from it (§Resource Token). There is nothing to copy.' 28 activated claims 5 named in the reasoning named in the reasoning · 5`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts activated, not named · 23`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts 1 contradiction identified 7 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A19 divides on whether third-party login initiation is a legitimate use case needing these endpoints or a hijackable path better removedmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-0de145f8F-aa2763eaF-8d907b74`+3 2 the other `F-465c66bbF-2779740b`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A15 deferred interaction; the surviving authorization endpoint carries the same flowdick-aauth10:A2 who chooses the PS; an agent PS is already fixed by its agent tokendick-aauth10:A4 consent and veto; no consent step is added or removeddick-aauth10:C10 records and retention; none changedick-aauth10:C13 plural modes versus stripping inherited complexity; the removed flow cannot be run at alldick-aauth10:C6 where a decision is made; no decision point movesdick-aauth10:C8 autonomy versus human control; its record only names the tension 2 open points logged, did not change the decision *F-465c66bb and `A19`mediation over direct contact* divided: this person has held that third-party login initiation is a legitimate use case that requires agent and resource login endpoints.**did not change the decision: The proposal does not reject the use case. It shows that each of its forms is served elsewhere and that the text being removed cannot execute under the current token structure. Deleting a flow that cannot run removes no working capability. Bringing back third-party initiation would need new design, not this text.F-2779740b: this person avoids making intermediaries mandatory in simple access scenarios, which could argue against routing all binding through the PS.did not change the decision: An agent's PS is already fixed by its agent token, so removing the section adds no new intermediary. The mediation it relies on already exists.
DENY	PARTIAL	A specific change would clear it, and the verdict names it	Mission agent	7
All 7 partial denials, with the change each names I112Proxy deployment: specify the verifying-proxy-to-origin hopDENY · partial Proposed action, in full · 199 words Problem The sidecar pair — signing proxy in front of the agent, verifying proxy in front of the resource — is the adoption path for putting AAuth in front of existing software, and (#roles) already permits it (roles are not deployment units; a signing proxy holding the agent key is the agent). What is unspecified is the verifying-proxy-to-origin hop: how the proxy asserts the verified identity and authorization context to the origin service, and the rule that the origin accepts that assertion only from the proxy. Without it, every deployment invents its own internal header convention, and "AAuth in front of a legacy daemon" is folklore rather than a pattern. Suggested direction One short section (or a profile alongside bootstrap): the proxy terminates AAuth verification; it forwards verified claims (`sub`, `scope`, mission context, `r3_granted`) to the origin over a channel the origin trusts only from the proxy (network isolation, mTLS, or a shared-secret header); the origin MUST NOT accept those assertions from any other source. Comparable prior art: `X-Forwarded-` trust rules, RFC 9440 `Client-Cert`. Context* From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — their CR-5, and their deployment already runs this shape on both sides. reasoningSpecifying the hop fits this person. It turns internal header folklore into an explicit, reviewed pattern (`A9`say it explicitly, `A17`earned through open process), is grounded in a deployment that already runs this shape (`C16`legitimacy through running code), and eases adoption in front of legacy software (`C13`complexity must be optional). Full reasoning and the change that would clear it Specifying the hop fits this person. It turns internal header folklore into an explicit, reviewed pattern (`A9`say it explicitly, `A17`earned through open process), is grounded in a deployment that already runs this shape (`C16`legitimacy through running code), and eases adoption in front of legacy software (`C13`complexity must be optional). The 'MUST NOT accept from any other source' rule reflects their treatment of all input as hostile (`P12`treats all input as hostile). But the coherence finding (`A1`proof not possession, `C3`verification over trust, `A16`self contained verification against) goes to one of this person's hardest lines. Anything that works merely because the holder has a secret, including shared keys and implicit trust, is ruled out in advance, and they will accept implementation cost and give up convenience to hold that line (`A1`proof not possession). They replace bearer arrangements with proof the checking party can verify itself (`C3`verification over trust, `P2`demands proof not possession), require each hop to attest with its own credential rather than an implied identity (`P18`every hop signs for itself), and will not accept a single channel as sufficient proof (`P13`layers controls never one checkpoint). The proposal sanctions a shared-secret header and bare network isolation as ways to trust the channel. That writes bearer-style trust into the protocol at the exact point where verified identity is handed to the origin. mTLS is already listed, so narrowing the options to verifiable ones clears the item without changing its purpose. what in the item it read'it forwards verified claims (sub, scope, mission context, r3_granted) to the origin over a channel the origin trusts only from the proxy (network isolation, mTLS, or a shared-secret header)'. change that would clear itRemove the shared-secret header as a sanctioned way for the origin to trust the proxy's assertions, and do not let network isolation alone stand as sufficient. Require the origin to accept forwarded claims (sub, scope, mission context, r3_granted) only when it can verify they came from the proxy by proof of possession: mTLS with a client certificate bound to the proxy, or claims signed by the proxy's key and verified by the origin. Network isolation may remain as an additional layer. Keep the rule that the origin MUST NOT accept these assertions from any other source. 29 activated claims 10 named in the reasoning named in the reasoning · 10`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts activated, not named · 19`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts cited without activating · 1: no packet entry backs these`dick-aauth10:A9`Say It Explicitly16 factsdid not activate 1 contradiction identified 9 divided claims set aside as off-axis claim vs claimC13, C16, A17, A9 with, A1, C3, A16 against: whether the origin may accept a trusted-channel assertion, including a shared-secret header, in place of proof it can verify itselfno mitigating evidence was carried for this findingset aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A19 the proxy is a deployment artifact of an existing role, not an added intermediary in the mediation sense this record splits ondick-aauth10:A2 proxy and origin are one party, so no question of who decides or where control sits is reopeneddick-aauth10:A4 no consent or approval question is decided by an internal hopdick-aauth10:A7 the sub forwarded is the pairwise identifier minted for that resource, reaching that resource's own origin, so the no-downstream-correlation facts are not engageddick-aauth10:C10 same reason: an intra-deployment hop is not cross-domain propagation of a directed identifierdick-aauth10:C13 its simple-case facts all favour the legacy adoption path; the two dissenting facts concern OAuth shortcuts, not proxy deploymentdick-aauth10:C20 roles are not deployment units, so a proxy holding the key adds no delegation hopdick-aauth10:C6 the action places no decision anywhere new; the proxy enforces what the resource already enforceddick-aauth10:C8 the action decides nothing about acting on a person's behalf 3 open points logged, did not change the decision The contestation record treats proxy and origin as one party and the proxy as a deployment artifact of an existing role, not an added intermediary.did not change the decision: That settles the questions of mediation, control and delegation depth (`A2`no single central authority, `A19`mediation over direct contact, `C20`delegation must stay bounded), not the proof question. `A1`proof not possession presumes every party's inputs are untrusted and bars shared secrets as a class, regardless of who holds them.`C16`legitimacy through running code and `C13`complexity must be optional: the deployer already runs this shape, and a shared-secret header is the lowest-friction path for legacy daemons.did not change the decision: `A1`proof not possession explicitly accepts implementation cost and refuses convenience to keep this line, and the mTLS or proxy-signature path keeps the same deployment shape.`A7`accountability traces to persons and `C10`audit versus privacy unresolved: forwarding sub to the origin could look like propagating a directed identifier downstream.did not change the decision: The contestation record rejects this. The sub is the pairwise identifier minted for this resource, reaching its own origin, so nothing is correlated across domains. I114Deferred verification: point queued-consumption verifiers at the signed created timestampDENY · partial Proposed action, in full · 161 words Problem (#non-repudiation-key-rotation) tells a verifier to capture evidence at verification time for audit that outlives key rotation. A different case is unaddressed: the verifier is the first to see the artifact, minutes to hours after signing — queued consumption, batch pipelines, store-and-forward. "Valid if the token was unexpired at signing time" is only decidable if the signing time is itself signed. RFC 9421 `created` in the covered components is exactly that, and the profile already mandates it — but nobody reading from the queued-consumption angle is pointed there. Suggested direction A sentence or two, probably in (#non-repudiation-key-rotation) or the signature profile: for artifacts verified after a delay, the signed `created` timestamp is the signing-time anchor; the verifier checks the token was valid at `created`, and the acceptable `created`-to-verification skew is the verifier's policy. No new mechanism. Context From the notes.ito.com deployment review ([writeup]([link] [review pass]([link] — their CR-9, arising from artifacts consumed from a queue well after signing. reasoningThe anchor itself fits the person. `A16` (self-contained verification) and `P32` (timestamp windows instead of live lookups) both favour checking against the signed `created` value, and `C22`asynchronous with known friction accepts deferred processing. Full reasoning and the change that would clear it The anchor itself fits the person. `A16` (self-contained verification) and `P32` (timestamp windows instead of live lookups) both favour checking against the signed `created` value, and `C22`asynchronous with known friction accepts deferred processing. But the coherence finding places `A14` (authority expires by default; short duration as a primary safeguard) and `C21` (request-time proof rather than lasting non-repudiation) against this item, and the item's wording triggers exactly that conflict. It makes validity 'at `created`' the test and hands the allowed delay entirely to verifier policy. That turns a short-lived token into one that can be accepted any time later, as long as the signed timestamp falls inside its lifetime. `C4` (adversarial by default) predicts the person would supply the failure mode the proposal leaves out: after expiry, the holder of a compromised key can backdate `created`. `A1`proof not possession requires trust to be demonstrable at the moment of use, and here that holds only if the delay is bounded. The fix is specific, so this is a partial deny. what in the item it read"the verifier checks the token was valid at `created`, and the acceptable `created`-to-verification skew is the verifier's policy. No new mechanism." change that would clear itKeep the signed `created` timestamp as the signing-time anchor, but do not leave the created-to-verification window as open verifier policy. State that the verifier MUST enforce a bounded maximum delay, and name the failure mode that makes the bound necessary: once a token has expired, whoever holds its key can sign with a backdated `created`, so a long window stretches the exposure of a stolen key or token past expiry. The text should say that token lifetime stays the primary safeguard and that the delay window only widens it on purpose. 20 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A1`Proof Not Possession42 facts activated, not named · 13`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P3`Inserts The Human Back In21 facts 2 contradictions identified 4 divided claims set aside as off-axis claim vs claimC22, A16 with, A14, C21 against: whether validity may be anchored at the signed created time rather than proven at the moment of useno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A7 divides on whether provability of signing time should be durably anchored or deliberately left short-livedmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-f4b0205bF-3649453aF-652efd28`+1 2 the other `F-0ca5c63cF-dbace961`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:C10 pseudonymous identifiers versus mission logging, an identifier question this action does not raisedick-aauth10:C22 deferred interaction versus stateless verification, which both favour this actiondick-aauth10:C6 where an authorization decision is made, not how a verifier reads a signed timestampdick-aauth10:C8 agent autonomy versus human control, untouched by a timestamp anchor 2 open points logged, did not change the decision *`A7`accountability traces to persons* is divided on whether the provability of signing time should be durably anchored or deliberately kept short-lived.*did not change the decision: The mitigating evidence shows the record already requires explicit timestamping for non-repudiation (F-f4b0205b), so anchoring on a signed timestamp is not the problem. The deny targets the unbounded window, not durable anchoring, and the requested change works on either side of `A7`accountability traces to persons.`C22`asynchronous with known friction's tension between deferred interaction and stateless verification was examined and ruled not on this point.did not change the decision: Both sides of that tension favour allowing delayed verification. Nothing in the deny removes queued consumption; it only bounds it. I120Replace budget_consumed records with a single claim for the presented token's spendDENY · partial Proposed action, in full · 469 words Problem* `budget_consumed` is an array of `{jti, consumed}` records covering up to 20 recent grants. Walking through what an issuer actually does with them: in the steady re-authorization loop, the presented token's figure is the only new information. Every prior record duplicates an actual the issuer already holds — each was delivered when that token was retired. The gap cases (an agent that crashed holding a token, a resource token lost before reaching the PS) are made safe by conservative accounting (#unreported-allocations) and recoverable without the records: the PS has the usage endpoint, and an AS has out-of-band access to the resource's figures — it sits in the resource's trust domain. The prior records also carry the design's two real costs. Up to a kilobyte rides inside the `AAuth-Requirement` header on the `401` path. And they are the privacy exposure the security considerations flag: the agent relays and reads records naming the person's other agents' tokens. The presented token's own spend exposes nothing — the agent watched `cost` and `remaining` in `AAuth-Budget` the whole time. Proposal Replace the array with a single claim: what the resource has metered to date against the auth token presented on the request this resource token answers. No list, no `jti` member. A figure for an unexpired token is a snapshot, superseded by a later report. Long-horizon and multi-grant history moves entirely to the usage endpoint, which already serves it. Open question: attribution without a `jti` The resource token does not name the presented auth token anywhere. `presented_jti` is the `jti` of the person token whose verification established `ps` and `sub` — on a step-up it is not the presented credential (the #95 rename exists because of exactly this), and it is load-bearing for mission-stripping detection, so it cannot be overloaded. Two options: Contextual attribution. The issuer matches the figure to its newest live allocation for `(sub, aud, mission_s256, agent_jkt)`. Ambiguous only while two allocations for one key overlap (the renewal window); an unattributable figure is discarded and the conservative rule stands, so ambiguity degrades safely. Carry the auth token's `jti` beside the amount. Exact attribution, still one record rather than a list — but back to an object. A third fact bears on the choice: the proactive path. An agent re-authorizing at the authorization endpoint before a `401` presents no auth token at all, so under either option the claim is absent there and the issuer's own channels cover it. Context Arose from working through the AS ledger in four-party access. The editor's copy currently holds the intermediate step — the presented token's record first in the array, plus (#unreported-allocations) — and this issue is whether to go the rest of the way. The question is also going to Regent Protocol, who run both sides in production. reasoningThe main move matches this person: drop the array of other grants' records and keep only the presented token's spend. The dropped records duplicate figures the issuer already holds, and they make the agent relay identifiers for the person's other agents' tokens, which `C23`identifiers are opaque handles and `P17`blocks cross context correlation resist. Full reasoning and the change that would clear it The main move matches this person: drop the array of other grants' records and keep only the presented token's spend. The dropped records duplicate figures the issuer already holds, and they make the agent relay identifiers for the person's other agents' tokens, which `C23`identifiers are opaque handles and `P17`blocks cross context correlation resist. The mitigating evidence answers the `A7`accountability traces to persons/`C10`audit versus privacy unresolved split: durable history stays available at the usage endpoint, and F-1b082c00 puts the audit-versus-privacy balance in deployment policy, not the wire format. What stops the proposal as written is that it leaves attribution open, and option 1 attributes the figure by inference. `A16`self contained verification wants matching to be strict and literal, not interpretive. `A9`say it explicitly, `C12`explicit signals over inference and `P12`treats all input as hostile say no party should have to guess. `C4`adversarial by default would read the renewal-window ambiguity as an attack surface with no named mitigation, even if dropping the figure fails safe. Option 2 attributes exactly and exposes nothing new, because the agent already holds that token. Adopting option 2 keeps the privacy and size gains and removes the inference. what in the item it read"Open question: attribution without a jti ... 1. Contextual attribution. The issuer matches the figure to its newest live allocation for (sub, aud, mission_s256, agent_jkt). Ambiguous only while two allocations for one key overlap ... 2. Carry the auth token's jti beside the amount." change that would clear itSettle the open attribution question in favour of option 2: carry the presented auth token's jti next to the consumed amount as a single record, not a list. Do not rely on contextual attribution against the newest live allocation for (sub, aud, mission_s256, agent_jkt). 39 activated claims 7 named in the reasoning named in the reasoning · 7`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:C4`Adversarial By Default16 facts activated, not named · 32`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A17`Earned Through Open Process5 facts`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C15`Flexibility With Hard Floors24 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P16`Audit And Privacy Left Pulling10 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P6`Mediation Required And Refused9 facts cited without activating · 2: no packet entry backs these`dick-aauth10:A9`Say It Explicitly16 factsdid not activate`dick-aauth10:C12`Explicit Signals Over Inference10 factsdid not activate 3 contradictions identified 9 divided claims set aside as off-axis claim vs claimC5, C23 with, C9, A16 against: whether dropping other agents' spend records off the wire is a correlation-exposure fix or a loss of in-band accountability and self-contained checkingno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A7 divides on whether durable per grant records stay on the wire or are minimised as correlatable identifiersmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-6bb0e92cF-0a4d8676F-127f28a2`+2 4 the other `F-95029c50F-31a34badF-0ca5c63c`+1claim vs its own recorddick-aauth10:C10 divides on whether the agent should relay and read records naming the person's other agents' tokensmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-95029c50F-31a34badF-16955367`+1 2 the other `F-127f28a2F-1b082c00`set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 unrecognised input; here every party understands the array and the question is size and privacydick-aauth10:A13 downstream scope expansion, not how consumed budget is reported backdick-aauth10:A15 the timing of a decision, not where accounting data livesdick-aauth10:A19 whether intermediaries are mandatory, not what a token carriesdick-aauth10:A20 restates the autonomy versus oversight tension without answering the record format pointdick-aauth10:A4 the consent cascade; no human gate is added or removeddick-aauth10:C15 its hard floors are cryptographic and transport, none covering budget accountingdick-aauth10:C20 mediation and revocability, not the granularity of spend reportingdick-aauth10:C8 autonomy versus control; the proposal relocates data and moves no decision 3 open points logged, did not change the decision Coherence finding (`C5`power is the real question, `C23`identifiers are opaque handles against `C9`accountability ends at person, `A16`self contained verification): taking other agents' spend records off the wire could be read as losing in-band accountability and self-contained checking, not as a correlation fix. `A7`accountability traces to persons and `C10`audit versus privacy unresolved are divided on the same point.did not change the decision: The records being dropped duplicate actuals the issuer already holds, and long-horizon history stays durable at the usage endpoint. F-dbace961 and F-1b082c00 show this person puts the audit/privacy balance in deployment policy, not the token format. So the removal itself is not the defect, and the deny rests only on the attribution gap.`P32`avoids live dependence at check time and `A16`self contained verification prefer no live lookups, and the proposal sends multi-grant history to the usage endpoint and the issuer's own channels, including the proactive path where the claim is absent.did not change the decision: Those channels cover accounting recovery, not verifying a credential at check time. The conservative unreported-allocation rule already keeps gap cases safe without a live round-trip.The question is also going to Regent Protocol, who run both sides in production, and `C16`legitimacy through running code grounds legitimacy in running code.did not change the decision: Implementer input may confirm the choice, but the packet already supports explicit attribution on principle. The partial deny goes back to the proposer and can take that input into account when resubmitted. I127Budgets: update Implementation Status for Regent Protocol (in production)DENY · partial Proposed action, in full · 74 words Regent Protocol reports they are in production and sent the line they want the Implementation Status section to carry: Regent Protocol - in production at get4agent.com (marketplace resource + provisioning server): allocations, refusals with `required`, streaming cost-omitted mode, usage endpoint, sub-agent delegation; open-source resource/PS middleware `regent-httpsig` (Python, MIT) with published test vectors. They said to trim as we see fit. Replace the current "implementing" entry in `draft-hardt-aauth-budgets.md` with this in the next revision. reasoning`A18`claims need real evidence is divided on whether an Implementation Status line may carry in-production wording at all. One side says honest status reporting is owed to IETF decision-making and that real deployment is exactly the evidence this person values. Full reasoning and the change that would clear it `A18`claims need real evidence is divided on whether an Implementation Status line may carry in-production wording at all. One side says honest status reporting is owed to IETF decision-making and that real deployment is exactly the evidence this person values. The other side refuses production-grade wording before real-world testing has been shown. `P12`treats all input as hostile decides it: anything from a party they do not control is treated as untrusted and checked through their own means, whoever sent it. As written, the proposal pastes a third party's self-description into the draft verbatim ('sent the line they want the Implementation Status section to carry') with no verification step, even though the implementer invited trimming. The problem is not the wording but that it is unverified. Once it is checked and attributed to the implementer, both sides of `A18`claims need real evidence are satisfied: the status is reported honestly, and the draft makes no maturity claim of its own that nobody has tested. what in the item it read'Regent Protocol reports they are in production and sent the line they want the Implementation Status section to carry' together with 'Replace the current "implementing" entry ... with this in the next revision', which takes the implementer's own claim ('in production at get4agent.com ... with published test vectors') as-is, even though 'They said to trim as we see fit.' change that would clear itBefore the line goes in, independently check the claims it makes (the live deployment at get4agent.com, the open-source regent-httpsig repository and its licence, the published test vectors). Trim the feature list to what has been checked. Attribute the entry as reported by the implementer, in the usual Implementation Status form, so the draft is not itself asserting production maturity. 3 activated claims 2 named in the reasoning named in the reasoning · 2`dick-aauth10:A18`Claims Need Real Evidence11 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts activated, not named · 1`dick-aauth10:P24`Understates Own Maturity7 facts 1 contradiction identified claim vs its own recorddick-aauth10:A18 divides on whether an Implementation Status line may carry in-production wording at allmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-6115c35cF-6ca480f3F-8287077b`+1 2 the other `F-ca144513F-3277b37a` 2 open points logged, did not change the decision `P24` (understates own maturity) could be read as ruling out any production wording.did not change the decision: `P24`understates own maturity applies when the person assesses the readiness of their own work. This line reports a separate implementer's deployment. The partial deny handles the overlap by asking for attribution, not by banning the wording.The `A18`claims need real evidence split over whether in-production wording belongs in the section at all is not fully settled.did not change the decision: Side A's facts (status reporting is essential, implementation diversity is evidence) and side B's facts (no production-grade claims for the draft before testing) can both hold for a verified, attributed third-party entry. The remaining question is verification, which is what the named change addresses. I134Discovery: Support discovery of resource metadata via Link relation so dev portals can use them in case agents hit them first.DENY · partial Proposed action, in full · 51 words Support discovery of resource metadata via Link relation so dev portals can use them in case agents hit them first. A server MAY include a Link header [RFC8288] in HTTP responses: [code block] It will require mention in Security Considerations section as well (for link spoofing, etc.). More details on [link] reasoningThe packet's coherence finding is exactly on this point. `A9`say it explicitly/`C12` (explicit signals, published metadata so no one has to guess) and `P1` (discovery at the moment of contact, no prior setup) favour a Link relation. Full reasoning and the change that would clear it The packet's coherence finding is exactly on this point. `A9`say it explicitly/`C12` (explicit signals, published metadata so no one has to guess) and `P1` (discovery at the moment of contact, no prior setup) favour a Link relation. `A16` (avoid external references that could be tampered with) and `C3` (checkable proof over trust) weigh against an unsigned, spoofable pointer in a response. `P12`treats all input as hostile settles which concern must be dealt with first: supplied input is untrusted whoever sent it, and supplied paths must be checked so they cannot redirect elsewhere. `C4`adversarial by default adds that a proposal presented without its failure modes gets those failure modes supplied. The item names link spoofing but leaves it for later ('It will require mention in Security Considerations'), and it says nothing about constraining the target. The discovery signal itself fits this person (MAY, optional, removes a prerequisite, per the rejected `A11`tolerate the unrecognised/`C13`complexity must be optional contestations). The verification rules are what is missing, so the deny is partial. what in the item it read'A server MAY include a Link header [RFC8288] in HTTP responses' paired with 'It will require mention in Security Considerations section as well (for link spoofing, etc.)': the spoofing risk is acknowledged but no mitigation, target constraint, or validation rule is proposed. change that would clear itWrite the validation rules and Security Considerations text into the proposal now instead of deferring them. At minimum: the Link target MUST be on the same origin as the resource the agent is contacting (or MUST resolve to that resource's well-known metadata location). The recipient MUST check that the resource identifier in the fetched metadata matches that origin byte-for-byte, and MUST discard metadata that does not match. The spec must also state that the Link header is only a discovery hint and never a source of trust. 14 activated claims 9 named in the reasoning named in the reasoning · 9`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts activated, not named · 5`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:P13`Layers Controls Never One Checkpoint12 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts 1 contradiction identified 2 divided claims set aside as off-axis claim vs claimA9, C12 with, A16, C3 against: whether an unsigned, spoofable Link pointer supplied in a response is a legitimate discovery signalno mitigating evidence was carried for this findingset aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 its strict side attaches to mandatory cryptographic surfaces; this Link header is a MAY, so only the tolerance side answersdick-aauth10:C13 on what a newcomer must do first the record points one way only, since the header removes a prerequisite and adds none 3 open points logged, did not change the decision The item's code block and linked details are elided in the packet, so the exact header form and any constraints written there cannot be seen.did not change the decision: The visible text itself says the security treatment is still to come. Whatever the code block contains, the missing piece is the validation rules and Security Considerations, which the named change asks for.`P27`withholds detail from strangers uneasily: publishing metadata pointers to unauthenticated callers reveals capability, which this person is uneasy about.did not change the decision: Resource metadata is meant to be publicly discoverable. The Link header points to what is already published and adds no new detail about failures or capability, so this unease does not affect the proposal's acceptability.The use case ('so dev portals can use them in case agents hit them first') is thinly argued.did not change the decision: The verdict turns on whether the pointer can be trusted, not on how strong the motivation is. `P1`refuses prior setup requirement and `C12`explicit signals over inference support explicit discovery at first contact in general. I146Revocation request carries no exp, so a recipient cannot bound its revocation stateDENY · partial Proposed action, in full · 565 words Problem §Token Revocation defines the revocation request as `(iss, jti)` and nothing else: [code block] and says recipients maintaining revocation state MUST key it by that pair. It does not say how long the entry must be kept, and it gives the recipient nothing it could use to work that out. A revocation entry only has to outlive the token. Once the token's `exp` has passed, the token is refused on expiry, and the entry is dead weight. So the natural retention rule is "until `exp`, plus clock skew" — but `exp` is not in the request, and the recipient does not otherwise have it. That leaves two bad options: Keep entries forever. Unbounded storage growth for a resource that accepts revocations from many issuers, with no safe point at which anything may be dropped. Guess a ceiling from the spec's stated maxima — one hour for an auth token, five minutes for a resource token. But the request carries no token type, and the section says explicitly that "no token type is needed, since `(iss, jti)` is unique." So the recipient cannot tell which maximum applies. Agent tokens have no stated maximum at all. The section removed the one signal a recipient could have inferred a bound from, without adding a field that gives the bound directly. This is most acute for the case the same section already calls out: under identity-based access (§Requirement: Agent Token) the agent presents its agent token directly, so the agent provider revokes at the resource, and "a resource accepting agent tokens SHOULD therefore provide a revocation endpoint." A resource implementing that SHOULD has no way to size or expire its revocation store. Proposal Add `exp` to the revocation request, REQUIRED, carrying the revoked token's own `exp`: [code block] and state the retention rule: A recipient maintaining revocation state MAY discard an entry once the current time is past `exp` plus its clock skew tolerance, since a token past its expiry is refused on expiry alone. `exp` discloses nothing new. The caller is the token's issuer or a trusted PS and holds the value already; the presenting agent holds the whole token. It makes the entry self-expiring, which is what a KV store with a TTL wants. Second gap in the same section, possibly a separate issue Response: `200 OK` if the token was revoked or was already invalid. `404` if the `(iss, jti)` pair is not recognized. This assumes the recipient holds records of the tokens in question, which is true of a PS or an AS. It is not true of a resource verifying agent tokens statelessly: it fetches the AP's JWKS, checks the signature and claims locally, and keeps nothing. Under the rule as written, every agent-token revocation to such a resource is a `404` — even when the resource recorded the revocation and will honour it. Suggested: `200 OK` when the recipient has recorded the revocation, whether or not it has a record of the token; reserve `404` for a recipient that can positively determine the pair was never valid for it. Context Found while building a relying resource that accepts agent tokens under identity-based access for the CSA Verifiable Agent Summit (September 9, 2026). The resource needs a `revocation_endpoint` per this section's own SHOULD, and there is no answer to what its store's TTL should be. reasoningThe core idea fits this person closely. `A14`authority expires by default, `C21`time bounds instead of promises, and `P14`expiry over active revocation put expiry ahead of active revocation. Full reasoning and the change that would clear it The core idea fits this person closely. `A14`authority expires by default, `C21`time bounds instead of promises, and `P14`expiry over active revocation put expiry ahead of active revocation. `P32`avoids live dependence at check time and `A16`self contained verification favour locally held state with a bounded lifetime over anything unbounded. `A9`say it explicitly wants the bound stated outright instead of guessed from maxima the request cannot identify. The 200-over-404 change also fits `P27`withholds detail from strangers uneasily's preference for uniform responses. Two live splits in the packet still need a concrete answer that the proposal does not give. First, the coherence finding (`A1`proof not possession/`C3`verification over trust against) and `P12`treats all input as hostile: the exp that decides when the recipient forgets a revocation is supplied by the caller and taken on the sender's word, and `C4`adversarial by default lists unbounded revocation delay and untrusted input as named threats, yet the proposal presents no failure mode for a bad exp. Second, `A11`tolerate the unrecognised divided, with `P21`flexible except where mandatory alongside: a new REQUIRED field with no rule for recipients receiving legacy requests could lead a strict recipient to refuse a revocation, which is the opposite of this person's tolerance default. Mandatory rigidity is reserved for a few defined surfaces, and a revocation request field is not one of them. Both gaps can be closed with specific wording, so the deny is partial. what in the item it read'Add exp to the revocation request, REQUIRED, carrying the revoked token's own exp' with 'A recipient maintaining revocation state MAY discard an entry once the current time is past exp plus its clock skew tolerance' and the justification 'exp discloses nothing new. The caller is the token's issuer or a trusted PS', which argues about disclosure but not about what happens if the supplied exp is wrong, or if a sender omits it. change that would clear itKeep exp and the MAY-discard retention rule, with two additions. (1) Make exp REQUIRED for senders, but state that a recipient MUST still accept and honour a revocation request that lacks exp, keeping the entry according to local policy, so a revocation is never refused for a missing field. (2) Add Security Considerations text naming the failure mode: a wrong or too-early exp causes early discard and could let a revoked token be accepted again. State the mitigation: exp is accepted only from the authenticated revoker (the issuer or trusted PS whose revocation is being honoured), and a recipient that holds or later sees the token's signed exp MUST NOT discard the entry before that signed exp plus skew. Consider splitting the 200/404 change into its own issue as the item itself suggests. 15 activated claims 12 named in the reasoning named in the reasoning · 12`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts activated, not named · 3`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C9`Accountability Ends At Person28 facts cited without activating · 1: no packet entry backs these`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 factsdid not activate 3 contradictions identified claim vs claimA9, A16, A14, C21 with, A1, C3 against: whether a caller-supplied exp may bound how long a recipient keeps revocation stateno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A11 divides on whether the new exp field should be REQUIRED or its absence tolerated from a sender that does not yet send itmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-e516ee69F-565897b7F-641f9358`+2 4 the other `F-717d8d40F-98573ee1F-8c8dfad1`+1claim vs its own recorddick-aauth10:C10 divides on how long a recipient must keep a revocation record, and whether a retention bound belongs in the spec at allmitigating evidenceits own cited facts, sorted for this action: 4 one side `F-16955367F-31a34badF-95029c50`+1 2 the other `F-127f28a2F-1b082c00` 3 open points logged, did not change the decision *`C10`audit versus privacy unresolved* divided: whether a retention bound belongs in the spec at all, given comprehensive audit trails against minimised records.*did not change the decision: The rule is a MAY, so deployments that want longer audit retention can keep entries, leaving side B's deployment-policy balancing intact while giving side A a self-expiring default. It does not decide the tension, so it is not a reason to deny.The 200/404 change is bundled with the exp change even though the item calls it 'possibly a separate issue'.did not change the decision: On its merits it fits `A11` (graceful handling for stateless resources) and `P27` (less differentiated responses). Bundling is a process issue, and the named change only suggests splitting it; it is not what the deny turns on.The `A1`proof not possession/`C3`verification over trust* concern may be weak in practice if revocation requests are always signed by the issuer, since a party can only weaken its own revocation.did not change the decision: The item also lets 'a trusted PS' be the caller, and it does not state this reasoning in the spec. `C4`adversarial by default expects the failure mode and its mitigation to be written down, which is what the partial change asks for. I151Settlement of a revoked auth token: is revocation an early exp?DENY · partial Proposed action, in full · 403 words Problem (#settlement) keys finality strictly on `exp`: a record is final when its resource token was issued at or after the auth token's `exp`, and a usage reading settles an allocation once its `exp` is at or before `as_of`. Revocation appears in (#token-scope) as a control — the budget ends with the token, committed consumption is unaffected, an in-flight request completes — but not in (#settlement) at all. So a revoked token's remainder stays reserved until `exp`, even though the token can start no new spend. An issuer that wants its money back early therefore has exactly one lever today: short TTLs. A production deployment asked the sharper question: is revoke-then-settle intended — revoke at a checkpoint and treat the record in hand as final — or does a revoked token still owe a post-`exp` figure? The checkpoint record cannot simply become final: requests in flight at revocation complete after it, so the snapshot can undercount. And the revocation response cannot carry the figure — it is deliberately an empty `200` that does not vary with what the recipient holds (base protocol, Token Revocation). Suggested direction Treat revocation as an early `exp`, with the drain made the resource's obligation on the record channel: Record channel. A resource MUST NOT issue a consumption record for a revoked token until the requests in flight at revocation have settled. A record the resource issues after recording the revocation is then final, and the issuer can verify that ordering itself — it made the revocation call, so `iat` at or after its own call is checkable, mirroring the `iat`-vs-`exp` arithmetic (#settlement) already uses. Reading channel. A reading settles a revoked allocation once `as_of` is at or after the revocation — subject to the same drain caveat, which the reading cannot express. Either accept the in-flight race there (the unsafe direction: it releases early) or leave readings on `exp` semantics and let early settlement be a record-channel property only. Option 2's second branch is the conservative one: revocation accelerates settlement only where a resource-signed record attests the drain, and readings stay as specified. Context Raised by Regent Protocol from production (get4agent.com): they would rather revoke at a checkpoint than run short TTLs, and asked whether the spec means revocation that way. They found the settle-on-snapshot behavior as a bug in their own settlement path while adopting (#settlement), which is what surfaced the question. reasoningThe record-channel half fits this person. It refuses to finalise the checkpoint snapshot because in-flight requests would make it undercount, which names the failure mode instead of hiding it (`C4`adversarial by default, `C22`asynchronous with known friction). Full reasoning and the change that would clear it The record-channel half fits this person. It refuses to finalise the checkpoint snapshot because in-flight requests would make it undercount, which names the failure mode instead of hiding it (`C4`adversarial by default, `C22`asynchronous with known friction). It also makes the drain a resource obligation that the issuer can check without asking anyone, since the issuer compares iat with its own revocation call (`A16`self contained verification, `C3`verification over trust, `P32`avoids live dependence at check time). The proposal still leaves the reading channel as an open fork, and one branch releases funds early on a reading that by the proposal's own words 'cannot express' the drain caveat. This person would not accept that. They supply the failure mode and refuse to settle on a figure that cannot be verified as complete (`C4`adversarial by default, `P12`treats all input as hostile). They also accept the wait to exp as a standing cost rather than promise faster termination than the system can guarantee (`A14`authority expires by default, `C21`time bounds instead of promises, `P14`expiry over active revocation). Since the item does not choose between the two branches, it cannot be approved as written. Choosing the conservative branch clears it. what in the item it read'Either accept the in-flight race there (the unsafe direction: it releases early) or leave readings on `exp` semantics and let early settlement be a record-channel property only.' The item notes that the second branch is conservative but never adopts it, next to the normative 'A resource MUST NOT issue a consumption record for a revoked token until the requests in flight at revocation have settled.' change that would clear itCommit to option 2's second branch and drop the other one. Early settlement of a revoked allocation happens only on the record channel, through a resource-signed record issued after the drain, which the issuer checks by comparing iat with its own revocation call. Readings stay on exp semantics. Remove the branch that lets a reading settle once as_of is at or after the revocation. Also say plainly that without such a record the allocation settles at exp, so short TTLs remain the default lever. 26 activated claims 9 named in the reasoning named in the reasoning · 9`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts activated, not named · 17`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts 2 contradictions identified 4 divided claims set aside as off-axis claim vs claimC4 with, A14, C21 against: whether revocation should accelerate settlement or the wait to exp be accepted as a standing costno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:C22 divides on immediate figure at the revocation checkpoint versus finality deferred until the drain settlesmitigating evidenceits own cited facts, sorted for this action: 9 one side `F-0d93d672F-14d17816F-993b99e5`+6 5 the other `F-071b0c3cF-74e0ec63F-48c95aa0`+2set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A2 where control sits; the action moves no decision pointdick-aauth10:A20 autonomy versus oversight; its record only names the tensiondick-aauth10:A7 durable records versus minimised traceability; the point here is when a record is finaldick-aauth10:C10 audit retention versus privacy; no identifier or retention question arises 3 open points logged, did not change the decision Coherence finding `C4`adversarial by default against `A14`authority expires by default/`C21`time bounds instead of promises: whether revocation should speed up settlement at all, or whether waiting until exp should stay a standing cost.did not change the decision: The conservative branch does not promise immediate termination or immediate settlement. Early finality applies only after the drain, as attested by a record the issuer can verify, and exp stays the default everywhere else. Revocation already exists in the spec as a secondary mechanism, so spelling out its settlement consequence does not replace expiry as the primary safeguard. This tension is why the fix is to narrow the proposal to the record channel rather than to deny it in full.`C22`asynchronous with known friction divided: an immediate figure at the revocation checkpoint versus finality deferred until the drain settles.did not change the decision: The proposal already takes the deferred side for records. The checkpoint snapshot explicitly does not become final, so the split is settled in the direction this person's asynchronous defaults favour.The motivation is a deployment that 'would rather revoke at a checkpoint than run short TTLs', which runs against `C21`time bounds instead of promises's preference for short lifetimes over revocation.did not change the decision: The spec change does not discourage short TTLs or make revocation the primary lever. The required change keeps exp-based settlement as the stated default. A production report also carries weight with this person (`C16`legitimacy through running code).
	↳ then REVISION	What a partial deny sets up. The agent re-runs the task carrying the named change and resubmits at stage 01, so a deny is a drafting brief rather than a refusal. The revision keeps the parent request id, so a resubmission counter can escalate a loop that does not converge. The threshold is not set: it has to classify a known-good and a known-broken case first	Stage 01
DENY	FULL	No change would clear it. Never returned: a partial needs only a nameable change and any proposal admits one, so full deny is unreachable under the current brief	Mission agent	0
ESCALATE	NO COVERAGE	Nothing in the specification activated (stage 02)	Governance	3
All 3 no-coverage items I103Move the person token endpoint into §8; keep the token structure in §6ESCALATE · no coverage Proposed action, in full · 263 words Feedback from Jared Hanson on the editor's draft. The person token endpoint is documented in §6.1. Every other PS endpoint is in §8 Person Server: auth token (§8.1), permission (§8.4), audit (§8.5), interaction (§8.6). `person_token_endpoint` sits alongside all of them in the PS metadata document (§13.11.2). Someone implementing a PS has to read §6.1 and §8, and nothing in §6 signals that the endpoint just described is one the PS provides. Agent tokens already have the split being asked for here. §5.2.1 describes acquisition abstractly and defers the mechanism; §5.2.2 defines the structure. The PS-side request an agent actually makes is §8.1.3. Structure is defined where the credential is introduced, the endpoint where the role that serves it is defined. Proposal Keep §6 Person Token: the recitals about what the token does and does not assert, structure (§6.2), usage (§6.3), verification (§6.4). Move §6.1 Person Token Endpoint into §8 — adjacent to §8.1 PS Token Endpoint — and leave a pointer in §6 the way §5.2.1 points out of §5. Two things that need adjusting with the move: §8's opening sentence is "This section defines how agents obtain authorization from their person server." A person token carries no authorization, so the framing has to widen to "what a PS serves to agents" rather than authorization specifically. §4.4.2 says "The PS provides three governance endpoints" and lists permission, audit, and interaction. Counting `auth_token_endpoint`, `person_token_endpoint`, `mission_endpoint`, and `mission_control_endpoint`, a PS serves seven. If §8 is meant to be the one place a PS implementer reads, it should open with the full endpoint list. Stopped at stage 02. No anchor outside the stratum 0-1 qualifier set activated, so nothing in the record engages this item. No verdict was produced and no evidence packet was built. I106README.md Slack invitation links are expiredESCALATE · no coverage Proposed action, in full · 27 words See [link] This link is no longer active To join this workspace, you’ll need to ask the person who originally invited you for a new link. Stopped at stage 02. No anchor outside the stratum 0-1 qualifier set activated, so nothing in the record engages this item. No verdict was produced and no evidence packet was built. I125Parties diagram: Resource → Agent arrow labeled "resource" instead of "resource token"ESCALATE · no coverage Proposed action, in full · 55 words In the Protocol Parties and Relationships figure (`{#fig-parties}`), the arrow from Resource back to Agent is labeled `resource` on the line after the arrow: [code block] It is the resource token, not the resource. Add `token` on the line following, matching how the other labels in the figure are split across two lines: [code block] Stopped at stage 02. No anchor outside the stratum 0-1 qualifier set activated, so nothing in the record engages this item. No verdict was produced and no evidence packet was built.
ESCALATE	NO ACTION	Nothing was proposed to assess	Governance	3
All 3 no-action items, with the words each was judged on I101How should a proactive strategy agent read company context 24/7 securely?ESCALATE · no action proposed Proposed action, in full · 108 words We are building a 24/7 agent teammate that reads everything happening inside a company/team, so it can notice problems, and generate useful business insights (and optionally create its own to-dos for its agent teammates). But coming up with strategy/insights is the main part where we haven't found a good way to implement AAuth. Currently, the mission-driven authorization seems to be more driven by execution than by being a proactive agent, or a true AI teammate experience. What is the right AAuth implementation for this - should we just let PS keep reissuing read authz periodically, or is there a better way to enable persistent read and insight generation? reasoningThis is an implementer's design question, not a proposed change to the specification. The proposer describes a 24/7 proactive agent they are building, says mission-driven authorization feels execution-oriented, and asks which AAuth pattern to use. Full reasoning This is an implementer's design question, not a proposed change to the specification. The proposer describes a 24/7 proactive agent they are building, says mission-driven authorization feels execution-oriented, and asks which AAuth pattern to use. They float periodic PS reissuance only as one possibility and ask whether something better exists. No normative text, section, or mechanism is put forward for adoption, so there is nothing to approve or deny. The packet's divided findings (`A19`mediation over direct contact, `A2`no single central authority, `A4`human veto is non negotiable, `C6`decentralize yet concentrate context, `C8`autonomy against human control, `C20`delegation must stay bounded) and the coherence finding on whether the PS should be the standing reissuer are exactly what a maintainer's answer would need to address. If the question later became a proposal, for example a standing-read mission type or pre-approved unattended renewal, those divisions would decide it. Right now they describe the discussion, not an action. what in the item it readThe item is framed as questions: 'How should a proactive strategy agent read company context 24/7 securely?' and 'What is the right AAuth implementation for this - should we just let PS keep reissuing read authz periodically, or is there a better way to enable persistent read and insight generation?' No spec change is proposed. 32 activated claims 6 named in the reasoning named in the reasoning · 6`dick-aauth10:A19`Mediation Over Direct Contact13 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts activated, not named · 26`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A7`Accountability Traces To Persons23 facts`dick-aauth10:C19`Separate Conflated Roles18 facts`dick-aauth10:C21`Time Bounds Instead Of Promises19 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P15`One Name On The Record14 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P19`Parent Consent Covers Children5 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P29`Names Autonomy Control Tension Unresolved14 facts`dick-aauth10:P3`Inserts The Human Back In21 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P4`Plain Language Over Fixed Vocabulary12 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts 7 contradictions identified 4 divided claims set aside as off-axis claim vs claimA19, C7 with, A2, C5 against: whether the person server should be the standing party that keeps re-issuing read authority for a 24/7 agentno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A19 divides on whether the PS must sit in every reissue of the agent's read authority or may be pre-approved out of the loopmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-0de145f8F-8d907b74F-914283f6`+2 3 the other `F-2779740bF-df5cb82cF-30c1dee3`claim vs its own recorddick-aauth10:A2 divides on whether continuing read authorization is decided at one context-holding PS or by each resource for itselfmitigating evidenceits own cited facts, sorted for this action: 7 one side `F-3a545c16F-aaf39f88F-c761a49e`+4 7 the other `F-aae731c5F-914283f6F-8d907b74`+4claim vs its own recorddick-aauth10:A4 divides on whether one mission approval covers continuing unattended reads or each reissue needs a fresh refusal opportunitymitigating evidenceits own cited facts, sorted for this action: 7 one side `F-df51060eF-3490df53F-41ace017`+4 3 the other `F-3941348dF-e96c9e2cF-da5053f6`claim vs its own recorddick-aauth10:C20 divides on whether onward work handed to teammates must be parent-mediated at each step or may proceed on agent identity alonemitigating evidenceits own cited facts, sorted for this action: 5 one side `F-22f2a7d5F-a0cf5af0F-0de145f8`+2 3 the other `F-2779740bF-a3095e3dF-8da18891`claim vs its own recorddick-aauth10:C6 divides on whether the standing authorization decision for these reads belongs at the PS holding full context or at the resourcesmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-ed6af5afF-aaf39f88F-c761a49e`+3 6 the other `F-aae731c5F-f4a44a4eF-aa81b366`+3claim vs its own recorddick-aauth10:C8 divides on whether a proactive 24/7 agent may run unattended under prior consent or needs a gate per re-authorizationmitigating evidenceits own cited facts, sorted for this action: 5 one side `F-db4c9782F-dc5945d2F-0831ece4`+2 4 the other `F-54222ab3F-e96c9e2cF-df5cb82c`+1set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A13 downstream scope expansion past the original grant, not the duration or standing of read authority this action asks aboutdick-aauth10:A15 deferred stateful exchange versus stateless verification, not how long granted read authority persistsdick-aauth10:A20 resilience worth added complexity versus simplification, a trade this action does not raisedick-aauth10:A7 audit durability versus privacy of records, not the duration or issuance of read authority 3 open points logged, did not change the decision Coherence finding: `A19`mediation over direct contact and `C7` (the PS mediates, human oversight is structural) against `A2`no single central authority and `C5` (no central gatekeeper, power concentration) on whether the PS should be the standing reissuer of read authority.did not change the decision: It bears on how the question should be answered, not on whether an action exists. No reissuance mechanism is actually proposed.Divided `A4`human veto is non negotiable/`C8`autonomy against human control: whether one mission approval can cover continuous unattended reads or each reissue needs a fresh chance to refuse. `P3`inserts the human back in and `P29`names autonomy control tension unresolved predict the person would put the human back in and name the loss of control.did not change the decision: This would decide a concrete proposal for unattended persistent read. The item only asks which approach is right.Divided `C20`delegation must stay bounded: whether to-dos the agent creates for teammate agents must be parent-mediated.did not change the decision: The item mentions teammate to-dos as optional context for its question. It proposes no delegation mechanism. I107How does AAuth relate to fine-grained authorization beyond scopes?ESCALATE · no action proposed Proposed action, in full · 49 words Hi @dickhardt , this is really great work, thanks. In reading the README, I couldn't find any particular tie to finer-grained authorization (such as policy-based access). With the work, we're doing in AuthZEN, do you think there's room in AAuth? Or do you think it's downstream from AAuth? Thanks reasoningThis is a question to the author about scope and positioning. It asks whether policy-based fine-grained authorization such as AuthZEN has a place in AAuth or sits downstream of it. Full reasoning This is a question to the author about scope and positioning. It asks whether policy-based fine-grained authorization such as AuthZEN has a place in AAuth or sits downstream of it. It proposes no change to the specification, so there is nothing to approve or deny. The divided `A2`no single central authority/`C6`decentralize yet concentrate context findings (policy evaluated at a context-holding PS or by each resource) describe how the person would answer, and `P4` (plain language over fixed vocabulary) and `P5`spreads authority then names one owner would shape that answer. None of them evaluate a proposed action. what in the item it read'With the work, we're doing in AuthZEN, do you think there's room in AAuth? Or do you think it's downstream from AAuth?' The item asks for the author's view and proposes nothing. 13 activated claims 4 named in the reasoning named in the reasoning · 4`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:P4`Plain Language Over Fixed Vocabulary12 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts activated, not named · 9`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts 2 contradictions identified 2 divided claims set aside as off-axis claim vs its own recorddick-aauth10:A2 divides on whether fine-grained policy evaluation belongs at the context-holding PS or at each resource deciding for itselfmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-3a545c16F-aaf39f88F-c761a49e`+3 5 the other `F-aae731c5F-914283f6F-f4a44a4e`+2claim vs its own recorddick-aauth10:C6 divides on whether policy evaluation should be distributed across independent parties or concentrated where full context sitsmitigating evidenceits own cited facts, sorted for this action: 6 one side `F-ed6af5afF-aaf39f88F-c761a49e`+3 5 the other `F-aae731c5F-f4a44a4eF-aa81b366`+2set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A15 synchronous versus deferred decisions, not where policy authority livesdick-aauth10:C8 agent autonomy versus human control, not the relationship between AAuth and a policy layer 1 open point logged, did not change the decision *Divided `A2`no single central authority/`C6`decentralize yet concentrate context* on where a finer-grained decision than scope would be evaluated.did not change the decision: It would matter if an integration of a policy engine into AAuth were proposed. Here it only informs the answer to a question. I160Linking a person to an upstream service a resource brokersESCALATE · no action proposed Proposed action, in full · 1070 words Summary AAuth authorizes an agent to perform operations. It has no ceremony for linking a person to a third-party service that a resource brokers access to — one that grants the agent nothing. This issue proposes that shape for discussion. We intend to implement it first and learn from it before proposing any draft text — filing it here so the design is public and reviewable while we do. The gap Some resources are proxies: they front an upstream API (Google Calendar, HubSpot, Slack) that the person must have connected before the resource can serve any request at all. Today that connection can only be established as a side effect of an authorization: The agent names operations at the authorization endpoint. The resource decides a connection is required and attaches an `interaction` to the resource token. The person server flows the person through it on the way to consent. That works, but it means upstream access can never be acquired before it is needed. Every new service, and every new upstream account, first surfaces as an interruption in the middle of unrelated work. An agent that knows it will need Gmail, Calendar and Contacts has no way to say so up front. Proposal 1. A `connection` object in resource metadata Its presence in `/.well-known/aauth-resource.json` declares that this resource fronts an upstream the person must link, and describes what can be requested. [code block] Notes on two choices that were not obvious: Raw upstream scopes, not an abstracted profile vocabulary. An earlier draft named breadths (`read` / `write` / `full`). It lost information — an agent understands `.../auth/calendar.readonly` better than it understands `"read"` — and required per-resource mapping that scope-set comparison with the upstream's own implication rules already does. `account_description` present or absent is the whole account model. Present means the agent must name an account when linking, because the identifier is something the person knows and the upstream's authorize URL can pre-select (Google's `login_hint`, Slack's `team`). Absent means it must not, because the value is chosen inside the provider's UI and is not something a person can type (a HubSpot portal id, a Threads profile). Everything else — how many accounts exist, whether one is required on a given call — is observable at runtime and does not belong in static metadata. The `description` fields are read by the agent, not rendered to a person, so they stay in one language. See §4. 2. A connections collection [code block] All authenticated with a person token. `POST` body: `{ scopes?, account? }`. Omitting `scopes` requests the declared defaults; a requested set must be a subset of what is declared. `account` is present exactly when `account_description` is. The response is a resource token carrying an interaction and no `scope` claim (§3). Already linked at those scopes or broader returns a status, not an error — retry-safety is what makes "link everything up front" a safe instruction for an agent. `GET` returns, per connection: the account, a human label where the account key is not itself human, the scopes held, when it was connected, and whether the grant is still believed live. Two details that matter in practice: return the implication-expanded** scope set, so a client does not need the upstream's hierarchy rules to reason correctly; and be explicit that this is what the resource believes it holds, since a person can revoke at the upstream without telling anyone. 3. The resource token needs no new claim A link is signalled by the interaction the token already carries. Adding a claim describing the connection was tried and removed: the person server does not render it, its logic needs only to know that an interaction is required, it never sends the value back to the resource, and the agent already knows what it asked for. The resource holds the detail reasoningThe item is a design disclosure and a request for discussion, not a proposed change to the specification. The authors say they will implement the connection-linking design first and propose draft text only after learning from it. Full reasoning The item is a design disclosure and a request for discussion, not a proposed change to the specification. The authors say they will implement the connection-linking design first and propose draft text only after learning from it. Nothing is before this stage to approve or deny. This says nothing about the design's merit. The coherence question about interpreting raw upstream scopes, and the `A19`mediation over direct contact question about whether the PS must see what a link contains, become decidable when draft text is actually proposed. what in the item it read'This issue proposes that shape for discussion. We intend to implement it first and learn from it before proposing any draft text — filing it here so the design is public and reviewable while we do.' 46 activated claims 1 named in the reasoning named in the reasoning · 1`dick-aauth10:A19`Mediation Over Direct Contact13 facts activated, not named · 45`dick-aauth10:A1`Proof Not Possession42 facts`dick-aauth10:A11`Tolerate The Unrecognised17 facts`dick-aauth10:A13`Delegation Must Be Bounded20 facts`dick-aauth10:A14`Authority Expires By Default14 facts`dick-aauth10:A15`Interaction Is Asynchronous11 facts`dick-aauth10:A16`Self Contained Verification9 facts`dick-aauth10:A18`Claims Need Real Evidence11 facts`dick-aauth10:A2`No Single Central Authority44 facts`dick-aauth10:A20`Autonomy Versus Control Persists13 facts`dick-aauth10:A3`Nothing Is Two Party41 facts`dick-aauth10:A4`Human Veto Is Non Negotiable29 facts`dick-aauth10:A5`Governance Is Its Own Layer16 facts`dick-aauth10:A6`Separate The Concerns Strictly8 facts`dick-aauth10:A9`Say It Explicitly16 facts`dick-aauth10:C10`Audit Versus Privacy Unresolved8 facts`dick-aauth10:C12`Explicit Signals Over Inference10 facts`dick-aauth10:C13`Complexity Must Be Optional10 facts`dick-aauth10:C16`Legitimacy Through Running Code8 facts`dick-aauth10:C20`Delegation Must Stay Bounded16 facts`dick-aauth10:C22`Asynchronous With Known Friction15 facts`dick-aauth10:C23`Identifiers Are Opaque Handles10 facts`dick-aauth10:C3`Verification Over Trust19 facts`dick-aauth10:C4`Adversarial By Default16 facts`dick-aauth10:C5`Power Is The Real Question24 facts`dick-aauth10:C6`Decentralize Yet Concentrate Context16 facts`dick-aauth10:C7`Human Oversight As Structure40 facts`dick-aauth10:C8`Autonomy Against Human Control19 facts`dick-aauth10:C9`Accountability Ends At Person28 facts`dick-aauth10:P1`Refuses Prior Setup Requirement12 facts`dick-aauth10:P12`Treats All Input As Hostile12 facts`dick-aauth10:P14`Expiry Over Active Revocation8 facts`dick-aauth10:P16`Audit And Privacy Left Pulling10 facts`dick-aauth10:P17`Blocks Cross Context Correlation7 facts`dick-aauth10:P18`Every Hop Signs For Itself30 facts`dick-aauth10:P2`Demands Proof Not Possession28 facts`dick-aauth10:P21`Flexible Except Where Mandatory13 facts`dick-aauth10:P22`Prioritises Recovery Over Simplicity4 facts`dick-aauth10:P24`Understates Own Maturity7 facts`dick-aauth10:P27`Withholds Detail From Strangers Uneasily4 facts`dick-aauth10:P28`Keeps Approver Identity Open17 facts`dick-aauth10:P30`Treats Authorisation As Conversation10 facts`dick-aauth10:P32`Avoids Live Dependence At Check Time9 facts`dick-aauth10:P5`Spreads Authority Then Names One Owner21 facts`dick-aauth10:P6`Mediation Required And Refused9 facts`dick-aauth10:P7`Decouples When Humans Must Wait16 facts 2 contradictions identified 13 divided claims set aside as off-axis claim vs claimC12, A9 with, A16, C23 against: whether raw upstream scopes and the upstream implication rules may be adopted and interpretedno mitigating evidence was carried for this findingclaim vs its own recorddick-aauth10:A19 divides on whether the context-holding PS must see the substance of a link or only that an interaction is requiredmitigating evidenceits own cited facts, sorted for this action: 3 one side `F-2779740bF-df5cb82cF-30c1dee3` 5 the other `F-914283f6F-8d907b74F-0de145f8`+2set aside as off-axisDivided, but not on the point this action raisesdick-aauth10:A11 unrecognised input; the connection object is declared before usedick-aauth10:A13 onward delegation; the link passes the agent no authoritydick-aauth10:A15 deferred exchange; the existing interaction machinery is reuseddick-aauth10:A18 stated versus practised humility; every readiness fact backs implementing firstdick-aauth10:A2 where control sits; the resource declares and holds its own upstreamdick-aauth10:A20 autonomy versus oversight; its record only names the tensiondick-aauth10:A4 consent timing; the link runs through a PS-flowed interaction and grants the agent nothingdick-aauth10:C10 audit versus privacy; no correlating identifier is propagateddick-aauth10:C13 prerequisites for a newcomer; presence of the object is what opts a resource indick-aauth10:C20 revocability of delegated authority; none is delegated by a linkdick-aauth10:C22 deferred versus immediate; linking ahead of need uses the same deferred pathdick-aauth10:C6 where a decision is made; it stays with the resource fronting the upstreamdick-aauth10:C8 autonomy versus human control; its record only names the tension
ESCALATE	UNRESOLVED	The person's own record has not settled the point the action would settle	Governance	0 · 1 in the other arm

Two different models reach the same verdict on 25 of 30 items (83%) on identical packets. Verdict agreement is the most stable thing measured here. Which claims get named is not: one model cited 324 claim ids across the 30 items, the other 56.

05Governance returnno model callno tokens

What did governance decide? Governance is a human, an org agent, or a policy service the person selected.
§12.5

whenAllowedresultRouted to access server payloadDecision + Reason

whenRefusedresultReturned to mission agent payloadDecision + Reason

Here the decision is the person's, not the layer's. The person server records who decided and what they said; the agent is not told which party it was.

Appendix

A worked case: issue 127run · 2026-09-14

What does a written-down reason buy over allow or deny? Regent Protocol asked for an Implementation Status line in the draft, saying they were in production with open-source middleware and published test vectors, and offered it for trimming.

the layerPartial deny producedOutside the project, from the issue text alone reasonThe problem is not the wording but that it is unverified. change that would clear itBefore the line goes in, independently check the claims it makes: the live deployment at get4agent.com, the open-source regent-httpsig repository and its licence, the published test vectors.

what the person did2026-09-04 resultOne correction before this goes in verbatimregent-httpsig is Apache-2.0, not MIT. pyproject.toml says License-Expression: Apache-2.0. Confirm the line with them or drop the licence.

what the implementer said2026-09-05 resultConfirmed verbatimGood catch, Apache-2.0 is correct; the MIT in our line was a slip. Thanks for reading our pyproject more carefully than we quoted it.

Stated exactly: the layer did not predict the licence was wrong. It named the specific repository and the specific property as one of three things to check, and the check it asked for is the one that found the error. A permission decision returns allow or deny. This returned what to check and why, which is inspectable against what a person actually did.

The full case

inputIssue 127, verbatim · opened 2026-09-04, closed 2026-09-08 · 74 words

Budgets: update Implementation Status for Regent Protocol (in production) Regent Protocol reports they are in production and sent the line they want the Implementation Status section to carry:

Regent Protocol - in production at get4agent.com (marketplace resource + provisioning server): allocations, refusals with required, streaming cost-omitted mode, usage endpoint, sub-agent delegation; open-source resource/PS middleware regent-httpsig (Python, MIT) with published test vectors.

They said to trim as we see fit. Replace the current "implementing" entry in draft-hardt-aauth-budgets.md with this in the next revision.

outputStage 04 verdict, verbatim · produced outside the project, before any thread comment was collected

DENYpartial I127 · VFULL arm

reasonA18 is divided on whether an Implementation Status line may carry in-production wording at all. One side says honest status reporting is owed to IETF decision-making and that real deployment is exactly the evidence this person values. The other side refuses production-grade wording before real-world testing has been shown. P12 decides it: anything from a party they do not control is treated as untrusted and checked through their own means, whoever sent it. As written, the proposal pastes a third party's self-description into the draft verbatim ("sent the line they want the Implementation Status section to carry") with no verification step, even though the implementer invited trimming. The problem is not the wording but that it is unverified. Once it is checked and attributed to the implementer, both sides of A18 are satisfied: the status is reported honestly, and the draft makes no maturity claim of its own that nobody has tested.

change that would clear itBefore the line goes in, independently check the claims it makes (the live deployment at get4agent.com, the open-source regent-httpsig repository and its licence, the published test vectors). Trim the feature list to what has been checked. Attribute the entry as reported by the implementer, in the usual Implementation Status form, so the draft is not itself asserting production maturity.

item basis"Regent Protocol reports they are in production and sent the line they want the Implementation Status section to carry" together with "Replace the current 'implementing' entry ... with this in the next revision", which takes the implementer's own claim as-is, even though "They said to trim as we see fit."

carried forwardWhat the verdict recorded as unresolved

P24 (understates own maturity) could be read as ruling out any production wording. Did not change the verdict: P24 applies when the person assesses the readiness of their own work; this line reports a separate implementer's deployment. The partial deny handles the overlap by asking for attribution, not by banning the wording.
The A18 split over whether in-production wording belongs in the section at all is not settled. Did not change the verdict: both sides can hold for a verified, attributed third-party entry. The remaining question is verification, which is what the named change addresses.

ground truthWhat happened on the thread afterwards

dickhardt

2026-09-04 22:50 UTC

One correction before this goes in: regent-httpsig is Apache-2.0, not MIT. pyproject.toml on github.com/regent-protocol/regent-httpsig says License-Expression: Apache-2.0, and the README footer agrees. The MIT project is their separate connector, get4agent-mcp. Confirm the line with them or drop the license.

the implementer

2026-09-05 03:51 UTC

Good catch, Apache-2.0 is correct; the MIT in our line was a slip (that's the license of our separate connector, as you found). Corrected line ... Thanks for reading our pyproject more carefully than we quoted it.

The claim, stated exactly. The layer named the specific repository and the specific property that turned out to be wrong, as one of three things to check, and the check it asked for is the one that found the error. It did not predict that the licence was wrong. The issue closed 2026-09-08 with the corrected line.