Credential Delegation Protocol for AI Agents in Multi-System Environments

1.1. Problem Statement

OAuth 2.0 [RFC6749] solved human-to-service authorization. When a user authorizes an application to act on their behalf, the application receives an access token representing that delegation. This model assumes a human present at a browser for the consent ceremony.¶

AI agents operate autonomously. They are ephemeral (spawned on demand), numerous (many agents per user per service), and adversarially promptable: a compromised prompt can direct an agent to misuse any credential it holds. Existing standards fail the agent delegation use case in seven specific ways:¶

1. No agent identity primitive. OAuth clients require pre-registration. Agents are ephemeral and cannot register at instantiation time. SPIFFE requires admin provisioning. No standard defines bootstrapping an agent identity from nothing.¶

2. No delegation chain attenuation. When Agent A sub-delegates to Agent B, existing standards do not enforce that authority can only narrow. RFC 8693 records delegation chains via nested act claims but treats them as "informational only": no enforcement, no structural guarantee. The delegation chain splicing vulnerability (disclosed to the OAuth WG mailing list, February 26, 2026 [OAUTH-SPLICING]) demonstrates that Sections 2.1-2.2 of [RFC8693] permit a compromised intermediary to present mismatched subject_token and actor_token from different delegation contexts, producing a properly-signed token asserting a delegation chain that never occurred.¶

3. No credential wrapping. Agents need to use credentials at resource servers that do not understand delegation. No standard defines how a delegation token authorizes credential exercise without exposing the raw credential to the agent.¶

4. No granular authorization. OAuth scopes are coarse string identifiers. Agents need resource- and operation-level capability binding: not "can access Google Drive" but "can read file X in folder Y until time T." RFC 9396 provides the structural mechanism but no agent-specific vocabulary or attenuation rules.¶

5. No synchronous revocation cascade. Revoking a root delegation must immediately invalidate all derived delegations. UCAN revocation is gossip-based. RFC 8693 explicitly defers revocation to implementations. No existing standard provides sub-second cascading revocation for a delegation tree.¶

6. No asynchronous consent. Agent-initiated flows require user approval without a redirect URI. CIBA [OIDC-CIBA] provides the mechanism but is not profiled for agent delegation scenarios, and CIBA + DPoP interaction is underspecified.¶

7. No delegation audit chain. No standard defines an immutable, portable audit trail for "Agent A used User B's credential C to perform operation D at time T via delegation chain E."¶

This document profiles existing standards to address all seven gaps.¶

1.2. Relationship to Existing Work

The IETF landscape for agent authorization moved quickly during 2026. The OAuth Working Group was rechartered in June 2026 with agents acting on behalf of users explicitly in scope. The WIMSE Working Group held an interim meeting on June 3, 2026 dedicated to AI agent authentication and authorization and has since adopted that work as AIMS. Several dozen individual drafts now address some slice of agent identity or delegation. This section positions this protocol against the working group documents and the individual drafts closest to its mechanics. It is not a survey.¶

1.3. Design Principles

Compose, don't invent. Every mechanism reuses an existing standard. New concepts appear only where the gaps identified in Section 1.1 are confirmed.¶

Attenuation is structural. Agents cannot widen authority at any delegation hop. This is enforced by the Delegation Server, not by trusting agents. Inspired by UCAN attenuation semantics and the object-capability model [MILLER-2006].¶

Credentials are never possessed. Agents receive and exercise delegated authority through the Delegation Server. Raw credentials never cross the boundary to the agent host: the underlying credential is never delivered to the Agent, so an Agent turned into a confused deputy [CONFUSED-DEPUTY] cannot leak it. This does not protect the credential at the DS itself (Section 10.9).¶

Revocation is synchronous. A user revoking delegation takes effect within the SLA defined in Section 7. Eventual consistency is not acceptable for credential revocation in adversarially-promptable systems.¶

Capability-shaped, not identity-scoped. Delegation tokens authorize specific operations on specific resources with specific constraints, not "Agent X can access Service Y." Follows the NORA (designation = authority) principle from capability security.¶

Chain integrity is cryptographic. Each delegation hop produces a signed receipt. The chain is verifiable end-to-end without trusting intermediate agents, addressing the RFC 8693 delegation chain splicing vulnerability.¶

3.1. Protocol Version Negotiation

The canonical protocol version for this draft is 0.1.0.¶

HTTP protocol clients MUST advertise the highest Cred Protocol version they support for a request using the Cred-Protocol-Version request header. The header value MUST be a single semantic-version string in MAJOR.MINOR.PATCH form. Delegation Servers MUST set Cred-Protocol-Version on every protocol response, including error responses, to the version selected by the server for that response.¶

Each implementation MUST maintain:¶

• a supported-version set, ordered from newest to oldest¶

• a configured version floor, below which requests are rejected¶

For this draft, the supported-version set is ["0.1.0"] and the default version floor is 0.1.0.¶

A Delegation Server MUST reject a request that advertises a version lower than the configured floor or a version outside the supported-version set. The server MUST return HTTP 426 with a JSON body containing:¶

