Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange

3.1. Single-Actor Semantics

[[RFC8693]] Section 4.1 defines the act claim as a JSON object identifying the current actor. While nesting is permitted to represent prior actors, the specification explicitly limits their utility. Only the outermost act claim—representing the current actor—is relevant for access control. All prior actors exist solely for informational purposes.¶

This design was appropriate for traditional web service delegation where chains are short (typically one or two hops) and the identity of the immediate caller is sufficient for authorization. It is insufficient for the emerging class of workloads described below.¶

3.2. AI Agent Delegation Chains

Modern AI systems increasingly operate as networks of specialized agents. A typical interaction may involve:¶

User -> Orchestrator Agent -> Planning Agent -> Tool Agent -> Data API

At each hop, the agent performs a token exchange ([[RFC8693]]) to obtain credentials appropriate for calling the next service. Under current [[RFC8693]] semantics, by the time the request reaches the Data API, only the Tool Agent is identified as the actor. The Orchestrator Agent and Planning Agent—which may have been manipulated via prompt injection into delegating authority they should not have—are invisible to policy enforcement.¶

This creates several concrete risks:¶

• Lateral Movement: A compromised agent deep in the chain can impersonate the authority of the originating actor without any cryptographic evidence of the actual delegation path.¶
• Policy Bypass: Fine-grained policies like "only allow data access when the orchestrator is a known, trusted entity" cannot be expressed because the orchestrator's identity is not available for policy evaluation at the data plane.¶
• Audit Gaps: Post-incident forensic analysis cannot reliably reconstruct the delegation path because the nested act claims are self-reported and unsigned.¶

3.3. Structural Limitations of Nested act

Beyond the semantic restriction, the nested object structure of act in [[RFC8693]] has practical limitations:¶

1. Parsing Complexity: Each prior actor requires traversing one additional level of JSON nesting. In high-throughput data-plane proxies (e.g., Envoy, Istio sidecars), deep nesting imposes parsing overhead.¶
2. Indexing: It is not possible to efficiently query "the actor at position N" without recursively unwinding the nested structure.¶
3. Size Predictability: The depth of nesting is unbounded, making it difficult to predict token sizes and allocate parsing buffers.¶
4. No Integrity: Each nested act is a plain JSON object with no signature or hash binding. Any intermediary could insert, remove, or reorder prior actors without detection.¶

4.1. Overview

This document defines a new claim, actor_chain, that provides a Cryptographically Verifiable Actor Chain. When used in a JWT, its value is a JSON array of Actor Chain Entries. When used in a CWT, its value is a CBOR array of Actor Chain Entries. The array is ordered chronologically: index 0 represents the originating actor, and the last index represents the current actor.¶

The actor_chain claim supports two operational modes:¶

1. AS-Attested Mode: The Authorization Server (AS) validates each actor at token exchange time and constructs the actor_chain. The AS's signature over the entire token (JWS or COSE) provides integrity protection for the chain. Per-actor chain_sig fields are omitted.¶

2. Self-Attested Mode: Each Actor Chain Entry additionally includes a chain_sig field: a cryptographic signature (compact JWS [[RFC7515]] or COSE_Sign1 [[RFC9052]]) computed by that actor over a Chain Digest of all preceding entries. This creates a hash-chain structure providing tamper evidence and non-repudiation independent of the AS.¶

4.2. Claim Definition

The actor_chain claim is a JSON array. Each element of the array is a JSON object (an Actor Chain Entry) with the following members. To support diverse privacy requirements, Selective Disclosure (SD-JWT) is configurable at two levels of granularity: - Per-Actor: An Authorization Server MAY choose to hide entire Actor Chain Entries or only specific actors in the chain. - Per-Field: Within a single Actor Chain Entry, a subset of members (e.g., sub) MAY be hidden using an _sd claim while others (e.g., iat or por) remain in cleartext. These fields typically correspond to the identity claims present in the Actor Token or client credentials used during the token exchange flow.¶

sub:

REQUIRED (or selectively disclosed). A string identifying the actor, as defined in [[RFC7519]] Section 4.1.2.¶

iss:

REQUIRED (or selectively disclosed). A string identifying the issuer of the actor's identity, as defined in [[RFC7519]] Section 4.1.1.¶

iat:

REQUIRED (or selectively disclosed). The time at which this actor was appended to the chain, represented as a NumericDate as defined in [[RFC7519]] Section 4.1.6.¶

por:

OPTIONAL. A JSON object containing a Proof of Residency binding this actor to a verified execution environment. The structure of this object is defined in [[!I-D.draft-mw-spice-transitive-attestation]].¶

chain_digest:

OPTIONAL. A Base64url-encoded cumulative cryptographic hash (SHA-256). For any entry at index N, the hash is computed over the canonical serialization of the union of the current entry's identity claims (e.g., sub, iss, iat, _sd hashes) and the chain_digest of the preceding entry (index N-1). For the entry at index 0, the hash is computed over its identity claims alone. This recursive structure ensures that a chain_sig at any point in the chain provides proof of participation for all prior actors. REQUIRED in Self-Attested Mode. MUST be omitted in AS-Attested Mode.¶

[!IMPORTANT] When Selective Disclosure is used, the SD-JWT Disclosure strings (the cleartext salts/values) MUST NOT be included in the canonical serialization used for hashing. The chain_digest is computed exclusively over the Actor Chain Entry object, which contains the stable _sd hashes. This ensures the signature remains valid regardless of which disclosures are subsequently provided to different recipients.¶

chain_sig:

OPTIONAL. A compact JWS [[RFC7515]] signature produced by this actor's private key over the chain_digest value. The JWS header MUST include the jwk or kid member to identify the signing key. REQUIRED in Self-Attested Mode. MUST be omitted in AS-Attested Mode.¶

chain_mode:

OPTIONAL. A top-level string claim (sibling to actor_chain) indicating the operational mode. Values are as_attested or self_attested. If omitted, the mode is inferred from the presence or absence of chain_sig fields in the Actor Chain Entries.¶

4.3. Example Tokens

{
  "aud": "https://data-api.example.com",
  "iss": "https://auth.example.com",
  "exp": 1700000100,
  "nbf": 1700000000,
  "sub": "user@example.com",
  "actor_chain": [
    {
      "sub": "https://orchestrator.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000010,
      "por": {
        "wia_kid": "spiffe://example.com/wia/node-1",
        "env_hash": "sha256:abc123..."
      }
    },
    {
      "sub": "https://planner.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000030
    },
    {
      "sub": "https://tool-agent.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000050,
      "por": {
        "wia_kid": "spiffe://example.com/wia/node-3",
        "env_hash": "sha256:ghi789..."
      }
    }
  ]
}

{
  "aud": "https://data-api.example.com",
  "iss": "https://auth.example.com",
  "exp": 1700000100,
  "nbf": 1700000000,
  "sub": "user@example.com",
  "actor_chain": [
    {
      "sub": "https://orchestrator.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000010,
      "por": {
        "wia_kid": "spiffe://example.com/wia/node-1",
        "env_hash": "sha256:abc123..."
      },
      "chain_digest": "sha256:mno345...",
      "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
    },
    {
      "sub": "https://planner.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000030,
      "chain_digest": "sha256:def456...",
      "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
    },
    {
      "sub": "https://tool-agent.example.com",
      "iss": "https://auth.example.com",
      "iat": 1700000050,
      "por": {
        "wia_kid": "spiffe://example.com/wia/node-3",
        "env_hash": "sha256:ghi789..."
      },
      "chain_digest": "sha256:jkl012...",
      "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
    }
  ]
}

4.4. Token Exchange Flow

When an actor (Service B) receives a token containing an actor_chain and needs to call a downstream service (Service C), the following token exchange flow occurs:¶

1. Service B sends a token exchange request to the Authorization Server (AS) per [[RFC8693]] Section 2.1.¶
2. The subject_token contains the existing actor_chain.¶
3. The actor_token identifies Service B.¶

4. The AS validates the existing actor_chain:¶

   • In Self-Attested Mode: verifies each chain_sig against the corresponding actor's public key and each chain_digest against the hash of preceding entries.¶
   • In AS-Attested Mode: verifies the JWT signature and validates the actor identities through its own policy (e.g., client registration, mTLS certificate).¶
   • In both modes: enforces any max_chain_depth policy.¶

