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 6 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

A person asks an automated agent to arrange a car rental. That agent does not do the work itself: it engages a second, specialized agent operated by a different company, and that second agent calls the rental service's API. The rental service now receives a request from software that no human has ever spoken to, two hops removed from the person who authorized anything, and operated by an organization the person has no relationship with.¶

The rental service needs three things it cannot currently get: proof that the authority behind the request actually came from that person; assurance that nothing along the way granted itself more than it was given; and the ability to check both without calling back to any of the parties involved.¶

Automated agents increasingly act as principals against network and application APIs on behalf of a human or an organization. Where such an agent's authorization is delegated from a human principal, and potentially re-delegated agent-to-agent across administrative domains, three properties are needed that existing OAuth mechanisms do not by themselves guarantee end to end: that each re-delegation can only narrow what came before it, that a verifier can check the entire chain rather than trusting the last hop, and that the conditions under which a delegation was granted travel with it in a form a verifier can check offline.¶

This document specifies a profile that supplies those three properties. It does not define a new credential format, a new signature scheme, or a new agent identity system. It defines:¶

an HTTP header field for carrying a delegation chain (Section 5); a closed set of attenuation rules that every link in the chain must satisfy relative to its parent (Section 8); the required properties of a floor attestation, independent of its encoding (Section 12); an ordered verification procedure a verifier MUST follow (Section 14); and a profile of the RFC 9421 signature parameters (Section 6).¶

The profile is a composition layer. It assumes an underlying attestation issuer exists somewhere in the deployment and that a trust source can resolve that issuer's key; it says nothing about who or what that issuer is. Appendix A gives one concrete, non-normative instantiation to make the abstract properties concrete for a reader evaluating deployability; nothing in that appendix is required to implement this profile.¶

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 can produce a signed, boolean, expiring statement about whether a subject satisfies a floor condition, without disclosing the underlying value that produced the answer. This document treats the Attestation Issuer abstractly; it may be 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 in the chain. The first Delegator in a chain is the human or organizational principal that originates the delegation.¶

Delegate:

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

Relying Service:

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

Resource Owner:

The party that owns the resource named by a request's target origin and that publishes and signs the declared menu (Section 10.4) governing that origin's classSource declared value. A deployment commonly has the Resource Owner and the Relying Service be the same operator, but this document does not require it; the two are distinct roles, and only the Resource Owner's signing key and the menu's origin binding are constrained by this document, not the roles' organizational identity.¶

Scope:

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

Floor:

A named set of conditions a subject must satisfy, expressed as axis/value pairs, that a Relying Service or an intermediate Delegate requires before it will act. See Section 9. Each axis/value pair within that set is a constraint; a floor is the aggregate of the constraints it 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. Motivation

A delegation chain that is only checked at its endpoint is not a chain; it is a single trust decision with extra steps. If an intermediate Delegate can widen scope, loosen a floor, or extend an expiry beyond what it was itself granted, then the guarantees made at the root of the chain do not survive to the Relying Service, regardless of how carefully the root delegation was constructed. This document's primary technical contribution is to make that failure structurally difficult: attenuation is defined precisely enough that a verifier can check it mechanically at every link, and Section 19 states plainly that a verifier which checks only the final link defeats the entire mechanism.¶

A second, related problem is that authorization conditions are often expressed as raw attribute values (a date of birth, a tenure in days, an account balance) which a Relying Service does not need and should not receive. This document requires that floor conditions be evaluated by the Attestation Issuer and exposed to the chain only as a signed boolean result bound to a verifier's nonce and to an expiry, never as the underlying value. This is a disclosure-minimization requirement independent of the chaining requirement, and both apply together.¶

4. Position Among Delegation Layers

This section is informational. It introduces no new requirement beyond those stated elsewhere in this document; it exists to place this document among neighboring work so a reader does not mistake the boundary this document draws for an oversight.¶

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 down 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, at the moment the action is about to occur.¶

(c) What happened, 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 8 and the floor axes of Section 9, including the extensible registry of Section 9.1, bound the space of what an agent could invoke coarsely: an axis such as actionClass or writeBudget constrains a category of action or a cumulative budget 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, at the moment a request is dispatched, after a model has already chosen what to invoke. [I-D.schrock-ep-authorization-receipts] addresses layer (c), the recorded evidence that an action occurred. Read together, 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, with a receipt recording what happened afterward.¶

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.¶

Implementation experience that informed where this document draws its boundary is summarized, non-normatively, in Appendix A.¶

5. The Agent-Delegation Header Field

This document defines a new HTTP field, Agent-Delegation, that carries a delegation chain from a Delegate to a Relying Service or to the next Delegate in the chain. Agent-Delegation is a Structured Field [RFC8941], specifically a List whose members are Byte Sequences, each Byte Sequence carrying one opaque, encoded delegation link, ordered from the root link (index zero) to the leaf link presented by the immediate sender.¶

The internal encoding of each link is determined by the credential format in use (Section 12); this document does not mandate one. A verifier MUST be able to parse each Byte Sequence member into the fields required by Section 8 and Section 12 before it can evaluate the chain.¶

