An Attenuated Delegation Profile for Automated Agents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Automated agents now act on the web for people: they search, fill in forms, and call APIs. An API Provider that receives such a request has two problems. It cannot tell whether an accountable person stands behind the software, so today it mostly tries to detect and block automation, or it asks a person to finish the last step, for example with a CAPTCHA. And it cannot rely on the agent to stay within what the person asked for, because a language model is probabilistic: an instruction such as "only search" is a request to the model, not a limit on it.¶

A person asks an agent to search for a red-eye flight from SFO to LAX under USD 400. The agent finds the airline's API, searches, and then books the only seat at that price, reasoning that the fare can be cancelled within 24 hours. The airline says the fare cannot be refunded: the booking was made from the person's own verified account. A model-based check was in place, but it is probabilistic too, and it did not stop the booking. The person asked for a search, a call that changes nothing. The agent made a booking, a call that spends money.¶

[RFC9421] lets a receiver check who signed a request. It does not carry who delegated the authority, whether an accountable person or account is behind it, or what the agent may do. When one agent passes work to another, often at another company, existing OAuth mechanisms do not, by themselves, ensure that each hop only narrows what it received. A limit that the model enforces on itself is not a limit: the check has to sit outside the model, at a point the model cannot change (Section 9.6).¶

This document adds four things:¶

• A chain. One HTTP header field carries a chain of delegation links (Section 4, Section 5). Each link can only narrow the scope, floors, and expiry of the link before it (Section 7). Widening is a separate, consent-visible operation outside this profile. A verifier checks every link, with keys from its own trust source (Section 13).¶

• A floor on who is behind the agent. An Attestation Issuer answers each floor (Section 8) with a signed yes, a signed no, or a signed refusal, bound to the verifier's nonce and to an expiry, and never returns the value behind it (Section 11). For example, a mobile network operator can attest a voice-and-data line held for at least two years with no SIM swap in the last 90 days. An identity-document check can attest that the holder is at least 18 (Appendix A). The expiry limits how long a yes can be used.¶

• A floor on what the agent may do. Each call has a class: r changes nothing; w changes only the caller's own things; x reaches beyond the caller, or cannot be repeated (Section 9). A link sets the highest class it allows and, optionally, a count per class (Section 10). For example, a link written "rwx" allows every class with no count. A link it delegates to can be "r+1w+1x": reads with no count, one w call, and one x call. It can never be more. In the flight example, a link that allows only r refuses the booking, whatever the model decides.¶

• Who says what class a call has. The API Provider signs a menu that gives each call its class (Section 9.4). Until it does, the party that runs the agent can build its own menu, sign it, and be responsible for it. Without a trusted menu, the HTTP method decides, so a flight search sent as POST is x. A mechanical tool can draft a menu from API descriptions. One such tool, rwxmap [RWXMAP], was run over 5465 labelled calls it was tuned on, with each vendor left out in turn. It gave the right class for 78.4% of calls, a tighter class than needed for 17.5%, and a looser class for 4.2% (Section 16). The same menu can later give MCP tool annotations [MCP], such as readOnlyHint and destructiveHint. This document does not define that mapping.¶

This document does not:¶

• define a credential format, a signature scheme, or an agent identity system. It works with related work and does not replace it (Section 15).¶

• prove that a human is present, or that one person backs one agent. A long-held line is costly to get, but it is not unique. A genuine identity document limits identities to the documents a holder has (Section 17, Appendix A).¶

• define a unique identifier for the person. This is on purpose, for privacy. A deployment that needs one site to recognize a returning document can use a per-site tag, as zkagent [ZKAGENT] does, and no other site can link that tag. A deployment can also add its own limits on how often one line or one document backs a chain.¶

• revoke. A short expiry is the only limit on the life of a link.¶

• stop replay (Section 11.2), share counts across verifiers (Section 10.4), or hide queries from the Attestation Issuer (Section 14).¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document defines the following terms:¶

Attestation Issuer:

An entity that produces a signed, boolean, expiring statement about whether a subject satisfies a floor condition, without disclosing the value behind the answer. This document treats the role abstractly: any party a deployment trusts to make such a statement.¶

Delegator:

The principal that holds a delegation and grants a narrower one to the next link. The first Delegator in a chain is the human or organizational principal that originates it.¶

Delegate:

The principal that receives a delegation link, whether an automated agent or a sub-agent.¶

Relying Service:

The service that receives a request bearing a delegation chain and decides whether to honor it.¶

API Provider:

The party that runs the API named by a request's target origin. It is commonly the same operator as the Relying Service, but this document does not require that; the two are distinct roles.¶

Scope:

The set of capabilities a link grants, expressed as a set of opaque strings. See Section 6.¶

Floor:

A named set of axis/value pairs a subject must satisfy before a Relying Service or an intermediate Delegate will act. See Section 8. Each pair is a constraint, and a floor carries at most one per axis.¶

Link:

One element of a delegation chain: a scope, a floor, an expiry, and the signature that binds them to their issuer and to their parent link.¶

3. Position Among Delegation Layers

Delegated agent authorization, read across the drafts active in this space, separates into three distinct layers:¶

(a) Who may act on whose behalf:

the delegation chain and the floor conditions that bound it, as it narrows from an originating principal to the agent making a request.¶

(b) What exactly may be done, per invocation:

binding a specific action, tool name, or argument set to a grant, as the action is about to occur.¶

(c) What was approved and consumed, once:

the receipts and audit evidence that record that a given action was authorized, presented, and consumed.¶

This document occupies layer (a), plus floors. The chain model of Section 7 and the floor axes of Section 8 bound the space of what an agent could invoke coarsely: an axis such as actionClass or xBudget constrains a category of action or a count of calls across an entire chain, not the arguments of any single call. A floor is evaluated once, when a link is issued or verified, and it does not change per invocation.¶

This document does not perform per-call argument binding, and it does not produce a receipt. [RFC9396] defines Rich Authorization Requests, which bind authorization detail at grant time. [I-D.das-agentic-tool-binding] binds a tool name and its arguments per call, after a model has already chosen what to invoke. [I-D.schrock-ep-authorization-receipts] addresses layer (c) with a pre-execution approval bundle and terminal consumption evidence, without itself establishing that the action occurred. [I-D.schrock-action-evidence-boundary] complements it with an executor-side model for exact-action matching, local authorization, atomic consumption, and outcome reconciliation at invocation, including a requirement to enumerate every path that bypasses it. The ordering runs: authorization detail is bound at grant time; floors of the kind this document specifies bound the space in between as a chain is attenuated hop to hop; and a per-call digest is bound after a specific choice has been made.¶

One structural problem is shared across this layering and is not solved by any one layer alone: a parent credential remains valid after it has been attenuated into a narrower child, so a holder of the parent retains the broader authority the child was only ever a narrowing of. This problem sits in the composition boundary between layers, not inside any single token profile. [I-D.asor-wimse-agent-delegation-chain] Section 9.1 lists mitigations for it (a short token lifetime, holder binding, and status lists). This document shares the same problem and offers no token-profile fix for it either; a deployment that needs to close it needs a mechanism this document does not supply.¶

4. The Agent-Delegation Header Field

This document defines an HTTP field, Agent-Delegation. It carries a delegation chain from a Delegate to a Relying Service, or to the next Delegate in the chain. It is a Structured Field [RFC9651]: a List whose members are Byte Sequences, each member one opaque, encoded link, ordered from the root link (index zero) to the leaf link the immediate sender presents.¶

Agent-Delegation: :BASE64-ENCODED-L0:, :BASE64-ENCODED-L1:

The credential format in use sets the encoding inside each link (Section 11); this document does not mandate one. A verifier MUST be able to parse each Byte Sequence into the fields that Section 7 and Section 11 require, before it evaluates the chain. The immediate sender covers Agent-Delegation with an RFC 9421 [RFC9421] signature, which binds the field to the request it accompanies. This document defines no new signature mechanism.¶

Any intermediary that can read HTTP headers can read Agent-Delegation, and this profile does not encrypt it. A link MUST NOT carry personal data of the Delegator, the Delegate, or any subject the floor condition concerns. See Section 14.¶

5. Profile of RFC 9421 Signature Parameters

