WIMSE K. Sweeney Internet-Draft 13 October 2026 Intended status: Standards Track Expires: 16 April 2027 Credential Delegation Protocol for AI Agents in Multi-System Environments draft-sweeney-wimse-credential-delegation-01 Abstract Autonomous AI agents increasingly require access to protected resources across multiple service providers on behalf of human users. Existing OAuth 2.0 extensions address individual aspects of this problem (token exchange, proof-of-possession, and structured authorization) but no current specification defines how these mechanisms compose into a coherent credential delegation framework for AI agents. This document specifies the Credential Delegation Protocol: a profile of OAuth 2.0 Token Exchange (RFC 8693), Demonstrating Proof-of- Possession (RFC 9449), Rich Authorization Requests (RFC 9396), and Client-Initiated Backchannel Authentication (OpenID Connect CIBA) that enables human users to delegate scoped, attenuated credentials to AI agents operating across heterogeneous service providers. The protocol defines: agent identity lifecycle management using ephemeral key pairs; capability-shaped delegation tokens bound to specific operations and resources; credential wrapping semantics that prevent exposure of underlying OAuth tokens to agents; consent-gated delegation flows for asynchronous agents; real-time cascading revocation; and tamper-evident audit chains. This document does not define new token formats, new OAuth grant types, or modifications to existing authorization server behavior. It specifies how existing mechanisms are combined to achieve secure, auditable credential delegation for AI agents. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential- delegation/. Sweeney Expires 16 April 2027 [Page 1] Internet-Draft Credential Delegation for AI Agents October 2026 Discussion of this document takes place on the Workload Identity in Multi System Environments (WIMSE) Working Group mailing list (mailto:wimse@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at https://www.ietf.org/mailman/listinfo/wimse/. Source for this draft and an issue tracker can be found at https://github.com/cred-ninja/protocol. 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 16 April 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to Existing Work . . . . . . . . . . . . . . 5 1.2.1. Frameworks and Working Group Documents . . . . . . . 5 1.2.2. Delegation Chain Mechanics . . . . . . . . . . . . . 6 1.2.3. Credential Intermediation . . . . . . . . . . . . . . 7 Sweeney Expires 16 April 2027 [Page 2] Internet-Draft Credential Delegation for AI Agents October 2026 1.2.4. Consent, Mandates, and Audit Evidence . . . . . . . . 8 1.3. Design Principles . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 3.1. Protocol Version Negotiation . . . . . . . . . . . . . . 12 4. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Ephemeral Key Pairs . . . . . . . . . . . . . . . . . . . 13 4.2. Agent Authentication . . . . . . . . . . . . . . . . . . 13 4.3. Agent Lifecycle . . . . . . . . . . . . . . . . . . . . . 14 4.4. Workload Authorization Grant Composition . . . . . . . . 14 5. Delegation Token Format . . . . . . . . . . . . . . . . . . . 15 5.1. Required Claims . . . . . . . . . . . . . . . . . . . . . 15 5.2. Capability Structure . . . . . . . . . . . . . . . . . . 16 5.3. Constraint Ceilings . . . . . . . . . . . . . . . . . . . 17 5.4. Delegation Chain Integrity . . . . . . . . . . . . . . . 18 6. Credential Wrapping . . . . . . . . . . . . . . . . . . . . . 19 6.1. Exercise Flow . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Proxy Semantics . . . . . . . . . . . . . . . . . . . . . 20 6.3. Native Resource Server Support (Future) . . . . . . . . . 20 7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Consent Flow . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. CIBA-Derived Agent Consent . . . . . . . . . . . . . . . 21 8.2. Consent Records . . . . . . . . . . . . . . . . . . . . . 21 8.3. Re-Consent Triggers . . . . . . . . . . . . . . . . . . . 21 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 9.1. Cred SDK . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10.1. Confused Deputy Mitigation . . . . . . . . . . . . . . . 24 10.2. Delegation Chain Splicing . . . . . . . . . . . . . . . 24 10.3. DPoP Binding . . . . . . . . . . . . . . . . . . . . . . 25 10.4. Prompt Injection Containment . . . . . . . . . . . . . . 25 10.5. Chain Depth Limits . . . . . . . . . . . . . . . . . . . 25 10.6. Token Lifetime . . . . . . . . . . . . . . . . . . . . . 25 10.7. Model Identity and Substitution . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27 Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Sweeney Expires 16 April 2027 [Page 3] Internet-Draft Credential Delegation for AI Agents October 2026 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. Sweeney Expires 16 April 2027 [Page 4] Internet-Draft Credential Delegation for AI Agents October 2026 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.2.1. Frameworks and Working Group Documents *draft-ietf-wimse-aims* ([AIMS]): AI Identity Management System, a framework for AI agent authentication and authorization, adopted by WIMSE and published as draft-ietf-wimse-aims-00. The framework identifies the need for concrete delegation mechanics and defers them to OAuth flows. This document supplies those mechanics and is designed as a companion, not a replacement. *draft-ietf-wimse-arch* ([WIMSE-ARCH]): Defines the trust domain model and terminology assumed here for WIMSE deployments. The Delegation Server is a service within a trust domain, and Agent identities established per Section 4 are compatible with WIMSE workload identifiers. *draft-ietf-wimse-wpt* ([WIMSE-WPT]): Defines the Workload Proof Token (WPT), a proof-of-possession mechanism for workloads. This protocol binds Delegation Tokens with DPoP [RFC9449] instead: DTs are exercised over plain HTTP by ephemeral agents that may sit outside any WIMSE trust domain, the deployment shape DPoP already serves. A future revision may profile WPT for DS-to-resource-server hops inside WIMSE trust domains. Sweeney Expires 16 April 2027 [Page 5] Internet-Draft Credential Delegation for AI Agents October 2026 *draft-ni-wimse-ai-agent-identity* ([WIMSE-AGENT]): Addresses agent identity within WIMSE. The did:key model used here is compatible. This document adds credential wrapping, revocation, consent gating, and chain verification. *draft-reece-wimse-cross-org-delegation* ([CROSS-ORG-REQS]): A problem statement and requirements catalogue for cross-organizational delegation, used on the WIMSE list as a common frame for evaluating delegation proposals. A future revision of this document will map the protocol against those requirements. 1.2.2. Delegation Chain Mechanics *draft-ietf-oauth-identity-chaining* ([OAUTH-CHAINING]): In the RFC Editor queue at -17. Chains identity and authorization across trust domains by exchanging a token in one domain for a JWT assertion accepted in another. It preserves identity across hops but does not constrain what each hop may do. This protocol adds structural attenuation and receipt-based chain verification on the same RFC 8693 substrate. The two compose. *draft-niyikiza-oauth-attenuating-agent-tokens* ([AAT]): Defines tokens a holder can attenuate offline, in the macaroon tradition. Same goal as Section 5.4, different trust model: AAT verification relies on the root issuer key and offline derivation, while this protocol keeps the Delegation Server in the loop at every hop in exchange for synchronous revocation (Section 7) and server-checked strict-subset validation. *draft-asor-wimse-agent-delegation-chain* ([ASOR]): Defines an offline-verifiable Delegation Chain of RFC 9068 JWTs, each committing to its parent's signing input by hash, carrying authority as an RFC 9396 agent_delegation detail with a wildcard scope grammar and a typed constraint vocabulary (Section 4.2 of that draft), and verified by a deterministic algorithm with no call to an authorization server. This protocol is the server-side counterpart: the Delegation Server is in the loop at every hop and holds the credentials, so revocation is synchronous and aggregate budgets have a single writer, while a receipt chain verified offline still proves scope narrowing, depth, linkage, expiry ordering, and, with Section 5.3, ceiling narrowing. The two share the constraint vocabulary so that a chain minted by either can be checked by a verifier written for the other; Cred's reference implementation is run against the Asor interop vectors as part of its conformance suite and, at the time of writing, passes all twenty; Section 9 states what those vectors do and do not cover. Sweeney Expires 16 April 2027 [Page 6] Internet-Draft Credential Delegation for AI Agents October 2026 *draft-gco-oauth-delegate-sd-jwt* ([DELEGATE-SD-JWT]; the OAuth WG call for adoption closed on 12 October 2026, and the chairs had not announced the result at the time of writing): Delegates SD-JWT credentials holder-to-holder by allowing a Key Binding JWT to act as an SD-JWT. It operates at the credential format layer; this protocol operates at the delegation service layer. A DS could issue capability attestations as Delegate SD-JWTs without changing the mechanics defined here. Comments in the adoption call identified what the format layer leaves open: a delegate payload may add claims with no rule against widening a predecessor's, a delegation's lifetime is not bounded by its predecessor's, and depth and no- further-delegation limits are undefined. Those are the chain rules of Section 5.4, which a holder-signed profile would need to state in its own terms. *draft-zhu-oauth-async-delegation* ([ASYNC-DELEG]): Defines delegated refresh tokens so agents can act while the user is offline. This protocol answers the same need by keeping refresh tokens in the Credential Vault and giving agents only short-lived DTs. The two are alternative positions on whether agents may hold long-lived credentials at all. *draft-oauth-ai-agents-on-behalf-of-user* ([OBO-USER]; expired February 2026): Introduced requested_actor and actor_token parameters binding the acting agent into the authorization code exchange. That closes the same actor-binding weakness this protocol closes with prf receipts, but only for the first hop and only at the authorization server. See Section 10.2. 1.2.3. Credential Intermediation *draft-hartman-credential-broker-4-agents* ([CB4A]; expired): Specifies a credential vaulting broker that mediates agent API access through short-lived, narrowly scoped proxy credentials. Architecturally the closest work to the Delegation Server and Credential Vault defined here. CB4A defines the broker; this document additionally defines the delegation chain (attenuation, receipts, sub-delegation), the consent flow, and the revocation cascade such a broker must enforce. *draft-araut-oauth-transaction-tokens-for-agents* ([TXN-AGENTS]): Extends transaction tokens to carry agent context in the act claim for intra-domain call chains. Complementary: transaction tokens propagate context within a domain after authorization exists; this protocol governs how the authorization comes to exist. Sweeney Expires 16 April 2027 [Page 7] Internet-Draft Credential Delegation for AI Agents October 2026 *draft-schwenkschuster-wimse-credential-exchange* ([WIMSE-CRED-X]; expired): Despite the similar name, addresses a workload exchanging its own credential for a different format or trust domain. This document addresses human-to-agent delegation over stored credentials that are never issued to the requesting party. 1.2.4. Consent, Mandates, and Audit Evidence *draft-yossif-agent-mandate-problem* ([MANDATE-PS]): A problem statement on verifiable human mandates: intent authorized at one time, executed autonomously later. The consent records (Section 8) and capability constraints defined here are a concrete answer to part of that problem space. *draft-nelson-agent-delegation-receipts* ([DELEG-RECEIPTS]): Defines a delegation receipt signed by the authorizing human principal's key, recording what an agent may do, for how long, and under what instructions, with scope attenuation rules for multi-agent chains and a revocation registry with cascade semantics. The prf receipts in Section 5.4 are DS-signed and bind hops within a chain; Nelson's receipts are principal-signed and bind the principal's instruction to the agent's run. They answer different trust questions and can coexist. *draft-nennemann-wimse-ect* ([ECT]; expired): Execution Context Tokens define an audit record format. This protocol's audit chain is designed to be ECT-compatible. *draft-goswami-agentic-jwt* ([AGENTIC-JWT]): Proposes agent checksums and intent binding. The agent_checksum claim (Section 4.2) remains defined for compatibility, with no dependency taken. A US patent has been filed on the underlying mechanism; this specification avoids the patented specifics. 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]. Sweeney Expires 16 April 2027 [Page 8] Internet-Draft Credential Delegation for AI Agents October 2026 *Credentials are never possessed.* Agents receive and exercise delegated authority through the Delegation Server. Raw credentials never cross the boundary to the agent host. This architecturally eliminates the confused deputy attack surface for credential theft [CONFUSED-DEPUTY]. *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. 2. 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. Delegation Server (DS): A service that issues, manages, and revokes Delegation Tokens on behalf of Subjects. The DS maintains the Credential Vault and enforces delegation policies. It acts as an intermediary between Agents and upstream OAuth authorization servers. Agent: An autonomous software entity that performs actions on behalf of a Subject across one or more service providers. An Agent authenticates to the DS using an ephemeral key pair and receives Delegation Tokens authorizing specific operations. An Agent MUST NOT possess or have access to the underlying credentials stored in the Credential Vault. Subject: The human user who authorizes credential delegation. The Subject authenticates to the DS, deposits credentials into the Credential Vault, defines delegation policies, and approves or denies consent-gated delegation requests. Delegation Token (DT): A signed JWT issued by the DS that authorizes Sweeney Expires 16 April 2027 [Page 9] Internet-Draft Credential Delegation for AI Agents October 2026 an Agent to perform specified operations on specified resources via the DS. A DT contains capability claims structured per [RFC9396], a DPoP key binding for proof-of-possession verification, and an opaque credential handle. Delegation Tokens MUST NOT contain raw OAuth tokens or credentials. Credential Vault: Server-side secure storage maintained by the DS that holds OAuth tokens and credentials deposited by Subjects. Credentials are referenced by opaque handles and exercised exclusively by the DS on behalf of Agents presenting valid Delegation Tokens. Capability: A structured authorization grant specifying a permitted operation, a target resource, and optional constraints (time bounds, rate limits, argument restrictions). Expressed using the authorization_details object defined in [RFC9396] and bound to a specific Delegation Token. Attenuation: The process by which a Capability is further constrained when delegated from one entity to another. An attenuated Capability MUST be a strict subset of its parent. Authority can only narrow at each delegation hop; it can never widen. Delegation Chain: An ordered sequence of Delegation Tokens from Subject to Agent_1 to Agent_2 ... to Agent_N, where each link attenuates the authority of the previous. The chain is verifiable from any link back to the root consent event via signed delegation receipts. Credential Exercise: The act of the DS using a stored credential on behalf of an Agent. The Agent presents a valid DT and DPoP proof to the DS, which validates the DT, retrieves the credential from the Vault, calls the resource server, and returns only the API response. 3. Architecture Overview Sweeney Expires 16 April 2027 [Page 10] Internet-Draft Credential Delegation for AI Agents October 2026 +------------------------------------------------------+ | SUBJECT (User) | | 1. Connects services (OAuth) | | 2. Sets delegation policies | | 3. Approves consent requests (CIBA) | +--------------------------+---------------------------+ | v +------------------------------------------------------+ | DELEGATION SERVER (DS) | | | | +-------------+ +------------+ +--------------+ | | | Credential | | Delegation | | Consent | | | | Vault | | Engine | | Manager | | | | | | | | (CIBA) | | | | OAuth tokens| | DT issue | | | | | | API keys | | Attenuation| | Approve/Deny | | | | Refresh tkns| | Chain vrfy | | Policy eval | | | +------+------+ +------------+ +--------------+ | | | | | +------+---------------------------------------+ | | | Exercise Proxy | | | | Validates DT -> Retrieves cred -> Calls RS | | | | Returns API response (never raw credential) | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | Revocation & Audit | | | | Synchronous cascade | Tamper-evident log | | | +----------------------------------------------+ | +--------------------------+---------------------------+ | v +------------------------------------------------------+ | AGENT | | | | 1. Generates ephemeral did:key | | 2. Authenticates via JWT Bearer (RFC 7523) | | 3. Requests delegation (capabilities + constraints) | | 4. Receives DT (DPoP-bound, capability-shaped) | | 5. Exercises credentials via DS /exercise endpoint | | 6. Sub-delegates via attenuation (optional) | | | | TRUST BOUNDARY: Agent sees DT + API responses only | | Agent NEVER sees: raw tokens, refresh tokens, keys | +------------------------------------------------------+ Figure 1: Protocol Architecture Sweeney Expires 16 April 2027 [Page 11] Internet-Draft Credential Delegation for AI Agents October 2026 *Critical architectural property:* The Agent's trust boundary extends only to the network interface of the Delegation Server. The Agent never crosses into the Vault. This eliminates credential theft as an attack surface: there is nothing for a compromised agent to exfiltrate. 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. Sweeney Expires 16 April 2027 [Page 12] Internet-Draft Credential Delegation for AI Agents October 2026 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. Agent Identity 4.1. Ephemeral Key Pairs An Agent MUST generate an Ed25519 or P-256 key pair at instantiation. 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. 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: +=======+=================+==================+ | Claim | Value | Notes | +=======+=================+==================+ | iss | Agent DID | did:key:z... | +-------+-----------------+------------------+ | sub | Agent DID | Same as iss | +-------+-----------------+------------------+ | aud | DS endpoint URL | | +-------+-----------------+------------------+ | iat | Current time | | +-------+-----------------+------------------+ | exp | iat + max 300s | 5-minute maximum | +-------+-----------------+------------------+ | jti | Unique nonce | Prevents replay | +-------+-----------------+------------------+ Table 1: Required authentication claims Optional claims: Sweeney Expires 16 April 2027 [Page 13] Internet-Draft Credential Delegation for AI Agents October 2026 +================+============+===================================+ | Claim | Value | Notes | +================+============+===================================+ | agent_model | Model | Vendor-prefixed, e.g., | | | identifier | "vendor:model-id" | +----------------+------------+-----------------------------------+ | agent_operator | Operator | Organization running the agent | | | DID or URL | | +----------------+------------+-----------------------------------+ | agent_checksum | SHA-256 | Intent binding per [AGENTIC-JWT]; | | | hash | advisory only due to IPR | +----------------+------------+-----------------------------------+ Table 2: Optional authentication 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. A deployment Sweeney Expires 16 April 2027 [Page 14] Internet-Draft Credential Delegation for AI Agents October 2026 that surfaces the WAG identity inside a token MAY carry it as iss and sub members of act, which RFC 8693 Section 4.1 allows for identifying an actor, while the outer sub remains the delegated principal. 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. Delegation Token Format A Delegation Token is a DPoP-bound JWT [RFC9449] issued by the Delegation Server. 5.1. Required Claims +=======================+===============+===========================+ | Claim | Value | Specification | +=======================+===============+===========================+ | iss | DS identifier | | +-----------------------+---------------+---------------------------+ | sub | Subject | User on whose behalf | | | identifier | delegation occurs | +-----------------------+---------------+---------------------------+ | client_id | Agent DID | Acting agent, per | | | | [RFC9068] Section 2.2 | | | | and [AIMS] Section 10.3 | +-----------------------+---------------+---------------------------+ | act | {"sub": | Current actor plus | | | ""} | per RFC 8693, | | | | Section 4.1 | +-----------------------+---------------+---------------------------+ | authorization_details | Capability | Per RFC 9396 | | | array | | +-----------------------+---------------+---------------------------+ | constraints | Ceiling array | Per-key ceilings in the | | | | [ASOR] Section 4.2 | | | | shape; see Section 5.3. | | | | OPTIONAL on a root | | | | token; REQUIRED on a | | | | child whose parent | | | | carries any | +-----------------------+---------------+---------------------------+ | cnf | {"jkt": | Per RFC 9449 | | | ""} | | +-----------------------+---------------+---------------------------+ | iat | Issuance time | | +-----------------------+---------------+---------------------------+ | exp | Expiry time | Max 1 hour; 15 minutes | | | | RECOMMENDED | +-----------------------+---------------+---------------------------+ | jti | Unique | | | | identifier | | +-----------------------+---------------+---------------------------+ | consent_id | Consent | Traceable to root | | | record ID | consent event | +-----------------------+---------------+---------------------------+ | credential_handle | Opaque string | References Vault entry; | | | | MUST NOT be the | | | | credential itself | +-----------------------+---------------+---------------------------+ Table 3: Required Delegation Token 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. 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 constraints claim (Section 5.3) so that a verifier holding only the chain can check that they narrow hop by hop. Sweeney Expires 16 April 2027 [Page 16] Internet-Draft Credential Delegation for AI Agents October 2026 5.3. Constraint Ceilings A Delegation Token MAY carry a 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. "constraints": [ { "key": "max_rows", "max": 5000 }, { "key": "region", "one_of": ["us", "eu"] }, { "key": "egress", "rank": "none" } ] Parsing is fail-closed. An entry with no type member, more than one, a type the DS does not recognize, a malformed value, or a key repeated within the array makes the whole claim malformed, and a token with a malformed constraints claim is invalid before any subsumption is evaluated. A verifier that encounters an unknown constraint type MUST treat the action as denied, never as unconstrained. 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 constraints, the DS inherits the parent's ceilings into the child unchanged. Sweeney Expires 16 April 2027 [Page 17] Internet-Draft Credential Delegation for AI Agents October 2026 Labels used with rank have no ordering on the wire. [ASOR] names one example ordering (egress: none < internal < any) and its interop vectors depend on it, but neither the token nor the proposed constraint-types registry carries an ordering for a key. A DS MUST hold a registered ordering for every rank label it mints, and MUST reject a delegation request whose rank label it cannot order rather than issue a token no later hop can compare. A verifier that encounters a label with no registered ordering MUST fail closed. The ordering gap is raised with the [ASOR] author as input to that draft's next revision. Ceilings in constraints bound each exercise of the capability and are checked offline by any holder of the chain. Lifetime aggregates, such as a count of calls measured across a delegation's whole life, are not expressible as a per-hop ceiling: two holders of the same chain cannot both decrement a counter correctly without a shared writer. The DS is that writer (Section 6.1); the 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. Sweeney Expires 16 April 2027 [Page 18] Internet-Draft Credential Delegation for AI Agents October 2026 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. 6. Credential Wrapping 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 2. Verifies the DPoP binding (htm, htu, nonce) 3. Checks that the requested operation is within the DT's authorization_details 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 Sweeney Expires 16 April 2027 [Page 19] Internet-Draft Credential Delegation for AI Agents October 2026 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. 7. Revocation When a Subject revokes a delegation (root or any subtree node), the DS MUST: 1. Invalidate the specified DT within *1 second* 2. Cascade revocation to all descendant DTs within *5 seconds* 3. Return HTTP 401 with error: delegation_revoked for any in-flight /exercise request using a revoked DT 4. Write an immutable revocation event to the audit log with a revocation_time claim *Revocation endpoint:* DELETE /delegation/{jti} The response MUST include a revoked_count field indicating the number of tokens invalidated in the cascade. 8. Consent Flow Sweeney Expires 16 April 2027 [Page 20] Internet-Draft Credential Delegation for AI Agents October 2026 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. Implementation Status Note to the RFC Editor: please remove this section and the reference to [RFC7942] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. Sweeney Expires 16 April 2027 [Page 21] Internet-Draft Credential Delegation for AI Agents October 2026 According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 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 09f9488 (2026-10-13) 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) but not yet its token, request, or proof-of-possession formats. It is not wire-compatible with this document. Contact: kieran@kierans.net Implemented: * Agent identity (Section 4): Ed25519 key pairs and did:key identifiers. P-256 is not implemented. * Protocol version negotiation (Section 3.1): the Cred-Protocol- Version header, version 0.1.0, and HTTP 426 with protocol_version_unsupported. * Credential wrapping (Section 6.1): provider tokens stay in the server's vault and the server makes the upstream call on the agent's behalf. A sub-delegated agent always receives a brokered handle, never a raw provider token. * Sub-delegation with attenuation (Section 5.4): wildcard-aware scope containment, a per-permission depth limit, matching service, user, and application context across hops, and a child expiry bounded by the parent's. Sweeney Expires 16 April 2027 [Page 22] Internet-Draft Credential Delegation for AI Agents October 2026 * Constraint ceilings (Section 5.3): all six types, fail-closed parsing, subsumption per hop, inherit-on-omit, and rank labels resolved through a per-key ordering, with an unknown label rejected. * Signed receipts: the server mints a compact Ed25519 JWS at each hop carrying client_id (the agent DID), a commitment to the parent (SHA-256 over the full compact parent receipt), and a signed lineage of ancestor DIDs. Offline chain verification checks signatures, linkage, depth, scope and ceiling subsumption, and expiry ordering. Receipt payloads are decoded as strict JSON: duplicate member names and integers outside the exact range of an IEEE 754 binary64 are rejected. * Revocation (Section 7): per-agent and per-connection revocation endpoints. Before minting a child, the server checks the revocation status of every ancestor named in the parent's signed lineage. * Audit: an audit log of delegation, exercise, and revocation events. Not implemented, or implemented differently: * Token exchange: delegation and sub-delegation use custom endpoints, not [RFC8693] token exchange. * Proof of possession: no DPoP. Agents prove key possession with signed payloads and HTTP Message Signatures [RFC9421]. * Capabilities: scope strings plus constraints, not [RFC9396] authorization_details. * Agent authentication: opaque bearer tokens plus signed payloads, not an [RFC7523] assertion. * Consent: a consent URL the user opens and the agent polls, not CIBA [OIDC-CIBA]. * Token claims: receipts name the agent in both sub and client_id; the delegating principal is not yet in sub, and there is no act or prf claim. Moving the principal into sub is planned for the next wire version. * Revocation interface and timing: no DELETE /delegation/{jti} endpoint or revoked_count, and the 1-second and 5-second bounds in Section 7 are not measured by tests. Sweeney Expires 16 April 2027 [Page 23] Internet-Draft Credential Delegation for AI Agents October 2026 Conformance results. The SDK's chain validation and sub-delegation checks were run against the twenty interop vectors published with [ASOR] (attenu-guard v0.9.0) and against four scope-class vectors proposed to that draft's author for its next revision. At commit 09f9488, all twenty and all four pass; four of the twenty pass with a rejection reason that the runner maps to the vector's reason name. The runner, vectors, and pinned results are at https://github.com/ cred-ninja/protocol/tree/main/conformance/asor-delegation-chain. These vectors are chains of HS256 tokens in the [ASOR] format; the runner checks their signatures and parent hashes itself and maps their claims onto the SDK's hop model. They exercise the scope grammar, constraint subsumption, depth, linkage, expiry ordering, and strict JSON decoding that this document shares with [ASOR]. They do not test any token, receipt, or request format defined in this document. 10. Security Considerations 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. Sweeney Expires 16 April 2027 [Page 24] Internet-Draft Credential Delegation for AI Agents October 2026 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 specific request, preventing re-use across operations. 10.4. Prompt Injection Containment Because credentials never reach the agent host, a successful prompt injection attack cannot exfiltrate credentials. 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. 10.7. Model Identity and Substitution The agent_model and agent_checksum claims are 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. 11. IANA Considerations This document requests registration of: * cred_delegation as an authorization_details type in the OAuth Authorization Server Metadata registry (per [RFC9396]) * agent_model, agent_operator, consent_id, credential_handle, prf as JWT claim names in the JSON Web Token Claims registry Sweeney Expires 16 April 2027 [Page 25] Internet-Draft Credential Delegation for AI Agents October 2026 * urn:ietf:params:oauth:grant-type:cred-delegation as a URI in the OAuth Parameters registry 12. References 12.1. Normative References [DID-CORE] Sporny, M., Longley, D., and D. Chadwick, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022, . [DID-KEY] Longley, D., "The did:key Method v0.7", W3C CCG Draft, . [OIDC-CIBA] OpenID Foundation, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", September 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . Sweeney Expires 16 April 2027 [Page 26] Internet-Draft Credential Delegation for AI Agents October 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [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, . 12.2. Informative References [AAT] Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, draft-niyikiza- oauth-attenuating-agent-tokens-01, June 2026, . [AGENTIC-JWT] Goswami, A., "Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management", Work in Progress, draft-goswami-agentic-jwt-01, July 2026, . [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, . [ASOR] Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, draft-asor-wimse-agent- delegation-chain-01, September 2026, . [ASYNC-DELEG] Zhu, L., "Delegated Refresh Tokens for OAuth 2.0 Token Exchange", Work in Progress, draft-zhu-oauth-async- delegation-05, August 2026, . [CB4A] Hartman, K., "Credential Broker for Agents (CB4A)", Work in Progress (expired), draft-hartman-credential-broker-4- agents-00, March 2026, . Sweeney Expires 16 April 2027 [Page 27] Internet-Draft Credential Delegation for AI Agents October 2026 [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, . [DELEG-RECEIPTS] Nelson, R., "Agent Delegation Receipts", Work in Progress, draft-nelson-agent-delegation-receipts-13, October 2026, . [DELEGATE-SD-JWT] Oliver, G., "Delegate SD-JWT", Work in Progress, draft- gco-oauth-delegate-sd-jwt-00, April 2026, . [ECT] Nennemann, C., "Execution Context Tokens for Distributed Agentic Workflows", Work in Progress (expired), draft- nennemann-wimse-ect-00, February 2026, . [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, . [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, . Sweeney Expires 16 April 2027 [Page 28] Internet-Draft Credential Delegation for AI Agents October 2026 [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, . [OAUTH-SPLICING] OAuth Working Group mailing list, "Security Consideration: Delegation Chain Splicing in RFC 8693 Token Exchange", February 2026, . [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, . [OWASP-AGENTIC] OWASP, "Top 10 for Agentic Applications v1.0", December 2025, . [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, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [TXN-AGENTS] Raut, A., "Transaction Tokens For Agents", Work in Progress, draft-araut-oauth-transaction-tokens-for-agents- 02, May 2026, . [UCAN-SPEC] Zelenka, B., "UCAN Delegation", RC v1.0, . [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, . Sweeney Expires 16 April 2027 [Page 29] Internet-Draft Credential Delegation for AI Agents October 2026 [WIMSE-AGENT] Ni, Y. and P. Liu, "WIMSE Applicability for AI Agents", Work in Progress, draft-ni-wimse-ai-agent-identity-03, October 2026, . [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, . [WIMSE-CRED-X] Schwenkschuster, A., "WIMSE Credential Exchange", Work in Progress (expired), draft-schwenkschuster-wimse- credential-exchange-03, October 2025, . [WIMSE-WPT] IETF WIMSE Working Group, "WIMSE Workload Proof Token", Work in Progress, draft-ietf-wimse-wpt-02, August 2026, . Changes from -00 * Workload Authorization Grant composition (Section 4.4): WAG- provisioned workloads authenticate per Section 4.2; act.sub stays the Agent DID; WAG identity travels as receipt identity evidence or as act iss and sub; WAG bearer status noted, proof of possession comes from the Delegation Token's DPoP binding. * Delegation Token adds client_id naming the acting agent per [RFC9068] and [AIMS] Section 10.3, which MUST agree with act.sub. * New Section 5.3: the constraints claim adopts the [ASOR] Section 4.2 vocabulary (max, min, one_of, not_one_of, prefix, rank) and Section 4.3 subsumption, fail-closed parsing, inherit- on-omit, and the rank-label ordering rule. Numeric ceilings leave the capability object. Lifetime aggregates stay DS-debited. Sweeney Expires 16 April 2027 [Page 30] Internet-Draft Credential Delegation for AI Agents October 2026 * Section 5.4: per-hop re-verification of authority and freshness; monotonic narrowing stated as containment plus order-independent intersection; root subject preserved in sub, current actor in act.sub, prior actors as nested act for attribution only; actor attribution attested per hop with its as-of time; receipt content adds the root subject and identity evidence; a SHOULD-level per- hop audit record distinct from the receipt; sub-delegation subset rule reads equal or narrower. * Related Work: [ASOR] added; AIMS and WAG references refreshed; Delegate SD-JWT paragraph notes the adoption call and the chain rules it leaves to this layer. * New Section 9 per [RFC7942]: what the open source SDK implements and does not, and what the [ASOR] interop vector results do and do not cover. * Related Work and references refreshed against Datatracker on 2026-10-13: identity chaining is in the RFC Editor queue at -17; the Delegate SD-JWT adoption call has closed, result pending; newer revisions of the Nelson, Reece, Zhu, Raut, Ni, Goswami, and WPT drafts; CB4A and ECT noted as expired. * References: [RFC9068] normative; [ASOR], [RFC7942], and [RFC9421] informative. Acknowledgments The design of this protocol draws on UCAN attenuation semantics [UCAN-SPEC], the object-capability literature, and ongoing work in the IETF WIMSE and OAuth working groups. Threat modeling was informed by [OWASP-AGENTIC] and [NIST-AGENT-ID]. Rafael Asor's delegation chain draft supplied the constraint vocabulary adopted in -01; Iman Schrock found the defect in the first scope-class proposal; Wes Jackson supplied the per-hop attestation framing in Section 5.4. Author's Address Kieran Sweeney Email: kieran@kierans.net Sweeney Expires 16 April 2027 [Page 31]