Agent-Delegation is intended to be covered by an RFC 9421 [RFC9421] HTTP Message Signature applied by the immediate sender, binding the header's content to the request it accompanies. This document specifies the header field and its semantics; it does not define a new signature mechanism, relying on RFC 9421 for message-level signing of the request the header is attached to.¶

Because Agent-Delegation is visible to any intermediary that can read HTTP headers, and is not encrypted by this profile, links MUST NOT carry personal data of the Delegator, the Delegate, or any subject the floor condition concerns. See Section 16.¶

6. Profile of RFC 9421 Signature Parameters

RFC 9421 [RFC9421] Section 2.3 defines a set of signature parameters, including created, expires, nonce, alg, keyid, and tag. This section profiles the use of those parameters for a signature applied over a request carrying an Agent-Delegation field; it does not define a new signature mechanism.¶

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

A sender MUST set the tag signature parameter to the string "agent-delegation", so a verifier can identify signatures made under this profile. RFC 9421 defines tag as "an application-specific tag for the signature as a String value" used "to help identify signatures relevant for specific applications or protocols," and tag values are application-specific strings requiring no registry. RFC 9421 Section 7.2.7 discusses the risk of tag collision between unrelated applications; this profile does not add any mechanism beyond that discussion.¶

RFC 9421 defines the expires parameter, "expiration time as a UNIX timestamp value of type Integer," but leaves its enforcement to the application. This profile therefore requires it: a verifier MUST reject a request whose signature expires value is earlier than the time of verification. This is a requirement this profile adds; RFC 9421 itself does not impose it.¶

RFC 9421 Section 7.2.2 describes the nonce parameter, "a random unique value generated for this signature as a String value," as allowing a verifier to detect replay of the signature itself, and describes a signer providing a creation timestamp and an expiration time to limit the utility of a captured signature value. It further states that a verifier wanting to trigger a new signature from a signer can send the Accept-Signature header field with a new nonce parameter, and that an attacker simply replaying a signature would not be able to generate a new signature with the chosen nonce value. A verifier under this profile that needs a fresh signature bound to a value of its own choosing SHOULD use the Accept-Signature header field carrying a nonce parameter, as described in RFC 9421 Section 7.2.2. This profile does not define a separate nonce-delivery mechanism, because RFC 9421 already provides one.¶

RFC 9421's nonce signature parameter binds one HTTP message. The nonce carried inside a floor attestation (Section 12) binds one attestation to one verifier's question. These are two distinct nonces at two distinct layers, and implementers MUST NOT conflate them.¶

RFC 9421 defines message-level signing and provides no notion of delegated authority, sub-principals, or attenuation of scope. The chain model of Section 8 therefore extends RFC 9421 rather than restating it.¶

7. 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 over case-sensitive, octet-for-octet string equality. 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 any 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 in exactly the way this profile exists to prevent.¶

The empty set is a valid scope and is contained in every scope; a link granting the empty scope grants no capability 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; they are not defined here.¶

8. 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 7. 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 9. 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.¶

9. Floor Axes

A floor is a set of axis/value pairs. This document defines a closed set of axes for this version of the profile. Extending the axis set beyond this closed set is no longer future work as of this revision: Section 9.1 defines a registry mechanism for it. The closed set defined directly by this document is:¶

An axis name that does not appear in this table MUST cause a verifier to reject the floor, and therefore the link that carries it, outright. An unknown or misspelled axis name MUST be treated as 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.¶

For an enum-typed axis (subjectClass, accountClass, partialPolicy), the comparison is equality only; these axes are unordered and a value either matches the required value or it does not. For a duration-typed axis (tenureMin, credentialAgeMin), a larger value is strictly tighter than a smaller one.¶

10. Action Class Floors

This section specifies the semantics of the actionClass and classSource axes registered in Section 9.1. It answers two separate questions: what is the maximum class of operation a delegation link permits (actionClass), and where a verifier is permitted to obtain a given request's class from (classSource).¶

11. Write Budget

This section specifies the semantics of the writeBudget axis registered in Section 9.1. It answers three separate questions: what value a link carries (Section 11.1); what a verifier holds as state separately from that value, and how a request is admitted against the two together (Section 11.2); and how a verifier derives the identifier that state is keyed by (Section 11.3).¶

12. Attestation Properties

This document does not mandate a specific credential format for a floor attestation. A JSON Web Token, a CBOR Object Signing and Encryption (COSE) structure, or another signed data structure MAY be used, provided the resulting object satisfies every property in this section. A conforming attestation, regardless of its encoding, MUST:¶

1. be signed by the Attestation Issuer over the exact bytes presented to the verifier. A verifier MUST verify the signature over those exact bytes and MUST NOT re-serialize the object before or in place of that verification;¶

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

3. carry an expiry. A missing expiry, or an expiry that is not a well-formed numeric timestamp, MUST be treated by the verifier as already expired; it MUST NOT be treated as "no deadline";¶