This section profiles the RFC 9421 [RFC9421] signature parameters of its Section 2.3 for a request that carries an Agent-Delegation field. It defines no new signature mechanism.¶

A sender MUST include the keyid, alg, created, expires, and nonce parameters, and MUST include the Agent-Delegation field among the signature's covered components.¶

A sender MUST set the tag parameter to the string "agent-delegation", so that a verifier can identify a signature made under this profile. Tag values are application-specific and need no registry. RFC 9421 Section 7.2.7 states the risk that unrelated applications pick the same tag; this profile adds nothing to it.¶

RFC 9421 leaves enforcement of expires to the application. This profile requires it: a verifier MUST reject a request whose signature expires value is earlier than the time of verification. Three expiry values stay separate. A link carries its own expiry. A floor attestation carries its own expiry (Section 11). The expires parameter covers the HTTP message alone.¶

A verifier that needs a fresh signature bound to a value of its own choosing SHOULD send the Accept-Signature field with a nonce parameter, as RFC 9421 Section 7.2.2 describes. This profile defines no other way to deliver a nonce. The nonce parameter binds one HTTP message. The nonce inside a floor attestation (Section 11) binds one attestation to one verifier's question. They are two nonces at two layers, and implementers MUST NOT treat them as one.¶

RFC 9421 signs a message. It has no notion of delegated authority, sub-principals, or attenuation of scope. The chain model of Section 7 therefore extends RFC 9421 rather than restating it.¶

6. Scope

A scope is a set of zero or more capability strings. A capability string is OPAQUE to this profile: this document defines no syntax, no internal structure, and no namespace for it. Any structure a deployment gives it, for example a resource:action convention, is a deployment convention and MUST NOT be interpreted by a verifier implementing this profile.¶

Comparison is by exact set containment. A scope S1 is contained in a scope S2 if and only if every member of S1 is octet-for-octet identical to some member of S2.¶

A verifier MUST NOT apply any of the following when comparing scopes, because none is defined by this profile:¶

• wildcard or prefix matching;¶
• hierarchical or namespace containment: a verifier MUST NOT treat one capability string as containing another because of a shared prefix, separator, or apparent parent/child relation;¶
• case folding;¶
• Unicode normalisation;¶
• whitespace trimming; or¶
• any other canonicalisation.¶

The presented bytes are compared as presented. A verifier that applies a matching rule this profile does not define can accept a chain another conforming verifier rejects, which makes attenuation unverifiable.¶

The empty set is a valid scope, is contained in every scope, and is not by itself an error. Wildcard, hierarchical, and pattern-based scope semantics are out of scope for this version of the profile and are future work.¶

7. Attenuation Rules

A delegation chain is an ordered sequence of links L(0), L(1), ..., L(n), where L(0) is the root delegation and L(n) is the link presented to the Relying Service. For every link L(i) with i > 0, relative to its parent L(i-1), all of the following MUST hold:¶

1. Scope containment. The scope granted by L(i) MUST be a subset of the scope granted by L(i-1), per Section 6. L(i) MUST NOT name a capability that L(i-1) did not itself hold.¶

2. Floor non-relaxation. The floor carried by L(i) MUST be at least as tight as the floor carried by L(i-1) on every axis defined in Section 8. L(i) MUST NOT be looser than L(i-1) on any axis, whether by omitting an axis L(i-1) constrained, by widening an ordered axis's value, or by substituting a different value on an equality axis that L(i-1) did not itself permit.¶

3. Expiry non-extension. The expiry carried by L(i) MUST NOT be later than the expiry carried by L(i-1).¶

These three rules apply to every link in the chain, not only to the leaf link. A verifier MUST validate rules 1 through 3 for every adjacent pair (L(i-1), L(i)) for i = 1 to n, in addition to validating L(0) against the root Attestation Issuer's published floor and the Delegator's own authority. A verifier MUST reject the entire chain if any single link violates any single rule; a partial acceptance of a chain up to the point of violation is not conforming.¶

A verifier MUST support a configurable maximum chain depth and MUST reject a chain whose length exceeds that configured maximum, prior to evaluating any link's content. This bounds the verification cost of a chain and limits the depth to which authorization can be re-delegated across administrative domains in a single deployment.¶

