Chain Delegation for OAuth 2.0 Access Tokens

1.1. Requirements Language

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

3.1. Claim Definition

Claim Name:

delegation_chain¶

Claim Type:

Array of Objects¶

Usage:

Access tokens (JWT format)¶

Specification:

RFC 7519 (JWT)¶

3.2. Structure

The delegation_chain is an ordered array of delegation records, from most recent to earliest. Each record represents one delegation hop.¶

{
  "delegation_chain": [
    {
      "delegator_wit": "wit://agent-a.example",
      "delegatee_wit": "wit://agent-b.example",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow {\n  input.action == \"inventory_check\"\n  input.item_id == \"123\"\n}",
        "entry_point": "allow"
      },
      "operation_summary": "Delegate inventory check for item 123",
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "as_signature": "eyJhbGciOiJSUzI1NiIs..."
    }
  ]
}

3.3. Delegation Lifecycle

A delegation record transitions through three phases during its lifecycle:¶

1. Delegation Proposal Phase: The delegating agent creates a delegation proposal that includes the delegated policy, delegatee identity, and operation context. This phase corresponds to the policy creation process defined in [I-D.ietf-oauth-rego-policy].¶
2. Delegation Enforcement Phase: The Authorization Server validates the delegation request, verifies user identity (using id_token_hint as defined in [I-D.ietf-oauth-cross-domain-id-token-hint] for the first delegation), and signs the delegation record upon successful validation.¶
3. Chain Propagation Phase: The signed delegation record is embedded into an access token's delegation_chain claim, enabling multi-hop propagation across trust domains.¶

This three-phase model ensures cryptographic binding between user authorization, agent identity, and policy constraints throughout the delegation chain.¶

3.4. Field Definitions

Both as_signature and delegator_signature MUST be computed over the same set of fields using JSON Canonicalization Scheme (JCS) as defined in RFC 8785:¶

• delegator_wit¶
• delegatee_sub¶
• delegation_timestamp¶
• delegated_policy (if present)¶
• operation_summary (if present)¶
• root_evidence_ref (if present)¶

Both signature fields MUST be excluded from their respective signature computations. The signatures MUST use detached JWS format with appropriate algorithm identifiers.¶

The delegator_signature uses the delegating agent's WIT-bound private key, while as_signature uses the Authorization Server's signing key. This dual-signature approach ensures:¶

• Malicious AS Prevention: A compromised AS cannot unilaterally forge delegations without the delegator's consent;¶
• Non-Repudiation: The delegator cannot deny having authorized the delegation;¶
• Complete Trust Chain: User → AS → Delegator → Delegatee.¶

3.5. Chain Ordering

The array MUST be ordered from most recent delegation to earliest:¶

• Index 0: Most recent delegation (delegator → current token holder)¶
• Index N: Earliest delegation (first agent after human authorization)¶

This ordering allows efficient validation starting from the immediate delegator.¶

4.1. Step 1-4: Initial Authorization

Agent A obtains authorization from the user through a standard OAuth flow. The resulting token does not contain a delegation_chain (it is the root authorization).¶

4.2. Step 5: Delegation Request (PAR)

Agent A initiates delegation using Pushed Authorization Request (PAR) with JWT Secured Authorization Request [RFC9126]. The delegation parameters are encoded in a JWT, providing integrity protection and supporting large payloads.¶

POST /par HTTP/1.1
Host: as.example.com
Content-Type: application/oauth-authz-req+jwt
OAuth-Client-Attestation: wit://agent-b.example
OAuth-Client-Attestation-PoP: <PoP-Signature>

eyJhbGciOiJFUzI1NiIsImtpZCI6ImFnZW50LWEta2V5In0.ewogICJpc3MiOiAid2l0Oi8vdHBtMi5udmlkaWEuc2hhMjU2LmFiYzEyMy4uLiIsCiAgImF1ZCI6ICJodHRwczovL2FzLmV4YW1wbGUuY29tIiwKICAicmVzcG9uc2VfdHlwZSI6ICJjb2RlIiwKICAiZ3JhbnRfdHlwZSI6ICJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTp0b2tlbi1leGNoYW5nZSIsCiAgInN1YmplY3RfdG9rZW4iOiAiPGFnZW50LWEtdG9rZW4-IiwKICAic3ViamVjdF90b2tlbl90eXBlIjogInVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tlbi10eXBlOmFjY2Vzc190b2tlbiIsCiAgInJlcXVlc3RlZF90b2tlbl90eXBlIjogInVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tlbi10eXBlOmFjY2Vzc190b2tlbiIsCiAgInNjb3BlIjogImNhcnQ6cmVhZCIsCiAgImRlbGVnYXRpb25fcmVhc29uIjogIkludmVudG9yeSBjaGVjayBmb3IgaXRlbSBYIiwKICAiZGVsZWdhdGVlX3dpdCI6ICJ3aXQ6Ly9zZ3guaW50ZWwuc2hhMjU2LmRlZjQ1Ni4uLiIKfQ.signature