4. carry a boolean result of the floor evaluation and MUST NOT carry the underlying value that produced that result. An attestation that discloses a raw date of birth, a raw tenure count, a raw account balance, or any other unrounded attribute in place of, or in addition to, the boolean result does not conform to this profile;¶

5. be rejected by the verifier if its serialization contains a duplicate top-level key. A parser that resolves duplicate keys by a first-wins or last-wins rule is exposed to an ambiguity where the issuer and the verifier can disagree about which value was signed; this profile closes that ambiguity by requiring detection and rejection rather than a resolution rule.¶

13. 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.¶

Appendix B records that this unlinkability requirement pulls in a different direction from a stability requirement found in related work, and treats that tension as an open, unresolved item rather than as settled by this document.¶

14. 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 19).¶

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 6.¶

4. Verify each link's own signature, per Section 12, 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 8 for every adjacent pair of links in the chain.¶

7. 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.¶

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

9. Classify the request's actionClass per Section 10.3, consulting the declared menu of Section 10.4 where the chain's classSource is declared, and admit or refuse the request against the writeBudget ledger of Section 11; per Section 10.6, this step is performed by the verifier at the resource or credential boundary, not by an upstream harness or orchestration layer.¶

10. 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.¶

15. A Worked Example

This section is non-normative. It illustrates the rules of the preceding sections using a single chain that is built and then verified; where it appears to conflict with a normative section, the normative section governs.¶

Recall the scenario from Section 1: a person asks an automated agent to arrange a car rental. The parties in this example are the person, who is the root Delegator; Agent A, a general assistant; Agent B, a specialized booking agent operated by a different company; and the rental service, which is both the Relying Service and the verifier.¶

Link L(0) is the root delegation, created on the person's device:¶

Link L(1) is Agent A's re-delegation to Agent B:¶

Agent A drops payment:authorize from the scope it grants to Agent B. Dropping a capability is always permitted, because rule 1 of Section 8 requires only that the child's scope be a subset of the parent's.¶

On the wire, Agent B presents both links to the rental service as an Agent-Delegation Structured Field List:¶

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

Each member of the list is a Byte Sequence per RFC 8941 [RFC8941]. The base64 content is elided here for readability; the decoded fields are shown in the tables above.¶

The expiry values in the tables above are written in a human-readable form for readability only. The on-the-wire encoding of a link is determined by the credential format in use, as stated in Section 5, and this document does not mandate one. A link's expiry is distinct from the expiry of a floor attestation carried by the chain (Section 12), and both are distinct from the RFC 9421 expires signature parameter profiled in Section 6, which covers the HTTP message rather than the delegation.¶

The rental service verifies the chain following Section 14. For the adjacent pair (L(0), L(1)), the three attenuation rules of Section 8 are checked as follows:¶

• Rule 1, scope containment: {booking:read, booking:create} is a subset of {booking:read, booking:create, payment:authorize}. Holds.¶

• Rule 2, floor non-relaxation: subjectClass is equal on both links, so the equality axis holds. For tenureMin, P2Y is not less than P2Y, so it holds. For credentialAgeMin, P180D is 180 days and P90D is 90 days; 180 is greater than 90, so L(1) is tighter. Holds.¶

• Rule 3, expiry non-extension: 2026-11-01T11:00:00Z is earlier than 2026-11-01T12:00:00Z. Holds.¶

Every link in the chain verifies, so the chain is accepted, and the rental service applies its own authorization policy to a scope of booking:read and booking:create only. It will not honor a payment request on this chain, because no link in it carries that capability.¶

Had L(1) instead carried credentialAgeMin="P30D", that value would be looser than the parent's P90D, and rule 2 would require the verifier to reject the entire chain.¶

16. 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 8 is otherwise satisfied.¶

The agent identifier requirement in Section 13 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.¶

Because the Agent-Delegation field is visible to any intermediary able to read HTTP headers, and this document defines no confidentiality mechanism for it, links in the chain MUST NOT carry personal data belonging to the Delegator, any intermediate Delegate, or any subject the floor condition concerns.¶

17. Relationship to Existing Work

The OAuth Working Group charter [OAUTH-CHARTER], as updated 2026-06-04, includes the following work item, quoted in full: "Developing new mechanisms or/and extensions 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 addresses cross-administrative-domain agent authorization with an attenuation mechanism a verifier can check at every hop.¶

[I-D.klrc-aiagent-auth], submitted 6 July 2026 and expiring 7 January 2027 (version -03 is the latest published version; this document was current as of 2026-08-28), is an individual submission and has not been adopted by the Working Group. 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 composes with that draft at both points: the attenuated chain this document specifies can carry, at any link, a floor attestation produced by a provisioning and posture stack of the kind that draft describes, and this document's chain can be presented alongside, or as an input to, the grant type that draft defines. This document does not compete with or attempt to replace [I-D.klrc-aiagent-auth]; it fills two extension points that draft leaves open.¶