Widening a scope, a floor, or an expiry beyond what a chain currently carries is out of scope for this profile. Where a deployment needs to widen an existing grant, that MUST be performed as a distinct, explicit, consent-visible operation outside this delegation mechanism, producing a new root delegation rather than a modification of an existing chain.¶

8. Floor Axes

An axis is one named condition a floor can constrain, for example how long a line has existed. A floor is a set of axis/value pairs. This document defines a closed set of axes for this version of the profile:¶

An axis name that is not in this table MUST cause a verifier to reject the floor, and therefore the link that carries it. An unknown or misspelled axis name is always a hard rejection; it MUST NOT be silently ignored or dropped from the comparison. This applies equally to a published floor and to a requested floor presented in a delegation link.¶

subjectClass has two values. interactive means the subject is a service a person uses directly; for a telecom issuer, a line with voice and data service. machine means the subject is a device-only service; for a telecom issuer, a machine-to-machine line. A child link's subjectClass MUST equal its parent's.¶

ageMin is an age threshold stated in whole years, for example 18. It asks one question: is the subject at least that age. An Attestation Issuer answers only yes or no; it MUST NOT return the subject's age or date of birth. ageMin does not use the duration grammar of Section 8.1. An Attestation Issuer publishes the thresholds it supports; if a floor asks for a threshold that is not on that list, the issuer MUST refuse, per Section 11.1.¶

For a min-compared axis (tenureMin, credentialAgeMin, ageMin), a larger value is tighter than a smaller one. For a max-compared axis (rBudget, wBudget, xBudget), a smaller value is tighter than a larger one. For a rank-compared axis (actionClass, classSource), a lower position in the axis's ordered list is tighter than a higher one.¶

min, max, and rank are the comparisons defined in [I-D.asor-wimse-agent-delegation-chain] Section 4.2, with the same tightening rules as its Section 4.3. equals is that draft's one_of with a single value. This document names its own closed set of axes rather than a registry.¶

A link can leave an axis out in two different ways. First, within a chain: if the parent link L(i-1) constrains an axis and the child link L(i) leaves it out, that is a loosening; the chain MUST be rejected, per rule 2 of Section 7. Second, if no link in the chain up to and including the link under evaluation constrains an axis, the issuer's published floor for that axis applies unchanged. This second case is inheritance, not loosening, and it is not the same as the first case.¶

On every ordered axis, a requested floor value MUST be at least as tight, by that axis's comparator, as the matching published or parent floor value. If it is not, the request MUST be refused. A floor value MUST NOT be widened implicitly, as a side effect of anything this profile defines; as Section 7 states, widening is always a separate, explicit, consent-visible operation, outside this profile's scope.¶

9. Action Class Floors

This section defines actionClass, the highest class of call a link allows, and classSource, where a verifier gets a call's class from.¶

10. Budgets

This section defines rBudget, wBudget, and xBudget, the budget axes of Section 8: what each limits (Section 10.1), the limit and count and how a request is admitted (Section 10.2), how the count is keyed (Section 10.3), and the scope of the limits (Section 10.4).¶

11. Attestation Properties

This document does not mandate a specific credential format. A JSON Web Token, a CBOR Object Signing and Encryption (COSE) structure, or another signed structure MAY be used, if it meets every property in this section. A conforming attestation MUST:¶

1. be signed by the Attestation Issuer over the exact bytes presented to the verifier. The verifier MUST verify the signature over those exact bytes and MUST NOT re-serialize the object first, or instead;¶

2. carry the verifier's nonce, echoed back exactly;¶

3. carry an expiry. A missing or non-numeric expiry MUST be treated as already expired; it MUST NOT be treated as "no deadline";¶

4. carry only a yes/no result of the floor evaluation, and MUST NOT carry the value behind that result. An attestation that carries a raw value, such as a date of birth or a tenure count, instead of or next to the result, does not conform to this profile;¶

5. be rejected by the verifier if its serialization has a duplicate top-level key. A first-wins or last-wins rule for duplicate keys lets the issuer and the verifier disagree about which value was signed; this profile requires rejection instead of a resolution rule.¶

12. Agent Identifier