{
  "error": "protocol_version_unsupported",
  "message": "Cred Protocol version 0.0.9 is not supported",
  "requested_version": "0.0.9",
  "supported_versions": ["0.1.0"],
  "minimum_version": "0.1.0",
  "current_version": "0.1.0"
}

The response MUST also include Cred-Protocol-Version set to the server's current version so clients can distinguish protocol drift from authentication, authorization, or policy failures.¶

During the 0.1.0 compatibility window, a missing Cred-Protocol-Version request header MAY be treated as 0.1.0. This allowance exists only because there is no earlier wire version to downgrade to. Implementations that raise the version floor above 0.1.0 MUST reject missing protocol-version headers with protocol_version_unsupported.¶

4.1. Ephemeral Key Pairs

An Agent MUST generate a key pair at instantiation for a signature algorithm the DS accepts. A DS MUST accept Ed25519 and P-256 and MAY accept ML-DSA [FIPS204] where a did:key encoding for it is available to both parties. The DID is derived deterministically from the public key using the did:key method [DID-KEY], a DID method conforming to [DID-CORE]. No pre-registration is required. The DS MUST NOT reject a DID it has not seen before.¶

Every verifier in this protocol, including the DS when it re-verifies a parent chain (Section 5.4), MUST hold a local list of accepted signature algorithms and MUST reject an assertion, Delegation Token, or receipt signed with an algorithm not on that list, as in step 1 of Section 6 of [ASOR]. The alg header of the object under verification never selects the algorithm by itself.¶

4.2. Agent Authentication

The Agent authenticates to the DS using a JWT Bearer assertion [RFC7523] signed with the private key corresponding to its did:key. Required claims:¶

Optional claims:¶

4.3. Agent Lifecycle

Agents SHOULD generate a new key pair per session. The DS MAY require Subject pre-authorization of specific agent DIDs or agent operators before issuing Delegation Tokens. When an agent terminates, the DS SHOULD invalidate any active Delegation Tokens bound to that agent's DPoP key within the revocation SLA.¶

4.4. Workload Authorization Grant Composition

Workload Authorization Grant [WAG] supplies the provisioning layer: a platform-signed RFC 7523 grant identifies a workload to an authorization server that trusts the platform. Its on-behalf-of delegation composition slot is addressed by this document's subject consent, capability attenuation, and signed delegation receipts; WAG does not supply those properties itself.¶

A WAG assertion is presented to an authorization server's token endpoint, not to the DS. A WAG-provisioned workload therefore authenticates to the DS as any other Agent, per Section 4.2, and act.sub in its Delegation Tokens remains the Agent DID. The WAG Agent Identifier is source identity evidence about that Agent, not a replacement for its DID. When a deployment links the two, the DS records in the delegation receipt (Section 5.4) the WAG assertion's issuer, the Agent Identifier, and, where several Platforms share one issuer identifier, the registration-distinguishing claim name and value described in Section 6.3 of draft-carleton-workload-authz-grant-01. Section 6.1 of that draft requires sub and jti to be interpreted only within the matched Platform registration, so the DS MUST NOT equate bare Agent Identifiers from different registrations, and a downstream verifier MUST have a trusted mapping from the recorded issuer and registration context to the actor identity; a platform-local identifier is not globally resolvable. The WAG identity travels only as this receipt evidence. It MUST NOT be carried inside act: act.sub names the Agent DID, and a platform-scoped identifier there would contradict client_id (Section 5) and depend on a mapping the verifier may not hold.¶

The WAG assertion is a bearer credential, and WAG leaves proof of possession open (Section 8 of that draft). The DS MUST NOT treat WAG-asserted identity as proof that the presenting party controls the workload's key; sender constraint comes from the Delegation Token's DPoP binding (Section 4.2). WAG actor identity MUST NOT be treated as user consent or as permission to re-delegate.¶

5.1. Required Claims

client_id and act.sub name the same current actor. client_id follows the adopted AIMS Section 10.3 convention (acting agent in client_id, delegating principal in sub); act adds the RFC 8693 history trail so a verifier can tell the current actor from prior actors without a second claim set. The two MUST agree; a token in which they differ is malformed.¶

client_id keeps the meaning [RFC9068] Section 2.2 takes from [RFC8693] Section 4.3: the client that requested the token. The DS therefore issues a Delegation Token only to the agent it names. For a child token the receiving agent is the requester (Section 5.4.1), so the authenticated requester, client_id, and act.sub are one party at every hop.¶

5.2. Capability Structure

Capabilities are expressed as RFC 9396 authorization_details objects:¶

{
  "type": "cred_delegation",
  "provider": "google",
  "operations": ["drive.files.get", "drive.files.list"],
  "resources": ["folder:abc123"],
  "expires": "2026-07-28T22:00:00Z"
}

The DS MUST validate that capabilities in a sub-delegation request are a subset of the parent DT's capabilities, equal or narrower, never wider. Validation is the DS's responsibility, not the requesting agent's.¶

Numeric and enumerated bounds on how a capability may be exercised are not part of the capability object. They are carried in the token's delegation_constraints claim (Section 5.3) so that a verifier holding only the chain can check that they narrow hop by hop.¶