[I-D.klrc-aiagent-auth]'s Section 11 states that a participant MAY subscribe to change notifications using mechanisms such as the OpenID Shared Signals Framework; it does not require such a subscription. This document specifies no revocation-notification mechanism at all and instead relies on short-lived expiry, per Section 12 and Section 19. Both documents are, in this sense, revocation-light: one permits an optional richer revocation path that this document does not require or preclude, and this document specifies none. Neither position is presented here as superior to the other.¶

[I-D.klrc-aiagent-auth]'s Section 6 wants an identifier that remains stable for the lifetime of a workload identity, to support audit. This document's Section 13 wants an identifier unlinkable across Relying Services. These two goals pull in opposite directions, and this document does not resolve that tension; see Appendix B.¶

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 attempt a detailed comparison against each; it notes their existence as evidence of active, converging interest in attenuated agent delegation across administrative domains, a problem this document addresses from the OAuth Working Group side.¶

[I-D.asor-wimse-agent-delegation-chain] Section 10 requests a new "Agent Delegation Constraint Types" registry, with initial entries max, one_of, not_one_of, prefix, and rank, and its Section 4.1 requires a verifier that encounters an unknown constraint type to deny the action, never to treat it as unconstrained. That draft's registry, as posted, has no entry named min: every constraint that draft's Section 4.2 subsumption rules define narrows a ceiling (child.max <= parent.max, child.one_of a subset of parent.one_of, child.rank <= parent.rank), where this document's duration-typed axes are all floors tightened upward instead. That draft's registry names comparator TYPES and leaves the constrained quantity to a profile-level naming agreement; the registry defined in Section 9.1 takes the complementary approach of naming axes, each bound to one comparator from a closed set. The comparator vocabulary is therefore the bridge between the two registries, not a shared set of names: rank in that draft's registry and the rank comparator of Section 9.1 are the same comparator, and actionClass in this document's registry uses it. A mirrored min comparator, matching this document's min, has been stated as intended for a future revision of that draft; it is not present in [I-D.asor-wimse-agent-delegation-chain] as posted, and this document does not describe it as present.¶

A companion document, [CAMARA-PROPOSAL], is an open, unreviewed API proposal filed to a separate standards body's API backlog; it has not been reviewed, accepted, or adopted by that body. It proposes the operator/attestation side of the same overall design, on the premise that an Attestation Issuer of the kind this document treats abstractly can, in one concrete instantiation, be a telecommunications operator. The two documents meet only at the RFC 9421 header defined in Section 5; neither depends on the other's approval, and this document remains fully specified without the companion proposal existing at all.¶

18. Implementation Status

This section records the status of a known implementation of this profile, in accordance with [RFC7942]. The information provided is believed to be accurate at the time of writing, has not been independently verified, and does not constitute an endorsement of this profile by any party. The provided implementation is a single-author, open-source proof-of-concept, written in zero-dependency Node.js and available at https://github.com/hamr0/justabit. It has not undergone external review and has not been adopted by any organization; no Attestation Issuer has reviewed or validated this profile.¶

The following elements of this profile are implemented and exercised by automated tests in that proof-of-concept:¶

• the attestation object and exact-bytes Ed25519 signature verification described in Section 12;¶
• duplicate-top-level-key rejection;¶
• nonce binding, as distinct from replay protection;¶
• expiry enforcement, including the missing/non-numeric-expiry-is-expired rule;¶
• the signed-refusal shape of Section 12.1 and its independent verification path;¶
• the closed floor axis set of Section 9, the duration grammar of Section 9.2, and the monotone tightening comparison of Section 9.3;¶
• the actionClass and classSource classification and admission rules of Section 10, exercised by 27 automated cases in the proof-of-concept: the classification procedure; the deterministic path-template rule for matching menu operation keys, per Section 10.4; and the binding of a menu's issuer to the request's target origin that Section 10.4 requires.¶
• the writeBudget ledger of Section 11: reserve-then-decrement admission against a stateful, per-chain count, and an actionClass r request never spending against it. This shares the same proof-of-concept and the same case count as the previous bullet, and includes the chain identifier derived by the verifier as the SHA-256 digest of L(0)'s signature value, per Section 11.3, rather than taken from a caller-supplied request field.¶

The following elements of this profile are NOT implemented in the proof-of-concept, and this is stated here without qualification:¶

• RFC 9421 HTTP Message Signature presentment is not implemented; the proof-of-concept has no HTTP transport layer between the parties at all;¶
• the multi-hop delegation chain of Section 8 is not implemented; the proof-of-concept exercises only a two-party exchange between one Delegator and one Attestation Issuer;¶
• the per-Relying-Service unlinkable agent identifier of Section 13 is not implemented.¶

The catalogue survey behind the honest-limit paragraph of Section 10.7 is included in this same repository, alongside its underlying data.¶

19. Security Considerations

Lazy verification is the primary risk this profile is designed against. A verifier that checks only the final link of a delegation chain, rather than every link per Section 14, defeats the entire mechanism: an intermediate Delegate can present a leaf link that is internally well-formed while the chain that produced it silently widened scope, loosened a floor, or extended an expiry at an earlier hop. Conformance to this profile requires whole-chain verification; there is no partial-conformance mode that checks only the leaf.¶