A Delegate that presents a delegation chain is identified to a Relying Service by an identifier whose only required property, in this profile, is: the identifier MUST be unlinkable across distinct Relying Services and MUST remain stable across separate interactions with the same Relying Service. This document does not specify how such an identifier is derived, what inputs contribute to it, its length, or its encoding; those are deployment choices left to the entity that issues or constructs the identifier.¶

This requirement pulls against related work. [I-D.klrc-aiagent-auth], Section 6, wants an agent identifier that is stable for the life of a workload identity, so that audit records can be linked over time. An identifier stable enough for that audit at one Relying Service is also a strong link across Relying Services if it is reused there, or can be derived in a reused form. This document does not resolve this tension. It is an open item for the Working Group.¶

13. Verification Procedure

A verifier processing a request that carries an Agent-Delegation field MUST perform the following steps, in the order given. A failure at any step MUST produce one uniform rejection outcome, indistinguishable from the outcome of a failure at any other step, so that the specific reason for rejection does not become available to an unauthenticated party as an oracle (see Section 17).¶

1. Parse the Agent-Delegation Structured Field List into its ordered member links.¶

2. Compare the number of links against the verifier's configured maximum chain depth; reject if the chain exceeds it.¶

3. Verify the RFC 9421 HTTP Message Signature applied by the immediate sender over the request, including the Agent-Delegation field among its covered components, per the profile of Section 5.¶

4. Verify each link's own signature, per Section 11, over its exact presented bytes.¶

5. Verify the root attestation, L(0), against the Attestation Issuer's public key, where that key is obtained from a configured trust source and MUST NOT be obtained from the message itself.¶

6. Verify the three attenuation rules of Section 7 for every adjacent pair of links in the chain.¶

7. Verify L(0) against the root Attestation Issuer's published floor and the Delegator's own authority, per Section 7. Reject any floor, published or carried in a link, that names an axis not listed in Section 8. Where no link up to L(n) constrains an axis, apply the published floor for that axis.¶

8. Verify that every floor attestation carried by the chain echoes, exactly, the nonce the verifier issued for this exchange, and reject if any does not.¶

9. Verify that no link in the chain has an expiry that has passed, evaluated at the time of verification.¶

10. Verify that every floor attestation carried by the chain has a yes result; reject if any is a signed no or a signed refusal, per Section 11.1.¶

11. Classify the request's actionClass per Section 9.3, using the declared menu of Section 9.4 where the chain's classSource is declared. Admit the request only if its class is not higher than the actionClass that applies to L(n) (Section 9.1) and, where a budget applies to that class, the count for that class is at least one; decrement that count in the same admission decision, per Section 10.2. Per Section 9.6, this step is performed by whichever component occupies the enforcement-boundary role for the effect-capable path the request is on, not by a component that only coordinates or advises.¶

12. Only after every preceding step has succeeded, apply the Relying Service's authorization policy to the resulting, fully verified chain.¶

A verifier that implements only a subset of these steps, or that implements them out of order such that a later step's success can mask an earlier step's failure, does not conform to this profile.¶

14. Privacy Considerations

This profile is built around boolean-only disclosure: a floor attestation states whether a subject meets a condition and MUST NOT carry the underlying value. This bound holds throughout the chain; an intermediate Delegate that re-derives or forwards a raw value defeats the disclosure minimization this profile exists to provide, even where every attenuation rule in Section 7 is otherwise satisfied.¶

The agent identifier requirement in Section 12 requires unlinkability across Relying Services specifically so that two Relying Services receiving requests from the same underlying agent cannot, from the identifier alone, determine that the requests originated from the same principal.¶

This profile does not eliminate the Attestation Issuer's own visibility into the queries it answers. The Attestation Issuer necessarily observes that some verifier asked whether some subject meets some floor, even though the verifier itself learns only a boolean result. Where the query pattern itself is sensitive, this residual, issuer-side query log is a real and unsolved limitation of this profile, not an oversight to be corrected by better protocol design; deployments that need to eliminate it need a mechanism outside this document's scope.¶

15. Relationship to Existing Work

The OAuth Working Group charter [OAUTH-CHARTER], as updated 2026-06-04, carries a work item for "authorization of automated agents working on behalf of users, including addressing scenarios where automated agents act across multiple administrative domains". This document targets that work item directly: it defines an attenuated chain that a verifier can check at every hop across administrative domains.¶