5.3. Constraint Ceilings

A Delegation Token MAY carry a delegation_constraints claim: an array of objects, each with a REQUIRED key naming the constrained dimension and exactly one typed constraint value. The shape and the type vocabulary are those of Section 4.2 of [ASOR], so that a Cred receipt chain and an Asor Delegation Chain can be checked by the same subsumption code:¶

• max (number): the quantity MUST NOT exceed it.¶

• min (number): the quantity MUST NOT be less than it.¶

• one_of (array): the value MUST be a member.¶

• not_one_of (array): the value MUST NOT be a member.¶

• prefix (string): the value MUST have it as a prefix.¶

• rank (number or label): position in an ordered enumeration; the value's rank MUST NOT exceed the constraint's. A label-valued rank carries its enumeration in an order member, least to most permissive, as in [ASOR] Section 4.2.¶

• max_lifetime (number): the sum of the quantity over every exercise under the token MUST NOT exceed it.¶

• max_subtree (number): the sum of the quantity over every exercise under the token and its descendants MUST NOT exceed it.¶

"delegation_constraints": [
  { "key": "max_rows", "max": 5000 },
  { "key": "region", "one_of": ["us", "eu"] },
  { "key": "egress", "rank": "none",
    "order": ["none", "internal", "any"] }
]

Parsing is fail-closed. A constraint object is closed: its members are key, one type member, and any member that type defines (order for rank). An entry with no type member, more than one, any other member, a malformed value, or a (key, type) pair repeated within the array makes the whole claim malformed, and a token with a malformed delegation_constraints claim is invalid before any subsumption is evaluated. A constraint of a type the DS does not implement is not malformed for that reason alone; it is carried, and it is never treated as absent. A verifier that encounters an unknown constraint type MUST treat the action as denied (fail closed), never as unconstrained, as in Section 4.2 of [ASOR].¶

Subsumption follows Section 4.3 of [ASOR]: for every constraint in the parent, the child MUST carry a constraint under the same key and the same type whose admissible set is a subset of the parent's (max no greater, min no smaller, one_of a subset, not_one_of a superset, prefix extending the parent's prefix, rank no higher). A constraint present in the parent and absent from the child means the child is unbounded on that dimension, which is wider, and the DS MUST refuse to issue the child. The child MAY add constraints the parent does not carry. When a sub-delegation request omits delegation_constraints, the DS inherits the parent's ceilings into the child unchanged.¶

A DS or verifier that does not implement the type of a constraint present in the parent cannot evaluate subsumption for it. It MUST treat the child as not subsumed unless the child carries a constraint with the same key and type whose JCS serialization [RFC8785] is byte-identical to the parent's, and even then any exercise under that constraint is denied, as at step 8 of Section 6 of [ASOR] (outcome unknown_constraint in Table 2 of that draft).¶

Two constraints with the same key and different types, such as a min and a max forming a range, are evaluated independently. A label-valued rank without order, or whose label is not a member of order, is malformed. A child's order MUST be identical to its parent's for the same key; a verifier reads the ordering from the token and needs no registry entry per key.¶

max, min, one_of, not_one_of, prefix, and rank bound each exercise and are checked offline by any holder of the chain. max is per exercise only; a producer MUST NOT express a cumulative bound with it. The type, not the key, states whether a bound is per exercise or cumulative: a verifier gives a key name no meaning, so it cannot detect a max that its producer meant as a running total. A max on a quantity that exists only as a running count, such as a count of calls, bounds nothing, since each exercise contributes one; such a count is bounded with max_lifetime or max_subtree (Section 4.2 of [ASOR]). The DS defines what quantity each key it issues measures, so it is the party that can enforce this: a DS MUST NOT issue a token, including a child requested in a sub-delegation, that carries a max on a key it meters as a running count. max_lifetime and max_subtree name cumulative bounds: a verifier holding only the chain checks that a child's cumulative bound is no wider than its parent's, but two holders of the same chain cannot both decrement a running total correctly without a shared writer. The DS is that writer (Section 6.1): it checks and debits the running total atomically when it authorizes an exercise, and it alone holds the total for every token it issued. The delegation_constraints claim carries the bound; the DS does the debit.¶

5.4. Delegation Chain Integrity

To address the delegation chain splicing vulnerability in Sections 2.1-2.2 of [RFC8693], each delegation hop MUST produce a signed delegation receipt containing: the parent DT's jti, the child DT's jti, the delegating agent's DID, the receiving agent's DID, the root delegated subject (the outer sub), the attenuated capability set, and any source identity evidence recorded for the receiving agent (see Section 4.4). The receipt is signed by the DS and included in the child DT as the prf claim (an array of receipt content identifiers). Chain verification traces prf links back to the root consent event.¶

At every hop, the DS MUST re-verify the parent token and its signed receipt chain, including issuer trust, signatures, expiry, DPoP binding, and revocation state, before issuing a child. It MUST establish that the delegator currently holds the authority being delegated and is allowed to delegate it. Signed provenance alone does not establish either condition. If a required authority or freshness check cannot be completed, the DS MUST NOT issue or exercise the child on the basis of that unresolved input.¶