Nonce echo does not prevent replay. As stated in Section 12.2, a verifier that treats nonce presence as sufficient replay protection can be presented with the same attestation more than once within its expiry window. A conforming deployment needs its own replay defense, such as tracking consumed nonces within their validity window; this document does not supply that defense.¶

Cost-based floors price resets; they do not create uniqueness. A floor expressed in terms of tenure or credential age raises the cost of obtaining a fresh credential that satisfies it, but it does not establish that the underlying subscription or account is held by a unique human, or that one subject cannot back multiple agents. A deployment that needs a uniqueness guarantee needs a mechanism this profile does not provide.¶

This profile defines no revocation mechanism. Once an attestation or a delegation link is issued, this profile provides no way to invalidate it before its stated expiry. The only mitigation this profile offers is short expiry; a deployment's exposure window is bounded by how short its issuers set expiries, not by any revocation capability.¶

Key distribution is a centralization point. Verification of the root attestation depends on a trust source that resolves an Attestation Issuer's public key, per step 5 of Section 14. That trust source is, by construction, a point every verifier in a deployment must trust and a point whose compromise or unavailability affects every verification that depends on it.¶

Rejection MUST be uniform. As stated in Section 14, a verifier MUST NOT return different, distinguishable outcomes for different verification failures (an expired link versus a bad signature versus a loosened floor versus a depth overflow). A verifier that leaks which step failed hands an unauthenticated party an oracle it can use to probe the boundaries of a valid chain without ever constructing one.¶

An Attestation Issuer's query log is a residual disclosure channel even though the verifier learns only a boolean. This is restated here as a security consideration, not only a privacy one, because a party able to observe or compel disclosure of that query log gains information the wire protocol itself was designed to withhold.¶

An unforgeable chain identifier is what makes a write budget a cap rather than a suggestion. The derivation of Section 11.3, from L(0)'s own signature rather than from any value the request supplies, is what prevents the presenter of a chain from choosing its own identifier and thereby choosing its own remaining count. A verifier that accepts a presenter-supplied chain identifier converts the hard cap of Section 11 into something the presenter can reset at will, simply by supplying a different value on the next request; Appendix C's V11 exists to catch exactly that failure. Per-verifier counting, by contrast, per Section 11.4, is a stated limitation of this document, not a defect to be concealed: a deployment that needs a single shared count across verifiers needs a mechanism this document does not supply.¶

A declared menu is an owner-signed downgrade surface. classSource declared lets the Resource Owner's menu lower a request's actionClass below its method default, for example declaring a POST as r. The origin-binding rule and the out-of-band key requirement of Section 10.4 are what keep a third party from supplying that downgrade for a resource it does not own: without both checks, a verifier that resolves one key for more than one Resource Owner could be handed a validly-signed menu for the wrong resource and apply its declared classes to a request it was never meant to cover. A verifier that accepts a menu without checking both the signature and the origin match does not conform to this document.¶

20. IANA Considerations

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

This document requests IANA create the "HAMR Floor Axis Registry", referenced from Section 9.1. Registration policy for this registry is Specification Required [RFC8126]. The registration template is the five fields defined in Section 9.1: Name, Comparator, Value Domain, Tightening Direction, and Omitted-Axis Rule. The Comparator field of a registration MUST be exactly one of min, max, rank, or one_of; a registration naming any other comparator is not valid. The initial contents of the registry are the eight entries given in the table in Section 9.1: subjectClass, tenureMin, credentialAgeMin, accountClass, partialPolicy, actionClass, classSource, and writeBudget.¶

No other IANA actions are required by this document.¶

Appendix A. Non-Normative Instantiations

This appendix is entirely non-normative. It describes concrete ways to satisfy the abstract requirements of the body of this document, to help a reader evaluate the profile's deployability. Nothing in this appendix constrains a conforming implementation; a deployment satisfying the normative sections above by any other means is equally conforming.¶

Three directions are sketched below. They differ in what makes the underlying credential scarce; none is required, preferred, or assumed by this profile.¶

Direction 1: subscription attestation. A mobile network operator can act as the Attestation Issuer described in Section 12. In such an instantiation, a subscriber identity module credential grounds the Delegator's identity, and the operator attests floor conditions about the line associated with that credential without disclosing the line's underlying attributes. The floor axes named abstractly in Section 9 map, in this instantiation, to concrete network-observable attributes as follows: subjectClass maps to the line's service type (for example, voice-and-data versus machine-to-machine); tenureMin maps to the line's subscription tenure; credentialAgeMin maps to the elapsed time since the credential (for example, the SIM) was last swapped; accountClass maps to a billing relationship category (for example, postpaid versus prepaid); partialPolicy maps to how the operator's attestation service handles a query for which it holds incomplete data. This direction's scarcity is economic: obtaining many qualifying credentials costs money over time. Economic cost does not establish uniqueness. A companion document, [CAMARA-PROPOSAL], is an open, unreviewed API proposal that proposes a horizontal profile to a telecommunications standards body along these lines, independently of this document and without either document depending on the other's adoption; nothing about it has been approved, accepted, endorsed, reviewed, or adopted.¶