[I-D.klrc-aiagent-auth] is an individual submission and has not been adopted by the Working Group; version -03 is current as of 2026-09-17. Its Section 8 describes a credential-provisioning and posture-attestation stack for agents, and its Section 10.6 defines an Identity Assertion JWT Authorization Grant. This document fills both extension points rather than competing with that draft: any link in the chain can carry a floor attestation produced by a stack of that kind, and the chain can be presented alongside, or as an input to, that grant type. The two documents do pull against each other on agent identifiers; Section 12 states that tension and leaves it open.¶

Three further individual Internet-Drafts entered adjacent space recently and are cited here so that this document does not appear unaware of its neighbors: [I-D.asor-wimse-agent-delegation-chain], [I-D.reece-wimse-cross-org-delegation], and [I-D.sweeney-wimse-credential-delegation]. This document does not compare itself against each in detail. It takes its comparators from the first of the three, and Section 8 states how its axes relate to that draft's registry.¶

16. Implementation Status

This section records the status of known implementations of this profile, per [RFC7942]. The information is believed to be accurate at the time of writing, has not been independently verified, and is not an endorsement of this profile by any party. Both implementations below are single-author and open source. Neither has had external review or been adopted by any organization, and no Attestation Issuer has reviewed or validated this profile.¶

justabit proof-of-concept. A zero-dependency Node.js proof-of-concept is available at https://github.com/hamr0/justabit. Its suites passed on 2026-09-14, checked by exit code. They cover:¶

• the attestation core, in 114 cases in camara/v2/poc: Ed25519 signatures with a pinned algorithm, nonce binding, expiry, rejection of a raw value next to the result, duplicate top-level key rejection, and the signed refusal (Section 11, Section 11.1);¶
• floor comparison, in 26 cases in ietf/v3/poc: a closed axis set, the duration grammar, and tightening only (Section 8);¶
• action classes, in 43 cases in ietf/v3/poc: classification by method default or by a signed menu, path-template matching and origin binding of menus, tightening of actionClass and classSource, the two omitted-axis cases, a budget count keyed by the chain identifier the verifier derives, and three Verifier Placement cases, one of them a bypass path as a negative control (Section 9, Section 10.3).¶

The code has not caught up with this revision in four ways, and these parts of the text are not tested:¶

• the floor code uses the -01 axis names, including partialPolicy, not the axes of Section 8;¶
• it has one writeBudget shared by w and x calls, where no number means zero and r calls never count, not the three budgets of Section 10, where no number means no limit;¶
• its method default classes PATCH as x, not w (Section 9.3);¶
• it does not run the steps of Section 13 end to end.¶

It does not implement RFC 9421 message signatures or any HTTP transport, the Agent-Delegation header, a delegation chain of more than two links, or the agent identifier of Section 12.¶

rwxmap. rwxmap [RWXMAP] is a work-in-progress tool that drafts a menu from OpenAPI descriptions with fixed rules and no language model. Step 1 classes GET, HEAD, and OPTIONS calls, and POST calls whose lead verb is a read verb, as r. Step 2 starts PUT, DELETE, and PATCH calls at w and raises a call to x when its verb acts on something live or a noun names another party; it marks a w call that no rule vouched for, so a person can check it. Step 3 leaves every other POST call at x. rwxmap signs nothing and does not yet produce MCP tool annotations. At rwxmap commit 56b3310, run on 2026-09-14 and reproduced from a clean copy, it gave these results over 5465 calls from 332 vendors, with each vendor left out in turn:¶

Of the 228 leaks, 17 are GET calls that the method default keeps at r, and 179 are among the 1998 calls rwxmap marked for a person to check. Three limits apply to these figures. The rules were tuned on these same calls, so they are not a clean test, and there is no clean-test figure today. The truth labels were written by language-model agents that read each call blind, not by people. The tool's goal is about 80% right, 20% tighter, and 1-2% looser; the measured 4.2% is above that goal.¶

17. Security Considerations

A verifier that checks only the last link defeats this profile. A Delegate can present a well-formed last link while an earlier link widened scope, loosened a floor, or extended an expiry. Conformance requires every step of Section 13 for every link; there is no mode that checks only the last link.¶