5. The AS constructs a new actor_chain for the issued token by:¶

   • Copying all existing Actor Chain Entries from the subject_token.¶
   • Appending a new Actor Chain Entry for Service B.¶
   • In Self-Attested Mode: the new entry's chain_digest is computed over all preceding entries, and its chain_sig is produced by Service B's key (provided via the actor_token or client credentials).¶
   • In AS-Attested Mode: the new entry contains only the identity claims (sub, iss, iat) and optional por.¶
6. The AS issues a new token with the extended actor_chain.¶

  Svc A        Auth Server        Svc B        Svc C
    |               |               |             |
    |-- token ------>|               |             |
    |  (chain=[A])   |               |             |
    |               |-- issued tok ->|             |
    |               |  (chain=[A])   |             |
    |               |               |             |
    |               |<- exchange req-|             |
    |               |  subj_tok:     |             |
    |               |   chain=[A]    |             |
    |               |  actor_tok=B   |             |
    |               |               |             |
    |               |-- issued tok ->|             |
    |               |  (chain=[A,B]) |             |
    |               |               |             |
    |               |               |-- request ->|
    |               |               | token has   |
    |               |               | chain=[A,B] |

4.5. Data-Plane Policy Enforcement

Unlike the nested act claim in [[RFC8693]], the actor_chain claim is explicitly designed to be used in access control decisions. Resource Servers and data-plane proxies MAY apply authorization policies based on any entry in the actor chain.¶

actor_chain[0].sub == "https://orchestrator.example.com"

for_all(entry in actor_chain):
  entry.iss in ["https://auth.example.com",
                 "https://auth.partner.com"]

len(actor_chain) <= 5

for_all(entry in actor_chain):
  entry.por is present AND entry.por is valid

actor_chain[0].sub == "https://orchestrator.example.com" AND
actor_chain[1].sub == "https://planner.example.com"

6.1. East-West vs. North-South Security

This specification addresses the East-West axis of agent-to-agent communication, providing a cryptographically verifiable trail of identity delegation across a network of services. In contrast, Transitive Attestation [[!I-D.draft-mw-spice-transitive-attestation]] addresses the North-South axis of an agent's relationship with its local hosting environment (e.g., a Workload Identity Agent on a TEE-enabled node).¶

By embedding "North-South" Proofs of Residency (PoR) within "East-West" Actor Chain Entries, a Relying Party gains end-to-end assurance that every entity in a global delegation chain is both a recognized identity and is executing within a verified, secure environment.¶

6.2. Backward Compatibility with RFC 8693

An Authorization Server implementing this extension SHOULD populate both the act claim (per [[RFC8693]] Section 4.1) and the actor_chain claim in issued tokens. This ensures that:¶

• Legacy consumers that understand only act continue to function correctly, seeing the current actor in the top-level act claim.¶
• Chain-aware consumers can use actor_chain for fine-grained policy enforcement and audit.¶

The act claim, when present alongside actor_chain, MUST identify the same entity as the last entry in the actor_chain array.¶

7.1. Token Signature vs. Per-Entry Chain Signatures

A natural question arises: since the JWT containing the actor_chain is already signed by the Authorization Server (AS), is per-entry chain_sig redundant?¶

The answer depends on what each signature proves and when it is produced:¶

• The JWT outer signature is produced by the AS when the final token is issued. It proves that the AS issued this specific token with this specific payload. It covers the entire token: sub, aud, exp, actor_chain, and all other claims.¶
• Each chain_sig is produced by an individual actor during token exchange, before the final token exists (see Section "When Chain Signatures Are Produced"). It covers only the chain_digest—the hash of the actor chain state at that actor's point of participation. It proves that this specific actor participated in this specific chain.¶

The JWT outer signature does NOT prove that each individual actor actually participated in the delegation. A compromised or malicious AS could construct any chain it desires. The two modes address different trust assumptions:¶