Direction 2: a government-issued document credential proved in zero knowledge. A credential in the ISO/IEC 18013-5 [ISO18013-5] mobile document (mdoc) format, held in a wallet, can be used to prove a predicate over the credential in zero knowledge, rather than to disclose the credential's contents. The verifier learns one bit and learns nothing else, and separate presentations are unlinkable. This direction's scarcity is cryptographic: it is rooted in a document issued by a government authority rather than in a purchasable subscription. Work on this class of scheme is in progress in the IETF; see [I-D.google-cfrg-libzk]. This appendix does not state that any particular implementation of this direction exists or has been demonstrated.¶

Direction 3: a document chip signature with accompanying evidence. A holder's device can read the signature on a government-issued document's chip and verify it against the issuing authority's public-key infrastructure, a process known as passive authentication and specified in ICAO Doc 9303 [ICAO9303]. This establishes that the document is genuine and unaltered. On its own, the chip-signature check says nothing about who presented the document or about the software that performed the read, so deployments of this class pair it with additional evidence, and what that evidence is varies: an attestation from the device platform that unmodified software performed the read; a signature from a party the verifier trusts, vouching for the value reported; a zero-knowledge proof of the predicate itself; or no accompanying evidence at all.¶

The trust model differs by evidence type, and it matters which one a deployment picks. Where the accompanying evidence is an attestation, the verifier does not check a proof; it checks that trustworthy code ran, and then relies on the value that code reported, so breaking the attestation collapses the claim. Where the accompanying evidence is a zero-knowledge proof, the verifier checks the proof itself, and breaking a platform attestation buys an attacker nothing, because the mathematics still has to hold. Where there is no accompanying evidence, the claim rests on the chip signature alone. A deployment describing this direction needs to state which evidence it uses, because the strength of the claim is not a property of the document root. One limit does not change regardless of which evidence is paired with it: passive authentication proves the document is genuine and unaltered; it does NOT bind the presenter to the document. This direction therefore bounds the number of identities a holder can obtain to the number of documents held; it does NOT establish one identity per human, and must not be described as doing so.¶

All three directions satisfy the same abstract Attestation Issuer role defined in the body of this document; they differ in what makes a credential scarce. A deployment may use any of them, or another mechanism entirely. This profile does not require, prefer, or depend on any of them.¶

Direction 4: harness-side experience. These are three open-source, single-author experiments, available at https://github.com/hamr0/bareguard, https://github.com/hamr0/bareloop, and https://github.com/hamr0/bareagent, that exercise the boundary drawn in Section 4; they are not implementations of this profile, which is why they are not listed in Section 18. Non-normative, like the rest of this appendix.¶

bareguard is one chokepoint between an agent and the world: every action passes through a single gate and comes back allow, deny, or ask a human.¶

• a floor gate decides before the action runs, plus a separate detector after the result that annotates and never blocks alone; the split maps onto layers (a) and (c) of Section 4;¶
• capability presets may only narrow the floor, never widen it, so a wrong preset is not a safety hole;¶
• quantitative limits are enforced as a running cumulative total, because a per-action cap is defeated by splitting one action into many; only two comparator kinds were needed in practice, set membership and an ordered-enum threshold.¶

bareloop has an agent author its own workflow scaffolding as a constrained, validated config, with every run executing under an outer gate the agent cannot reach or argue with.¶

• the agent authors its workflow and never its arbiter; closes, budgets, and caps live outside the authored part;¶
• a predicate decides a pass, a judge never renders the verdict, and a judged verdict class needs a pre-scored calibration set before it may gate anything;¶
• an omitted cap reads as an explicit choice, never a silent default, because a defaulted cap is an unadvertised second ceiling.¶

bareagent is the think, act, observe loop: a goal goes in and coordinated actions come out.¶

• a policy chokepoint inside the loop forwards every action to an external gate that decides and never runs it;¶
• a lock on a check's code does not protect the check's semantics; a stateful function defeated an unsatisfiable check across repeated invocations;¶
• an incomplete result is returned honestly rather than as a faked pass.¶

In each case the point of control sat at the credential boundary or the resource, never in the harness, which is the placement Section 4 assumes.¶

Appendix B. Open Reconciliation Item: Identifier Stability Versus Unlinkability

This appendix records an unresolved tension rather than a solution. [I-D.klrc-aiagent-auth]'s Section 6 wants an agent identifier that is stable for the lifetime of a workload identity, so that audit records can be correlated over time. This document's Section 13 wants an identifier that is unlinkable across distinct Relying Services, so that no two Relying Services can correlate requests from the same underlying agent by identifier alone.¶

These two properties are in tension: an identifier stable enough to support long-lived audit correlation at one Relying Service is, by that same stability, a stronger correlation handle if it is reused, or is derivable in a reused form, across Relying Services. A per-Relying-Service unlinkable identifier, taken to its logical conclusion, complicates the kind of long-lived, cross-request audit trail Section 6 of that draft wants.¶