Authority MUST narrow monotonically: the child's operations and resources MUST be contained in the parent's effective authority, and its constraint ceilings MUST subsume per Section 5.3. Containment is the per-hop admission check. Where independent policies constrain the same action, their intersection MUST be order-independent; an unrecognized or unevaluable constraint MUST NOT be silently discarded. A child's lifetime MUST NOT exceed the remaining lifetime of the parent or the applicable consent grant.¶

For this on-behalf-of delegation profile, each child MUST preserve the root delegated subject in outer sub and name the receiving, current actor in act.sub. Prior actors MAY be represented using nested act as defined in RFC 8693 Section 4.1. Nested actors provide historical attribution only and MUST NOT be used independently to authorize an action. The DS's signed receipts MUST bind the subject and current actor attribution to the parent and child token identifiers and the effective capability set. Actor attribution is attested per hop, not re-derived downstream: each hop's receipt records the act value the DS verified at that hop together with the time it was verified, and a verifier reconstructing the chain composes those attestations rather than inferring a prior hop's actor from a later token. The act claim is the attribution carrier, not proof of authority or a replacement for signed receipts.¶

The DS SHOULD keep, for each hop, an audit record distinct from the receipt that identifies the receipt links, the grant and policy inputs evaluated, their as-of times and validity horizons, the decision, and any failed or unresolved check with a reason. The shape of that record is deployment-defined; verifier-side companion work may standardize it. A verifier MUST have authenticated evidence sufficient to reconstruct the chain to root consent, including the per-hop authority narrowing and subject/actor bindings; raw upstream credentials need not be forwarded. A valid receipt chain does not establish that issuer standing or consent remains current. Required freshness and revocation checks remain separate from chain reconstruction.¶

5.5. Chain-Verifiable Profile

The Delegation Tokens defined above are verified by the DS that issued them, with its receipt chain. Some tokens must instead be verified by a party that is not that DS and holds only the chain: a resource server or another server checking authority offline, or any verifier handed a token a user minted directly with no DS involved. Such tokens use the Delegation Chain format of [ASOR] unchanged: exactly one authorization_details entry, of type agent_delegation, carrying scopes and constraints inside it, with sub naming the principal at every hop, client_id naming the acting agent, cnf, par_hash, del_depth, and del_max_depth as that draft defines them. This document does not redefine that format, and a token under this profile is checked with the algorithm of Section 6 of [ASOR].¶

Cumulative ceilings (max_lifetime, max_subtree, and any running spend total) are enforced only where a single writer holds the total, as the DS does in Section 5.3. A verifier away from the DS enforces the per-exercise ceilings and checks that a child's cumulative bounds are no wider than its parent's. It permits an action under a cumulative constraint only if it holds the running total that constraint is measured over, or a component that holds that total, such as the issuing DS, authorizes the action; otherwise it denies, as step 8 of Section 6 of [ASOR] requires. Separate verifiers that each see only some of the exercises do not between them hold the total.¶

When a DS issues a token under this profile:¶

• The token MUST conform to [ASOR]. It MUST NOT carry a cred_delegation detail or a top-level delegation_constraints claim, since [ASOR] rejects any second detail.¶

• Its lifetime MUST NOT exceed 1 hour, the cap on a Delegation Token (Section 10.6).¶

• Each permitted operation on a resource is expressed as a scope string. Section 4.1 of [ASOR] classifies a scope as literal, wildcard, or opaque by its bytes, not by who issued it, so a provider-issued string such as crm.read is a literal scope that a parent's crm.* covers. The DS MUST choose each scope string so that, under that classification, it admits no more than the capability it maps. The mapping from the capability the DS holds to those scope strings is deployment-defined, and the DS MUST record it in the receipt for the hop.¶

• The DS signs a delegation receipt for the hop as in Section 5.4 and records the token's jti in it. It does not add prf, consent_id, or credential_handle to the token, which [ASOR] does not define; the receipt chain held by the DS remains the evidence that ties the token to consent.¶

• The DS MAY accept at its exercise endpoint (Section 6.1) a token it issued under this profile, resolving the credential and consent from the receipt recorded under the token's jti.¶

When a DS is presented with a token under this profile that it did not issue, it MAY verify the token per Section 6 of [ASOR] and evaluate the authority it carries with the scope grammar and subsumption rules of Section 5.3. Verifying such a token does not make it the parent of a Delegation Token. This revision does not define how a DS accepts a token it did not issue as the root of its own chain, or how a chain continues from a DS-issued token into hops minted without a DS; that composition is left to a later revision.¶

6.1. Exercise Flow

The Agent presents a valid DT and DPoP proof to the DS's /exercise endpoint. The DS:¶

1. Validates the DT signature and expiry, and checks that the DT is not revoked (Section 7)¶

2. Verifies the DPoP binding (htm, htu, nonce)¶

3. Checks that the requested operation is within the DT's authorization_details and within its delegation_constraints, denying an exercise under a constraint of a type it does not implement, and checking and debiting any cumulative total atomically (Section 5.3)¶