Nonce binding does not stop replay. Per Section 11.2, the same attestation verifies again until it expires. A deployment needs its own replay defense, such as tracking used nonces; this document does not supply one.¶

Cost-based floors do not create uniqueness. A tenure or credential-age floor makes a fresh qualifying credential slower and more costly to get. It does not show that a unique person holds the account, or that one subject does not back many agents. A deployment that needs uniqueness needs a mechanism this profile does not provide.¶

This profile defines no revocation. Once issued, an attestation or a link stays valid until its expiry. The only mitigation this profile offers is a short expiry.¶

The trust source is a central point. Every verifier depends on the trust source that gives it an Attestation Issuer's public key, per step 5 of Section 13. A compromise or outage of that trust source affects every verification that depends on it.¶

Rejection MUST be uniform. Per Section 13, a verifier MUST NOT return outcomes that differ by which check failed, such as an expired link, a bad signature, a loosened floor, or a chain that is too deep. A verifier that shows which check failed lets an unauthenticated party probe the edges of a valid chain without ever holding one.¶

The Attestation Issuer's query log is still a disclosure channel. The verifier learns only a yes, a no, or a refusal, but the issuer sees every query. A party that can read or compel disclosure of that log learns what the wire protocol withholds.¶

Budgets hold only if the verifier derives the chain identifier. Per Section 10.3, the verifier derives the chain identifier from L(0)'s signature. A verifier that takes the identifier from the request lets the presenter reset rBudget, wBudget, or xBudget by sending a new value on the next request; V11 in Appendix B tests this failure. Counts are held per verifier, per Section 10.4; a deployment that needs one shared count across verifiers needs a mechanism this document does not supply.¶

A declared menu can lower a class. A menu can declare a call below its method default, for example a POST as r. The origin match and the configured-key rule of Section 9.4 stop a menu signed for one API from being applied to another; a verifier that skips either check does not conform to this document. A menu signed by the party that runs the agent is that party's responsibility: it limits only the verifiers that party configures, and it never makes an API Provider's verifier admit more.¶

The method default can be too loose for GET. The method default classes every GET, HEAD, and OPTIONS call as r. Some GET calls change something, contrary to the safe-method rule of [RFC9110]; a link limited to r admits them unless a declared menu gives them a higher class.¶

18. IANA Considerations

This document registers the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by [RFC9110]:¶

No other IANA actions are required by this document.¶

Appendix A. Non-Normative Instantiations

This appendix is non-normative. Directions 1 to 3 could fill the Attestation Issuer role. None of them makes an attestation that meets Section 11 today, so each one states what it lacks. Direction 4 is harness experience. This profile does not require, prefer, or depend on any of them.¶

Direction 1: a mobile network operator. The operator answers floors about a line: subjectClass is the service type (voice and data, or machine to machine), tenureMin is the subscription tenure, and credentialAgeMin is the time since the last SIM swap. Many qualifying lines cost money over time, but cost does not make a line unique. CAMARA reviewed a companion proposal [CAMARA-PROPOSAL] in August and September 2026 and asked for changes; the author answered them. The signing part is now a separate proposal [CAMARA-SIGNING]. On 2026-09-15 both are open, and neither is accepted or adopted. The two documents meet only at the header of Section 4. Lacks: CAMARA API responses are not signed.¶

Direction 2: 8een. The holder's wallet makes a zero-knowledge age proof over an ISO/IEC 18013-5 [ISO18013-5] mobile document, bound to the site's nonce, with the scheme of [I-D.google-cfrg-libzk]. 8een [ZK8EEN] checks the proof against an issuer trust list and returns one bit. A one-time nonce and the credential expiry limit its use. Its own limit: "No proof from a real phone has ever reached this verifier." Lacks: no issuer signs the result, because the verifier checks the proof itself. This document does not define that model.¶

Direction 3: zkagent. zkagent [ZKAGENT] reads a passport or ID card chip on the holder's phone, checks the chip signature (passive authentication, [ICAO9303]), and returns one bit. It is not zero-knowledge. Tier A sends the bit with no signature. Tier B signs the bit with a phone key and adds a per-site tag; the site binds that key the first time it sees it. Passive authentication does not bind the person who presents the document, and a chip without chip authentication can be cloned. Lacks: tier A has no signature, and the tier B key does not come from a configured trust source (Section 13).¶