This document does not resolve this tension. It is recorded here as an open item for the Working Group's consideration, not presented as solved by either document.¶

Appendix C. Test Vectors

This appendix is non-normative. The vectors below are an aid to implementers checking their own understanding of the attenuation rules in Section 8 against a common set of examples; they are not an additional requirement, and they do not modify or extend the normative requirements stated in the body of this document. Where a vector appears to conflict with a normative section, the normative section governs.¶

Each vector is a delegation chain: an ordered sequence of links, each carrying a scope (Section 7), a floor, and an expiry, together with the outcome a conforming verifier is expected to reach and, where that outcome is rejection, which rule of Section 8 the chain violates. An implementation checking itself against this appendix is expected to reproduce every expected outcome listed below, using the scope and floor values shown.¶

In every vector, subjectClass is interactive on every link, and accountClass and partialPolicy are not exercised and are omitted from every link; a floor is a set of axis/value pairs and is not required to name every axis in Section 9. Only scope, tenureMin, credentialAgeMin, and expiry vary below, and those are what the tables show.¶

The floor and expiry for the same links follow.¶

V4 is a distinct and easily missed failure mode from V3: a floor can be relaxed either by widening a value already present on an axis, as in V3, or by dropping the axis from the link entirely, as in V4. Rule 2 in Section 8 treats both as the same violation, and an implementation that checks only for a looser value on an axis both links carry, without also checking for an axis the parent link carried and the child link dropped, does not detect V4.¶

V6 is the negative control. The violation is not at the leaf link: the pair (L(1), L(2)) attenuates correctly by every rule, and only the interior pair (L(0), L(1)) violates rule 1. A verifier that checks only the final link, or only the pair adjacent to the leaf, accepts this chain; such a verifier does not conform to Section 14, which requires every adjacent pair in the chain to be checked. This vector exists specifically to detect that failure.¶

Vectors V7 through V9 below extend this appendix to the actionClass and classSource axes of Section 10. In all three, subjectClass is interactive, and scope, tenureMin, and credentialAgeMin are omitted and not exercised, following the same convention stated above for V1 through V6. V7 is a two-link delegation chain, checked the same way as V1 through V6. V8 and V9 each involve a single link and one incoming request, together with, where noted, one menu; they exercise Section 10.3 and Section 10.4 rather than the three attenuation rules, so no parent link is shown for them.¶

V8 and V9 each present a request "POST /check" against a link whose actionClass is r. Both are accompanied by a menu, signed by the Resource Owner's key, declaring "POST /check" as r. In V8 the menu's iss value is the origin of the request target, https://api.example.com, matching it exactly. In V9 the menu carries the same declared entry and the same valid signature, but its iss value is https://attacker.example.com, an origin different from the request target.¶

V9 is the negative control for the origin-binding rule of Section 10.4. A verifier that checks the menu's signature but skips the comparison between iss and the request target's origin reaches the same outcome as V8 - it accepts the declared value r - and so admits a request that a verifier applying the origin-binding rule correctly refuses. The two vectors present an identical menu and an identical requested actionClass floor and differ only in the menu's iss value, so any difference in outcome between an implementation and this table is attributable to that one comparison.¶

More generally, a suite composed only of chains expected to be accepted cannot distinguish a verifier that correctly implements the rules of Section 8 from one that accepts every chain unconditionally; both pass such a suite identically. At least one vector expected to be rejected is therefore required for a suite to have any diagnostic value at all, and V6 in particular is required to detect a verifier that checks only the leaf of the chain.¶

Vectors V10 and V11 below extend this appendix to the writeBudget axis of Section 11. Both present the same single-link chain, L(0) with actionClass x and writeBudget 2, against a series of x-class requests; the chain identifier is whatever Section 11.3 derives from L(0)'s signature, and is the same value across every request in both vectors, since both present the same L(0).¶

V10 is the positive case: two successive x-class requests against the chain are admitted, dropping the remaining count from 2 to 1 to 0, and a third is refused because the remaining count is already 0, per the admission rule of Section 11.2.¶

V11 is the negative control. It re-presents the identical chain used in V10, after its budget is already exhausted, but the fourth request carries a different chain identifier value of the caller's own choosing rather than one the verifier derived from L(0). Because Section 11.3 requires the verifier to derive the chain identifier itself and forbids taking one from the request, the count is not refilled and step 4 is refused on the same exhausted count as step 3. A verifier that instead took the chain identifier from the request would treat the fourth request as belonging to a fresh chain with a full budget of 2, and would wrongly admit it; V11 exists specifically to detect that failure.¶

These vectors are illustrative and not exhaustive. Passing them does not establish conformance to this document as a whole: V1 through V6 cover the three attenuation rules of Section 8, V7 through V9 cover the actionClass tightening rule, the declared-value substitution rule, and the menu origin-binding rule of Section 10, and V10 through V11 cover the writeBudget admission rule and the chain-identifier-derivation rule of Section 11; together they do not exercise signature verification of a delegation link itself, nonce binding, expiry evaluation against wall-clock time, or the header field encoding described in Section 5 and Section 6. These vectors have not been executed against any implementation by anyone, including the author; they were derived by hand from the rules in Section 8, Section 10, and Section 11.¶