4. Retrieves the credential from the Vault using the opaque credential_handle¶

5. Performs the authorized API call against the resource server using the stored credential¶

6. Returns only the API response¶

The raw credential MUST NOT appear in any agent-facing response.¶

6.2. Proxy Semantics

For resource servers that accept standard OAuth Bearer tokens: the DS acts as a reverse proxy, performing the actual API call with the stored credential. The Agent's HTTP request to /exercise specifies the operation and parameters; the DS maps these to the upstream API call.¶

6.3. Native Resource Server Support (Future)

For resource servers that natively support this protocol: the DS performs RFC 8693 token exchange, issuing a scoped access token containing the DT's act claim and authorization_details for direct presentation at the resource server. This eliminates the proxy step for participating services. The lifetime of the exchanged access token MUST NOT exceed 1 hour (Section 10.6) or the remaining lifetime of the DT it was exchanged for.¶

8.1. CIBA-Derived Agent Consent

When an Agent requests a delegation that exceeds pre-authorized policies, the DS initiates a CIBA [OIDC-CIBA] backchannel authentication request to the Subject. The Subject approves or denies on their registered device. On approval, the DS issues the Delegation Token. The Agent polls or receives a push notification when the token is available.¶

8.2. Consent Records

The DS MUST store an immutable record of each consent event, including: Subject identifier, Agent DID, capabilities granted, grant time, expiry, and the full delegation chain context at time of consent. Records MUST be retained for at least 90 days.¶

8.3. Re-Consent Triggers

Consent MUST be re-requested when:¶

1. an Agent requests broader capabilities than previously granted¶

2. the grant has expired¶

3. the agent_operator claim changes¶

4. a security event triggers policy re-evaluation¶

9.1. Cred SDK

Implementer:

Kieran Sweeney (author of this document)¶

Location:

https://github.com/cred-ninja/sdk, branch main, described here as of commit 42b39f4 (2026-10-30), after integration of cred-ninja/sdk#89 to #93 through #96.¶

License:

Apache-2.0¶

Language:

TypeScript (Node.js)¶

Maturity:

Experimental. The implementation follows the architecture of this document (a Delegation Server holding deposited credentials, sub-delegation with attenuation, exercise by proxy), its receipt claim layout, and its Delegation Token, but not its agent authentication or exercise request formats. It is not wire-compatible with this document.¶

Contact:

kieran@kierans.net¶

Implemented as specified, or nearly:¶

• Agent identity (Section 4): did:key identifiers; the server accepts Ed25519 and P-256 keys, and the SDK client generates Ed25519 keys only. Receipt, assertion, and token verifiers hold a local accepted-algorithm list (EdDSA and ES256 by default).¶

• Protocol version negotiation (Section 3.1): the Cred-Protocol-Version header, version 0.1.0, and HTTP 426 with protocol_version_unsupported.¶

• Delegation Token (Section 5): a JWT of type dt+jwt carrying every required claim: iss naming the DS, the principal in sub, the acting agent in client_id and act.sub with prior agents in nested act, authorization_details of type cred_delegation, delegation_constraints when there are ceilings, cnf with the thumbprint of the agent's key, iat, exp, jti, consent_id, and an opaque credential_handle, plus prf with content identifiers of the receipts behind it. It lives 15 minutes by default and never more than 1 hour, and never past its parent or the stored credential. The DS records each token's state and re-reads it after a restart.¶

• Signed receipts (Section 5.4): a compact JWS at each hop, EdDSA or ES256 with kid, with iss naming the DS, the principal in sub, the acting agent in client_id and act.sub, prior agents in nested act, the delegation identifier as jti, cnf bound to the agent's key, a commitment to the parent (SHA-256 over the full compact parent receipt), and a signed lineage of ancestor agents. Before minting a child, the server re-verifies the parent receipt and checks the revocation of the parent delegation and the status of every ancestor agent.¶

• Sub-Delegation Exchange (Section 5.4.1): an authorization step that assigns the child's identifier, signs the receipt, and returns a single-use grant bound to the receiving agent's DID that expires within 60 seconds and never after the parent; and an [RFC8693] token exchange in which the receiving agent presents the grant as subject_token and an [RFC7523] assertion as actor_token, receiving a Delegation Token bound to its own key, with the parent's revocation re-checked at issuance. The grant's token type is a provisional urn:credninja: URN, since this document defines none. The older single-step sub-delegation remains available.¶

• Capabilities: catalogue operations with resources for GitHub repositories and Google Drive files, checked against the granted provider scopes at issuance, as a subset at every hop, and against the actual method and URL at exercise. Scope-shaped operations remain available; a token cannot mix them with catalogue operations. Unknown operations or resources are refused.¶

• Constraint ceilings (Section 5.3): all eight types, fail-closed parsing of closed constraint objects, uniqueness per (key, type), subsumption per hop with no inference across types, inherit-on-omit, rank read with its order, and a constraint of an unrecognized type carried and never treated as absent. Issuance refuses a max on max_calls, the key the server meters as a running count. The Delegation Token carries the ceilings in delegation_constraints; the receipt carries them in a claim named constraints, the name earlier revisions of this document used.¶