• AS-Attested Mode is appropriate when all participants trust the AS to faithfully record the chain. The AS validates each actor at exchange time, and its JWT signature provides integrity. This is the common single-organization deployment where the AS is a trusted internal service (e.g., a corporate identity provider). Per-actor signatures are omitted, keeping token sizes smaller and reducing cryptographic overhead.¶

• Self-Attested Mode is appropriate when the chain crosses trust boundaries or when stronger guarantees are needed:¶

  • Federated/Multi-AS environments: The token may be issued by AS-1 but consumed by a Relying Party that trusts AS-2. Per-actor signatures allow the RP to verify actor participation independently of the issuing AS.¶
  • Non-repudiation: Each actor's signature provides cryptographic evidence that it participated in the chain—evidence that the actor cannot deny and that the AS cannot fabricate.¶
  • Zero-trust posture: In adversarial environments, the Relying Party may not fully trust any single AS. Per-actor signatures provide defense-in-depth.¶
  • Forensic analysis: Post-breach investigations can verify the chain using each actor's public key, independent of the AS's continued availability or trustworthiness.¶

Deployments SHOULD select the mode that matches their trust model. An AS MAY enforce a specific mode via policy.¶

7.2. Chain Integrity

In AS-Attested Mode, chain integrity is provided by the JWT outer signature. The Relying Party trusts the AS to have correctly constructed the chain.¶

In Self-Attested Mode, the hash-chain structure provides additional tamper evidence. Insertion, deletion, or reordering of entries invalidates the chain_digest and chain_sig fields of all subsequent entries. An attacker who compromises a single actor in the chain cannot retroactively alter the entries of prior actors without possessing their signing keys.¶

7.3. Replay Protection

Each Actor Chain Entry includes an iat (issued-at) timestamp. Relying Parties SHOULD enforce a maximum age on Actor Chain Entries to prevent replay of stale chains. Additionally, the standard JWT claims exp and nbf on the enclosing token provide overall token-level freshness.¶

7.4. Chain Depth Limits

Unbounded actor chains pose a risk of token size explosion and processing overhead. Authorization Servers SHOULD enforce a configurable maximum chain depth (max_chain_depth). A RECOMMENDED default maximum is 10 entries. Relying Parties MAY independently enforce their own chain depth limits.¶

7.5. Key Management

Each actor in the chain signs its entry with its own key. The security of the entire chain depends on the security of each actor's key material. Actors SHOULD use short-lived keys and/or hardware-protected keys (e.g., via the PoR mechanism). The use of PoR in Actor Chain Entries provides additional assurance that the signing key is bound to a verified execution environment.¶

7.6. Privacy of Prior Actors

The actor_chain expose the identities of all actors in the delegation path to every Relying Party that receives the token. While this is necessary for certain audit and policy requirements, it may conflict with privacy goals. For example, in a chain a -> b -> c -> d -> e, the originating actor a may require its identity to be hidden from e while still ensuring the integrity of the delegation.¶

Deployments SHOULD consider the following anonymization and privacy-preserving techniques:¶

7.7. Confused Deputy Mitigation

In both modes, a confused deputy attack—where a legitimate actor is tricked into delegating to a malicious downstream—is detectable because the malicious downstream actor's identity appears in the chain, providing forensic evidence of the attack path. In Self-Attested Mode, the malicious actor's own cryptographic signature provides non-repudiable evidence of its participation.¶

8.1. JSON Web Token Claims Registration

This document requests registration of the following claim in the "JSON Web Token Claims" registry established by [[RFC7519]]:¶

• Claim Name: actor_chain¶
• Claim Description: A Cryptographically Verifiable Actor Chain — an ordered array of actor entries representing the complete delegation chain with optional per-entry cryptographic signatures.¶
• Change Controller: IETF¶
• Specification Document(s): [this document]¶

8.2. CBOR Web Token Claims Registration

This document requests registration of the following claim in the "CBOR Web Token (CWT) Claims" registry established by [[RFC8392]]:¶

• Claim Name: actor_chain¶
• Claim Description: A Cryptographically Verifiable Actor Chain.¶
• CBOR Key: TBD (e.g., 40)¶
• Claim Type: array¶
• Change Controller: IETF¶
• Specification Document(s): [this document]¶