Appendix D. Changes since -00

This section is non-normative and is expected to be removed before this document leaves individual submission status.¶

• Added the Floor Axis Registry (Section 9.1): axis names are now extensible through an IANA registry, Specification Required, rather than fixed to the closed set this document defines directly. Each registered name is bound to exactly one comparator from a closed set of four (min, max, rank, one_of); an unregistered axis name or an unregistered comparator is a hard rejection, extending the -00 rule that already applied to axis names alone. Eight initial entries are registered: the five axes Section 9 already defines (subjectClass, tenureMin, credentialAgeMin, accountClass, partialPolicy) are now registered with explicit comparators (one_of for the three enum axes, treating -00's equality-only rule as a singleton set; min for the two duration axes); and three new names, actionClass, classSource, and writeBudget, are registered with their comparators, but their full semantics are reserved for a later item of this revision and are not yet specified. Added the corresponding IANA Considerations request (Section 20) and a paragraph in Section 17 comparing this registry's approach against the constraint-type registry of [I-D.asor-wimse-agent-delegation-chain].¶

• Added Section 4, a new, purely informational section placed after Section 3 and before Section 5. It positions this document among three delegation layers (who may act, what exactly may be done per invocation, and what happened once), states that this document occupies layer (a) plus floors, and distinguishes it from [RFC9396] (grant-time binding), [I-D.das-agentic-tool-binding] (per-call tool-name-and-argument binding), and [I-D.schrock-ep-authorization-receipts] (layer (c) receipts). It also names, non-normatively, the shared structural problem that a parent credential remains valid after attenuation, citing [I-D.asor-wimse-agent-delegation-chain] Section 9.1 for mitigations this document does not itself supply.¶

• Added Direction 4 to Appendix A: three single-author, open-source harness experiments (bareguard, bareloop, bareagent) that exercise the boundary drawn in Section 4 without implementing this profile, and are therefore not listed in Section 18.¶

• Added Section 10, a new normative section placed after Section 9, specifying the actionClass and classSource axes reserved but not yet specified by the Floor Axis Registry addition above: the actionClass values r, w, and x and their rank tightening rule; the classSource values method and declared, ranked method < declared with method the tighter, default value, and the rule that a child link moves only from declared to method; the classification procedure (HTTP-method default per [RFC9110], or a verified, resource-bound menu when classSource is declared, falling back to the method default on any menu failure and never combining the two); the declared menu itself, a JWS ([RFC7515]) whose payload names the resource's origin ([RFC6454]) and a map from operation key to actionClass value, including a deterministic path-template matching rule and an origin-binding requirement on the menu's issuer; verifier placement at the resource or credential boundary; and an honest-limits paragraph, backed by a committed catalogue survey, that a POST is not always classed correctly by method alone. Added a corresponding paragraph to Section 19, three test vectors (V7 through V9, the last a negative control for the origin-binding rule) to Appendix C, and a bullet to Section 18 recording the proof-of-concept's case count against this section's requirements. Replaced the two Floor Axis Registry table cells that deferred actionClass's and classSource's semantics, and the standalone marker comment for this item, with a cross-reference to the new section.¶

• Added Section 11, a new normative section placed after Section 10, specifying the writeBudget axis reserved but not yet specified by the Floor Axis Registry addition above: the axis as a non-negative, max-comparator, cumulative-per-chain integer with an omitted-axis floor of zero; the distinction between the limit carried in the chain and the count a verifier holds as its own state, keyed by a chain identifier and never carried in a link, with reserve-then-decrement admission and an actionClass r request never spending; and the chain identifier itself, derived by the verifier as the SHA-256 digest of the root link L(0)'s signature value, never taken from the request, which resolves case 22 of the proof-of-concept. Added a corresponding paragraph to Section 19, two test vectors (V10, a positive three-request sequence, and V11, a negative control re-using an exhausted chain under a caller-supplied identifier) to Appendix C, and a bullet to Section 18 recording that the proof-of-concept now derives the chain identifier as this section requires. Replaced the writeBudget row's deferred-semantics note in Section 9.1's table, and the standalone marker comment for this item, with a cross-reference to the new section, and rewrote the paragraph after that table so it no longer describes writeBudget's semantics as unspecified.¶

• Updated three sections that already existed in -00. Added a Resource Owner entry to the Conventions and Terminology list (Section 2), and a clause to the Floor definition in that same list making explicit that a floor is the aggregate of its per-axis constraints, at most one per axis. Added a step to the ordered Verification Procedure (Section 14) placing actionClass classification, declared-menu consultation, and writeBudget admission after chain and attenuation validation and before the Relying Service's authorization-policy step. Restated the Floor Axis Registry's Omitted-axis rule (Section 9.1) as two distinct cases, link-to-link omission of an axis the parent constrained (a rejection per rule 2 of Section 8) and link-to-published-floor inheritance where no link in the chain constrains the axis, replacing an earlier statement that conflated the two.¶

Author's Address