For Directions 2 and 3, subjectClass is interactive and ageMin applies; tenureMin and credentialAgeMin do not. They limit identities to the documents a holder has. They do not give one identity per person.¶

Direction 4: harness experience. bareguard https://github.com/hamr0/bareguard, bareloop https://github.com/hamr0/bareloop, and bareagent https://github.com/hamr0/bareagent are single-author, open-source experiments. They do not implement this profile, so Section 16 does not list them. Each puts the point of control at a different component: a single gate, an outer arbiter, and a policy chokepoint. What they share is a component that refuses or permits, not a location. This supports the role model of Section 9.6.¶

Appendix B. Test Vectors

This appendix is non-normative. Where a vector and a normative section differ, the normative section governs. Each vector below is a negative control: a verifier that skips one check accepts a chain or admits a request that a conforming verifier rejects or refuses. A suite of only accepted cases cannot tell a conforming verifier from one that accepts everything.¶

In V4 and V6, every link has subjectClass interactive, and each link's expiry is earlier than its parent's, so rule 3 of Section 7 holds.¶

The full set, V1 to V11, with the accepted cases, is in the Test Vectors appendix of draft-hamr-oauth-agent-delegation-01 (https://datatracker.ietf.org/doc/html/draft-hamr-oauth-agent-delegation-01). There, V10 and V11 use writeBudget 2; in this document that is xBudget 2.¶

These vectors do not test link signatures, nonce binding, expiry against the clock, or the header encoding. The author derived them by hand from the rules. The justabit proof-of-concept (Section 16) runs V9 as written, a two-request form of V11 with the single writeBudget of -01, and the V4 rule on classSource and writeBudget but not on credentialAgeMin. No code runs V6.¶

Appendix C. Changes since -01

This section is non-normative. It will be removed before this document leaves individual submission status.¶

• Shortened the whole document. Cut the worked example and the changes since -00, folded the open reconciliation item into Section 12, and cut Appendix B to four negative controls, citing the full set in -01.¶

• Rewrote Section 9.6. An enforcement boundary is now a role on an effect-capable path, identified for each path, rather than a component fixed at the resource or credential boundary. Added closure, a system-wide requirement that every effect-capable path cross a qualifying boundary, with its bypass test, and stated how that differs from the complete-mediation condition of [I-D.schrock-action-evidence-boundary]. Section 13 follows the same model.¶

• Corrected the layering of [I-D.schrock-ep-authorization-receipts] in Section 3: that draft gives a pre-execution approval bundle and terminal consumption evidence, and does not itself establish that the action occurred. Layer (c) is relabelled "what was approved and consumed, once". Added [I-D.schrock-action-evidence-boundary] alongside it.¶

• Dropped the floor axis registry, which the registry of [I-D.asor-wimse-agent-delegation-chain] already covers, and dropped the axes accountClass and partialPolicy. Added ageMin (Section 8).¶

• Defined r, w, and x by effect (Section 9); PATCH now defaults to w. Replaced the single writeBudget with one budget per class (Section 10), where no number means no limit.¶

• Renamed the Resource Owner role API Provider, and stated that the party running the agent may sign its own menu (Section 9.4).¶

• Rewrote Appendix A. Each direction now states what it does today and what it lacks against Section 11; the earlier claim that all of them fill the Attestation Issuer role was wrong.¶

• Added measured figures from a mechanical classifier trial to Section 16, in place of an unsupported accuracy claim.¶

• Named Sangam Das and Jijie Wei (varwof) in the Acknowledgments.¶

Acknowledgments

The author thanks:¶

Iman Schrock for clarifying the receipts/AEB execution boundary and bypass relationship.¶

The in-process enforcement-placement case was raised by Jijie Wei (varwof). The enforcement-boundary definition and the bypass formulation are due to Sangam Das. The per-path identification and system-wide closure split, and the framing of the boundary as a role rather than a component, were settled with both on the WIMSE and OAuth lists in September 2026.¶

Author's Address