• Per-exercise ceilings: max, min, one_of, not_one_of, prefix, and rank are decided from quantities the DS measures, never ones the agent reports. Request-side checks precede dispatch; response-side checks withhold an over-limit response and audit the denial. A catalogue listing is capped before dispatch where its page-size parameter permits it. Unimplemented types and unmetered keys deny exercise. Withholding a response does not undo an upstream effect.¶

• Chain-verifiable profile (Section 5.5): the server mints tokens in the [ASOR] agent_delegation format on request, verifies a presented parent chain before minting a child, and records the token's jti and the scope mapping in the receipt. It does not accept such tokens at its exercise endpoint.¶

• Proof of possession (Section 10.3): a Delegation Token is issued only to a did:key agent that proves its key with a DPoP proof [RFC9449], and is bound to that key. Every exercise presents the token as a DPoP-bound access token with a fresh proof by the key whose ath is the hash of the token and which, through a SHA-256 hash of the JCS form [RFC8785] of the exercise request, is bound to that one request: its upstream URL, method, body, and headers. Replayed, stale, and mismatched proofs are refused before any upstream call. A sub-delegated token is bound to the receiving agent's key, so the delegating agent that relays it cannot use it.¶

• Exercise (Section 6.1): provider credentials stay in the server's vault and the server makes the upstream call; by default the server hands no provider token to an agent. Revocation is checked when the request arrives and again just before the upstream call, with HTTP 401 delegation_revoked. An exercise under a constraint of an unrecognized type is denied, and max_lifetime and max_subtree totals are checked and debited atomically by a single-writer ledger.¶

• Consent records (Section 8): every root Delegation Token names, in consent_id, a record of the consent behind it (subject, agent DID, capabilities granted, how consent was given and by whom, grant time, expiry, and the chain context), which storage refuses to update. Records are retained for at least 90 days after the later of grant and expiry, then purged with an audited count.¶

• Consent approval (Section 8): a CIBA-derived [OIDC-CIBA] poll flow for permissions requiring approval, with the Subject, an administrator, or both as approver. An approval is reused only for requests it covers. Broader capabilities, expired consent, looser ceilings, a different app client or approver requirement, and security events require approval again; revoked consent is checked at exercise.¶

• Cred Link: delegations use DPoP-bound Delegation Tokens, with the connection, client, grant and agent re-checked at exercise.¶

• Revocation (Section 7): DELETE /delegation/{jti} (also served as DELETE /api/v1/delegations/{id}) revokes a delegation and cascades to its descendants in one transaction, reporting revoked_count; tests measure the cascade under 5 seconds for up to 1,111 descendants.¶

• Audit: delegation, exercise, and revocation events in a log whose rows are chained by a keyed hash, with an endpoint that verifies the chain.¶

Remaining differences and limitations:¶

• Agent authentication and exercise interface: root delegation uses a deployment credential and DPoP, not an [RFC7523] assertion. Sub-delegation and token exchange use an [RFC7523] actor_token. Exercise uses the Delegation Token and DPoP at POST /api/v1/use, naming an upstream URL, method and body rather than an operation at /exercise.¶

• Capabilities: no capability-level expires; catalogue resource kinds are repositories and files, not the folder resource illustrated in Section 5.2. Cred Link delegation does not accept requested constraint ceilings.¶

• Consent: no re-consent on agent_operator change. The CIBA-derived request and error formats differ from CIBA Core; approval state is in process memory, the built-in approval link is a bearer credential, and an external provider's id_token is not verified. A non-expiring consent can be purged after 90 days while dependent delegations remain live.¶

• Revocation: the 1-second single-token bound is not measured by tests, and revocation of one Cred Link token by identifier is not implemented.¶

• DPoP: the DS issues no nonce.¶

Conformance results. At SDK commit 42b39f4, the native [ASOR] verifier, verifyAgentDelegationChain(), passes all 35 vectors from draft-asor-wimse-agent-delegation-chain-02 (attenu-guard v0.20.0) and all 36 from [ASOR] (attenu-guard v0.22.0). It reads each token without claim mapping. Every rejection is checked for the declared outcome, the hop, and the isolated rule; the added -03 vector, reject_child_adds_detail_type, is rejected at hop 2 for carrying a second detail. The SDK's own -02 test and the protocol repository's native runner provide repeatable checks.¶

A separate, older runner maps the vectors' claims onto the SDK's receipt hop model and supplies signature and parent-hash checks itself. At the same SDK commit it passes all 20 -01 vectors; for -02 it reports 21 passes, 4 failures and 10 gaps; for -03, 21 passes, 4 failures and 11 gaps, unchanged from 4c61b88. These are different code paths and measurements. The failures are different rejection reasons; the gaps are claim rules the mapped model cannot represent, including audience, confirmation, the closed and single detail, and per-hop maximum depth. No vector is skipped. The native results above are the result for the [ASOR] token format.¶