The JWT payload (decoded) contains:¶

{
  "iss": "wit://agent-a.example",
  "aud": "https://as.example.com",
  "response_type": "code",
  "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
  "subject_token": "<agent-a-token>",
  "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "delegated_policy": {
    "type": "rego",
    "content": "package agent\ndefault allow = false\n\nallow {\n  input.action == \"inventory_check\"\n  input.item_id == \"123\"\n}",
    "entry_point": "allow"
  }
  "delegatee_wit": "wit://agent-b.example"
}

4.3. Step 6: AS Validation

The AS MUST perform the following validations:¶

1. Token Validity: Verify Agent A's token is valid and not revoked.¶
2. Delegation Permission: Confirm the token permits delegation (e.g., includes a delegation scope or flag).¶
3. Scope Subset: Verify the requested scope is a strict subset of Agent A's authorized scope.¶
4. Delegatee Authentication: Validate Agent B's credentials (WIT-SVID).¶
5. Chain Depth: Optionally enforce maximum delegation depth.¶

4.4. Step 7: Token Issuance

Upon successful validation, the AS issues a new token for Agent B with:¶

• sub: The original user (unchanged)¶
• act: Agent B's identity¶
• delegation_chain: Extended with a new record for this hop¶
• Reduced scope (as requested)¶

5.1. For First Delegation

If Agent A's token has no delegation_chain (root authorization), the AS creates a new chain with one entry:¶

{
  "delegation_chain": [
    {
      "delegator_wit": "wit://agent-a.example",
      "delegatee_wit": "wit://agent-b.example",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow {\n  input.action == \"cart_op\"\n}",
        "entry_point": "allow"
      },
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Delegate cart operations",
      "as_signature": "eyJhbGciOiJSUzI1NiIs..."
    }
  ]
}

5.2. For Subsequent Delegations

If Agent B further delegates to Agent C, the AS prepends a new record:¶

{
  "delegation_chain": [
    {
      "delegator_wit": "wit://agent-b.example",
      "delegatee_wit": "wit://agent-c.example",
      "delegation_timestamp": 1734517800,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow {\n  input.action == \"inventory_check\"\n  input.item_id == \"123\"\n}",
        "entry_point": "allow"
      },
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Check inventory for item 123",
      "delegator_signature": "eyJhbGciOiJFUzI1NiIs...",
      "operation_summary": "Check inventory for item 123",
      "as_signature": "eyJhbGciOiJSUzI1NiIs..."
    },
    {
      "delegator_wit": "wit://agent-a.example",
      "delegatee_wit": "wit://agent-b.example",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow {\n  input.action == \"cart_op\"\n}",
        "entry_point": "allow"
      },
      "as_signature": "eyJhbGciOiJSUzI1NiIs..."
    }
  ]
}

6.1. Signature Verification

For each record in the chain, verify the as_signature using the AS's public key. This ensures:¶

• The delegation was authorized by the AS;¶
• The record has not been tampered with;¶
• The delegation metadata is authentic.¶

6.2. Root Authorization Anchor

The last record in the chain (highest index) represents the earliest delegation. Its delegator_wit identifies the agent that holds the root authorization (the token directly authorized by the user).¶

The Resource Server MUST verify that:¶

• root token (a token without a delegation_chain claim);¶
• This root token was issued by a trusted AS and has not been revoked.¶
• The root token contains valid evidence and audit_trail claims as defined in the authorization evidence draft, providing cryptographic proof of user consent.¶

If the RS cannot verify the root authorization anchor, it MUST reject the request.¶

6.3. Dual-Signature Verification

For each delegation record, the Resource Server SHOULD verify both:¶