These are library-level results over fixed test vectors, not full protocol conformance. Neither runner covers holder binding or status (steps 6 and 7 of Section 6 of [ASOR]), or the HTTP interface and wire formats defined in this document. The runners, vectors, and revision-pinned results are at https://github.com/cred-ninja/protocol/tree/main/conformance/asor-delegation-chain.¶

10.1. Confused Deputy Mitigation

Capability-shaped tokens eliminate ambient authority. An adversarially-prompted agent cannot widen its own capabilities since attenuation is DS-enforced. OAuth access tokens are ambient authority: any code holding the token exercises its full scope. For adversarially-promptable agents, this is a structural exploit vector. Cred delegation tokens are operation-bound, resource-specific, and constraint-bearing, following the principle that designation should equal authority [CONFUSED-DEPUTY].¶

10.2. Delegation Chain Splicing

The mandatory prf chain with DS-signed receipts addresses the vulnerability in Sections 2.1-2.2 of [RFC8693] disclosed to the OAuth WG on February 26, 2026 [OAUTH-SPLICING]. Each receipt cross-references parent and child DT jti values along with both agent DIDs, preventing presentation of tokens from mismatched delegation contexts. The requested_actor/actor_token binding proposed in [OBO-USER] mitigates the same class of attack at the authorization server for the first delegation hop; the prf chain extends equivalent protection across every subsequent hop (see Section 1.2). The two can compose: a DS can accept an actor-bound access token issued under [OBO-USER] as the credential it wraps, then produce prf receipts for every sub-delegation beyond that first hop.¶

10.3. DPoP Binding

DPoP [RFC9449] prevents Delegation Token theft and replay by requiring cryptographic proof of private key possession on every /exercise request. The proof is bound to the htm (HTTP method) and htu (URI) of the request, not to its body. Every exercise goes to the same /exercise endpoint and carries its operation and parameters in the body (Section 6.2), so the DPoP proof does not bind or distinguish them. The DS validates the actual operation and parameters against the Delegation Token (Section 6.1). Signed evidence of the request body would need a separate commitment to it, which this document does not define.¶

10.4. Prompt Injection Containment

Because the underlying credential is never delivered to the Agent, a successful prompt injection attack on the Agent cannot exfiltrate it. That does not cover the DS itself (Section 10.9) or a credential that an upstream response reflects or mints. The agent can only exercise capabilities already granted in its DT, and only via the DS /exercise endpoint. The blast radius of a compromised agent is bounded by its current DT's authorization_details.¶

10.5. Chain Depth Limits

Implementations SHOULD enforce a maximum delegation chain depth of 5. Unbounded sub-delegation creates exponential revocation cascades and audit complexity.¶

10.6. Token Lifetime

The default DT lifetime of 15 minutes limits the blast radius of any single token compromise. Implementations MUST NOT issue DTs with a lifetime exceeding 1 hour. The same cap applies to a token a DS issues under Section 5.5 and to an access token it issues by exchange (Section 6.3), so that a token used away from the DS outlives a revocation by at most 1 hour (Section 7).¶

10.7. Model Identity and Substitution

The agent_model claim is self-asserted. A credential valid for an agent remains valid if the operator substitutes the underlying model, a threat class raised against the AIMS predecessor framework in March 2026. Verifying model identity requires attestation of the agent runtime and is out of scope for this document. Deployments that need it should treat these claims as advisory policy input, not proof, and look to remote attestation work in the RATS WG.¶

10.8. Long-Term Evidence

Delegation receipts are signed by the DS, with Ed25519 or P-256 unless a deployment uses ML-DSA; a deployment may sign its consent and audit records the same way. A signed record retained as dispute evidence beyond the period in which its signature can be trusted against a cryptographically relevant quantum computer loses its value as evidence unless it was anchored while still trustworthy, for example by periodic time-stamping under a post-quantum signature or by inclusion in an append-only log whose head is so signed. Deployments that retain signed records for that long SHOULD anchor them. Consent and audit records that are immutable but unsigned carry evidence only as strong as the integrity controls of their store; a deployment that relies on them as dispute evidence SHOULD commit their digests to such a log.¶

10.9. Trusted Delegation Server

The DS holds the credentials Subjects deposit and is trusted with them. Compromise of the DS, of its operator, or of the path by which it releases the keys that protect stored credentials exposes those credentials and lets an attacker exercise them, with no Delegation Token and within whatever the upstream provider granted. Keeping credentials away from Agents does not remove this exposure; it concentrates it at the DS.¶

Delegation receipts are signed by the DS. A DS-signed receipt proves that the DS authorized an action under its own records; it does not prove that the Subject, rather than the operator, approved the grant those records describe. Deployments that need stronger guarantees can isolate credential custody per tenant or run the DS in hardware-protected execution environments. Root approval that can be verified independently of the DS, signed with a key the user holds, is left to a later revision.¶

12.1. Normative References

[ASOR]

Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, draft-asor-wimse-agent-delegation-chain-03, October 2026, <https://datatracker.ietf.org/doc/draft-asor-wimse-agent-delegation-chain/>.

[DID-CORE]

Sporny, M., Longley, D., and D. Chadwick, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022, <https://www.w3.org/TR/did-core/>.

[DID-KEY]

Longley, D., "The did:key Method v0.7", W3C CCG Draft, <https://w3c-ccg.github.io/did-method-key/>.

[OIDC-CIBA]

OpenID Foundation, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", September 2021, <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

12.2. Informative References

[AAT]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, draft-niyikiza-oauth-attenuating-agent-tokens-02, October 2026, <https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/>.

[AGENTIC-JWT]

Goswami, A., "Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management", Work in Progress, draft-goswami-agentic-jwt-01, July 2026, <https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/>.

[AIMS]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, draft-ietf-wimse-aims-00, 15 September 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/>.

[ASYNC-DELEG]

Zhu, L., "Delegated Refresh Tokens for OAuth 2.0 Token Exchange", Work in Progress, draft-zhu-oauth-async-delegation-05, August 2026, <https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/>.

[CB4A]

Hartman, K., "Credential Broker for Agents (CB4A)", Work in Progress (expired), draft-hartman-credential-broker-4-agents-00, March 2026, <https://datatracker.ietf.org/doc/draft-hartman-credential-broker-4-agents/>.

[CONFUSED-DEPUTY]

Hardy, N., "The Confused Deputy (or Why Capabilities Might Have Been Invented)", ACM SIGOPS Operating Systems Review, 1988.

[CROSS-ORG-REQS]

Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", Work in Progress, draft-reece-wimse-cross-org-delegation-02, August 2026, <https://datatracker.ietf.org/doc/draft-reece-wimse-cross-org-delegation/>.

[DELEG-RECEIPTS]

Nelson, R., "Agent Delegation Receipts", Work in Progress, draft-nelson-agent-delegation-receipts-15, October 2026, <https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/>.

[DELEGATE-SD-JWT]

Oliver, G., "Delegate SD-JWT", Work in Progress (expired), draft-gco-oauth-delegate-sd-jwt-00, April 2026, <https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/>.

[ECT]

Nennemann, C., "Execution Context Tokens for Distributed Agentic Workflows", Work in Progress (expired), draft-nennemann-wimse-ect-00, February 2026, <https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/>.

[FIPS204]

National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS 204, August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.

[MANDATE-PS]

Yossif, M., "Problem Statement on Verifiable Human Mandates for Autonomous Agent Actions", Work in Progress, draft-yossif-agent-mandate-problem-00, July 2026, <https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/>.

[MILLER-2006]

Miller, M. S., "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control", PhD thesis, Johns Hopkins University, 2006.

[NIST-AGENT-ID]

NIST NCCoE, "Accelerating the Adoption of Software and AI Agent Identity and Authorization", February 2026, <https://www.nccoe.nist.gov/>.

[OAUTH-CHAINING]

IETF OAuth Working Group, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, draft-ietf-oauth-identity-chaining-17, in the RFC Editor queue, August 2026, <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/>.

[OAUTH-SPLICING]

OAuth Working Group mailing list, "Security Consideration: Delegation Chain Splicing in RFC 8693 Token Exchange", February 2026, <https://mailarchive.ietf.org/arch/browse/oauth/>.

[OBO-USER]

Dissanayaka, T. and A. Dissanayaka, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", Work in Progress (expired), draft-oauth-ai-agents-on-behalf-of-user-02, August 2025, <https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/>.

[OIDC-FED]

OpenID Foundation, "OpenID Federation 1.0", <https://openid.net/specs/openid-federation-1_0.html>.

[OWASP-AGENTIC]

OWASP, "Top 10 for Agentic Applications v1.0", December 2025, <https://owasp.org/>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[TXN-AGENTS]

Raut, A., "Transaction Tokens For Agents", Work in Progress, draft-araut-oauth-transaction-tokens-for-agents-02, May 2026, <https://datatracker.ietf.org/doc/draft-araut-oauth-transaction-tokens-for-agents/>.

[UCAN-SPEC]

Zelenka, B., "UCAN Delegation", RC v1.0, <https://github.com/ucan-wg/delegation>.

[WAG]

Carleton, P., Ed., Steele, N., Parecki, A., Schwenkschuster, A., and B. Campbell, "Workload Authorization Grant", Work in Progress, draft-carleton-workload-authz-grant-01, 22 September 2026, <https://datatracker.ietf.org/doc/draft-carleton-workload-authz-grant/>.

[WIMSE-AGENT]

Ni, Y., Liu, P., and B. Wang, "WIMSE Applicability for AI Agents", Work in Progress, draft-ni-wimse-ai-agent-identity-04, October 2026, <https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/>.

[WIMSE-ARCH]

IETF WIMSE Working Group, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, draft-ietf-wimse-arch-08, July 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

[WIMSE-CRED-X]

Schwenkschuster, A., "WIMSE Credential Exchange", Work in Progress (expired), draft-schwenkschuster-wimse-credential-exchange-03, October 2025, <https://datatracker.ietf.org/doc/draft-schwenkschuster-wimse-credential-exchange/>.

[WIMSE-WPT]

IETF WIMSE Working Group, "WIMSE Workload Proof Token", Work in Progress, draft-ietf-wimse-wpt-02, August 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/>.