• AS Signature: Using the Authorization Server's public key, confirming the delegation was authorized by the AS;¶
• Delegator Signature: Using the delegating agent's WIT-bound public key, confirming the delegator explicitly consented to this delegation.¶

The dual-signature mechanism prevents:¶

• Malicious AS from unilaterally forging delegations;¶
• Delegators from denying authorized delegations (non-repudiation);¶
• Unauthorized privilege escalation through compromised components.¶

6.4. WIT Status Validation

The Resource Server SHOULD verify the current status of all Workload Identity Tokens (WITs) referenced in the delegation_chain by:¶

• Checking WIT revocation lists or status endpoints;¶
• Validating WIT expiration timestamps;¶
• Querying the issuing Identity Provider for current status.¶

If any WIT in the chain has been revoked or expired, the entire delegation_chain MUST be considered invalid, even if individual records remain cryptographically valid.¶

6.5. Chain Continuity

Verify the chain is continuous:¶

• Each delegatee_wit matches the delegator_wit of the previous (more recent) record;¶
• The final delegatee_sub matches the token's act.sub;¶
• Timestamps are in descending order.¶

6.6. Scope Validation

Verify scope constraints are progressively narrowing:¶

• Each delegation's delegated_policy MUST be equal to or more restrictive than the previous delegation's scope;¶
• The final scope MUST cover the requested operation.¶

7.1. Privilege Escalation Prevention

The AS MUST ensure that delegation cannot expand privileges:¶

• Delegated scope MUST be a strict subset of delegator's scope;¶
• Delegation depth MAY be limited;¶
• Certain scopes MAY be marked non-delegatable.¶

7.2. Chain Integrity

The as_signature on each record ensures chain integrity. Agents MUST NOT be able to:¶

• Forge delegation records;¶
• Modify existing records;¶
• Remove records from the chain;¶
• Reorder records.¶

7.3. Token Binding

This enables:¶

• Revocation of specific delegation paths;¶
• Audit trail reconstruction;¶
• Detection of token reuse.¶

7.4. Delegation Depth Limits

Implementations SHOULD enforce maximum delegation depth to:¶

• Prevent unbounded delegation chains;¶
• Limit token size growth;¶
• Simplify validation.¶

A RECOMMENDED default maximum depth is 5 hops.¶

8.1. JWT Claims Registration

This specification registers the following claim in the "JSON Web Token Claims" registry:¶

Claim Name:

delegation_chain¶

Claim Description:

An ordered array of AS-signed delegation records tracing agent-to-agent authorization transfers, enabling end-to-end validation of delegation lineage.¶

Change Controller:

IETF¶

Specification Document:

Section 3 of this document¶

B.1. Token Structure

For each delegation from Agent-X to Agent-Y:¶

• The token's "iss" claim MUST be the WIT of the delegating agent¶
• The token's "sub" claim MUST be the WIT of the delegatee agent¶
• The token MUST be signed by the delegating agent's private key¶
• The token's "delegation_chain" claim accumulates all previous hops¶

B.2. Verification Requirements

Resource Servers MUST validate:¶

1. The final token's signature matches the claimed issuer¶
2. Each hop in the delegation_chain has valid timestamps¶
3. Policy constraints are maintained or reduced (never expanded)¶
4. The chain is continuous (each "to" matches next "from")¶
5. The initial delegator matches the original authorization subject¶

B.3. Security Considerations

This per-hop signing approach provides:¶

• Non-repudiation: Each delegator's signature is independent evidence¶
• Flexible revocation: Individual hops can be revoked separately¶
• Incremental updates: New hops only require generating new tokens¶
• Audit-friendly: Each signature represents a discrete authorization event¶

B.4. Comparison with OAuth Identity Chaining

While [I-D.ietf-oauth-identity-chaining] focuses on static identity federation across organizational boundaries, this specification targets dynamic AI agent delegation with the following distinctions:¶

• Trust Model: Attestation-based (WIT) vs. pre-configured PKI trust¶
• Scope Control: Mandatory contraction vs. static mapping¶
• Time Scale: Task-level (minutes/hours) vs. employment-level (months/years)¶
• Target: AI workloads vs. human employees¶

This makes the mechanism suitable for AI-to-AI scenarios where agents need temporary, auditable delegation without pre-established trust relationships. Implementations MAY use WIT with attestation evidence for enhanced security, but it is not required by this specification.¶