Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange
draft-mw-spice-actor-chain-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | A Prasad , Ramki Krishnan , Diego Lopez , Srinivasa Addepalli | ||
| Last updated | 2026-02-25 | ||
| Replaced by | draft-mw-oauth-actor-chain | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mw-spice-actor-chain-00
SPICE A. Prasad
Internet-Draft Oracle
Intended status: Informational R. Krishnan
Expires: 29 August 2026 JPMorgan Chase & Co
D. Lopez
Telefonica
S. Addepalli
Aryaka
25 February 2026
Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange
draft-mw-spice-actor-chain-00
Abstract
This document defines an extension to OAuth 2.0 Token Exchange
[[RFC8693]] that addresses the problem of *Delegation Auditability
Gaps* in multi-hop service environments. Current standards treat
prior actors in a delegation chain as "informational only," providing
no cryptographic proof of the actual delegation path. This document
proposes a new actor_chain claim — a *Cryptographically Verifiable
Actor Chain* — that replaces the informational-only nested act claim
with a tamper-evident, ordered record of all actors. This solution
enables high-assurance data-plane policy enforcement and forensic
auditability, particularly for dynamic AI agent-to-agent
workloads—where susceptibility to *prompt injection attacks* can lead
to unauthorized delegation paths — the security posture of the entire
delegation chain is critical for authorization decisions.
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 29 August 2026.
Prasad, et al. Expires 29 August 2026 [Page 1]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Problem: RFC 8693 Actor Limitations . . . . . . . . . . . 5
3.1. Single-Actor Semantics . . . . . . . . . . . . . . . . . 5
3.2. AI Agent Delegation Chains . . . . . . . . . . . . . . . 5
3.3. Structural Limitations of Nested act . . . . . . . . . . 5
3.3.1. Selective Disclosure (SD-JWT) . . . . . . . . . . . . 6
4. The Solution: The Cryptographically Verifiable actor_chain
Claim . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Claim Definition . . . . . . . . . . . . . . . . . . . . 6
4.3. Example Tokens . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. AS-Attested Mode . . . . . . . . . . . . . . . . . . 8
4.3.2. Self-Attested Mode . . . . . . . . . . . . . . . . . 9
4.4. Token Exchange Flow . . . . . . . . . . . . . . . . . . . 10
4.4.1. Disclosure Propagation in SD-JWT . . . . . . . . . . 11
4.4.2. When Chain Signatures Are Produced . . . . . . . . . 11
4.5. Data-Plane Policy Enforcement . . . . . . . . . . . . . . 12
4.5.1. Policy Examples . . . . . . . . . . . . . . . . . . . 13
4.5.2. Integration with Data-Plane Proxies . . . . . . . . . 13
5. Chain Integrity Verification . . . . . . . . . . . . . . . . 14
6. Relation to Other IETF Work . . . . . . . . . . . . . . . . . 14
6.1. East-West vs. North-South Security . . . . . . . . . . . 16
6.2. Backward Compatibility with RFC 8693 . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Token Signature vs. Per-Entry Chain Signatures . . . . . 16
7.2. Chain Integrity . . . . . . . . . . . . . . . . . . . . . 17
7.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 18
7.4. Chain Depth Limits . . . . . . . . . . . . . . . . . . . 18
7.5. Key Management . . . . . . . . . . . . . . . . . . . . . 18
7.6. Privacy of Prior Actors . . . . . . . . . . . . . . . . . 18
7.6.1. Pseudonymous Identifiers . . . . . . . . . . . . . . 19
Prasad, et al. Expires 29 August 2026 [Page 2]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
7.6.2. Selective Disclosure (SD-JWT) . . . . . . . . . . . . 19
7.6.3. Identity Bridging for Anonymity . . . . . . . . . . . 19
7.6.4. Targeted Selective Disclosure . . . . . . . . . . . . 19
7.6.5. Encryption (JWE) . . . . . . . . . . . . . . . . . . 20
7.7. Confused Deputy Mitigation . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. JSON Web Token Claims Registration . . . . . . . . . . . 20
8.2. CBOR Web Token Claims Registration . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document defines an extension to OAuth 2.0 Token Exchange
[[RFC8693]] to support high-assurance *East-West* identity delegation
through cryptographically verifiable actor chains.
In modern multi-service and AI-agent environments, a workload often
delegates its authority to another agent, which may in turn delegate
to others. While [[RFC8693]] provides the act (actor) claim to
represent delegation, it explicitly restricts prior actors in a
nested chain to be "informational only," excluding them from access
control considerations. This creates a significant *Delegation
Auditability Gap*: Resource Servers cannot verify the full path of
authority, and attackers can potentially hide lateral movement or
*prompt injection-induced hijacking* within unverified informational
claims.
By providing a standardized *Cryptographically Verifiable Actor
Chain*, this extension replaces the informal nested act structure
with a policy-enforceable, ordered, and tamper-evident record of all
participants. This establishes an *"East-West"* axis of
accountability, ensuring that any service in a global delegation
chain can be verified for identity, integrity, and (optionally)
physical residency.
This solution addresses several critical gaps in [[RFC8693]]:
1. *Cryptographic Audit Trail*: Proves that each prior actor
actually participated in the delegation chain and that the
sequence has not been tampered with.
2. *Data-Plane Policy Enforcement*: Enables Resource Servers to
write fine-grained authorization policies based on any actor in
the path (e.g., "originating actor must be X").
3. *Dynamic AI Agent Topologies*: Provides a scalable architecture
for the unpredictable and deep delegation chains common in
autonomous agent networks.
Prasad, et al. Expires 29 August 2026 [Page 3]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
4. *Data-Plane Efficiency*: Uses a flat, ordered array structure
optimized for high-throughput parsing and indexing in cloud-
native proxies (e.g., Envoy).
This extension is designed to be backward-compatible and format-
agnostic, supporting both JSON/JWS (JWT [[RFC7519]]) and CBOR/COSE
(CWT [[RFC8392]]) representations.
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.
This document leverages the terminology defined in OAuth 2.0 Token
Exchange [[RFC8693]], the SPICE Architecture [[!I-D.ietf-spice-
arch]], and the RATS Architecture [[RFC9334]].
Actor Chain: A Cryptographically Verifiable Actor Chain — an ordered
sequence of Actor Chain Entries representing the complete
delegation path from the originating actor to the current actor.
The chain is integrity-protected either by the AS's JWT signature
(AS-Attested Mode) or by per-actor cryptographic signatures (Self-
Attested Mode).
Actor Chain Entry: A JSON object or CBOR map identifying a single
actor in the delegation chain, including its identity claims and a
cryptographic signature binding it to the chain state at the point
of its participation.
Chain Digest: A cumulative cryptographic hash computed over the
delegation history. For any entry at index N, the chain_digest is
computed over the concatenation of the current entry's identity
claims and the chain_digest of the preceding entry (at index N-1).
For the entry at index 0, the digest is computed over that entry's
identity claims alone. Each actor produces a per-actor signature
over its chain_digest, cryptographically anchoring itself to the
entire preceding history.
Chain Depth: The total number of Actor Chain Entries in an actor
chain. Used by policy engines to enforce maximum delegation
depth.
Proof of Residency (PoR): A cryptographic proof (as defined in [[!I-
D.draft-mw-spice-transitive-attestation]]) binding a workload to a
specific, verified local environment. When present in an Actor
Chain Entry, it provides hardware-rooted assurance of the actor's
execution context.
Prasad, et al. Expires 29 August 2026 [Page 4]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
3. The Problem: RFC 8693 Actor Limitations
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:
Prasad, et al. Expires 29 August 2026 [Page 5]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
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.
3.3.1. Selective Disclosure (SD-JWT)
4. The Solution: The Cryptographically Verifiable actor_chain Claim
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
Prasad, et al. Expires 29 August 2026 [Page 6]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
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.
Prasad, et al. Expires 29 August 2026 [Page 7]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
4.3. Example Tokens
4.3.1. AS-Attested Mode
In this mode, the AS constructs the actor_chain array and the JWT's
own signature provides integrity. No per-entry chain_sig or
chain_digest fields are present. This is the simplest deployment
model.
{
"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..."
}
}
]
}
The integrity of the chain rests on the AS's JWT signature. The
Relying Party trusts the AS to have correctly validated each actor at
the time of each token exchange.
Prasad, et al. Expires 29 August 2026 [Page 8]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
4.3.2. Self-Attested Mode
In this mode, each Actor Chain Entry additionally carries a
chain_digest and chain_sig, forming a hash chain with per-actor non-
repudiation. This mode is appropriate for federated deployments,
multi-AS environments, or when Relying Parties require cryptographic
proof of each actor's participation independent of any single AS.
{
"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..."
}
]
}
In the Self-Attested example:
Prasad, et al. Expires 29 August 2026 [Page 9]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
* *Index 0* (Orchestrator): The originating actor. Its chain_digest
is SHA-256(canonical_json({sub, iss, iat})) — a self-hash of its
own identity claims. Its chain_sig is computed over this digest.
It includes a PoR binding it to node-1.
* *Index 1* (Planning Agent): Its chain_digest is SHA-
256(canonical_json(actor_chain[0])). Its chain_sig is produced by
the Planning Agent's key over this digest. No PoR is present (the
agent may be running in a non-TEE environment).
* *Index 2* (Tool Agent): Its chain_digest is SHA-
256(canonical_json(actor_chain[0..1])). Its chain_sig is produced
by the Tool Agent's key over this digest. It includes a PoR for
node-3.
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.
Prasad, et al. Expires 29 August 2026 [Page 10]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
4.4.1. Disclosure Propagation in SD-JWT
When Selective Disclosure (SD-JWT) [[!I-D.ietf-oauth-selective-
disclosure-jwt]] is used for any Actor Chain Entry, the Authorization
Server (AS) acts as the Discloser during token exchange. The
propagation of the underlying cleartext identities is managed as
follows:
1. *Disclosure Inclusion*: When the AS issues a token for a
downstream recipient (Service B), it determines based on policy
which hidden identifiers in the actor_chain should be visible to
that recipient. For each visible actor, the AS appends the
corresponding SD-JWT Disclosure string (containing the salt and
cleartext value) to the issued token.
2. *Hop-by-Hop Visibility*: In a chain a -> b -> c -> d -> e, if a
is to be visible to b, c, and d, the AS includes a's disclosure
string in the tokens issued to b, c, and d during their
respective token exchanges.
3. *Selective Redaction*: When the final exchange occurs for
recipient e (the end of the trust zone), the AS simply omits the
disclosure string for a from the issued token.
4. *Validation*: Each recipient in the chain can independently
verify the hash of any disclosed claim against the _sd array in
the Actor Chain Entry. If a disclosure is missing, the recipient
sees only the hash, but can still verify the entry's geographic
and residency properties through other claims.
This mechanism ensures that the "key" to unlock a hidden identity is
passed only to authorized actors in the chain, while the underlying
cryptographically signed JWT structure remains identical for all
recipients.
4.4.2. When Chain Signatures Are Produced
In Self-Attested Mode, a critical distinction is that each actor's
chain_sig is produced *during the token exchange request*, before the
final issued token exists. Consider a scenario where Service A calls
Service B, and Service B later needs to call Service C:
1. Service A calls Service B, presenting a token containing
actor_chain with chain [A].
2. Service B receives the token and performs its work.
3. *When Service B needs to call downstream Service C*, it initiates
a token exchange with the AS. At this point — not before —
Service B:
* Computes chain_digest over the existing chain entries from the
received token.
* Signs this chain_digest with its own key, producing chain_sig.
Prasad, et al. Expires 29 August 2026 [Page 11]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
* Submits both values to the AS as part of the token exchange
request, alongside the subject_token (containing chain [A])
and its own actor_token.
4. The AS validates the existing chain, then assembles the new
actor_chain (prior entries + Service B's signed entry) into the
issued JWT.
5. The AS signs the *entire JWT* (including the actor_chain) with
the AS's own key and returns the token to Service B.
6. Service B uses this new token (containing chain [A, B]) to call
Service C.
Consequently, each chain_sig covers only the *actor chain state* at
that actor's point of participation — not the enclosing JWT's other
claims such as aud, exp, or sub. This is by design: the actor chain
and the token are concerns of different parties. The actor signs the
chain to prove its participation; the AS signs the token to assert
the token's validity. This separation allows the AS to set audience,
expiry, and other claims independently without invalidating any
actor's chain signature.
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.
Prasad, et al. Expires 29 August 2026 [Page 12]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
4.5.1. Policy Examples
The following are illustrative examples of policies that become
expressible with the actor_chain claim:
*Origin-Based Policy*: Allow access only if the originating actor
(index 0) is a trusted orchestrator:
actor_chain[0].sub == "https://orchestrator.example.com"
*Domain Restriction*: Deny access if any actor in the chain belongs
to an untrusted domain:
for_all(entry in actor_chain):
entry.iss in ["https://auth.example.com",
"https://auth.partner.com"]
*Chain Depth Limit*: Reject tokens with delegation chains longer than
a configured maximum:
len(actor_chain) <= 5
*Residency Requirement*: Require that all actors in the chain have a
valid Proof of Residency:
for_all(entry in actor_chain):
entry.por is present AND entry.por is valid
*Path-Based Policy*: Allow access only through a specific delegation
path:
actor_chain[0].sub == "https://orchestrator.example.com" AND
actor_chain[1].sub == "https://planner.example.com"
4.5.2. Integration with Data-Plane Proxies
The flat array structure of actor_chain is designed for efficient
processing by data-plane proxies such as Envoy, Istio sidecars, and
API gateways. Proxies can:
1. Extract the actor_chain array from the JWT payload with a single
JSON path expression.
2. Iterate linearly over the entries without recursive descent.
3. Index specific entries by position (e.g., actor_chain[0] for the
originator).
4. Compute len(actor_chain) for depth-based policies without parsing
nested structures.
Prasad, et al. Expires 29 August 2026 [Page 13]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
5. Emit structured log entries per Actor Chain Entry for distributed
tracing and forensic analysis.
5. Chain Integrity Verification
A Relying Party receiving a token with the actor_chain claim MUST
perform the following verification steps:
1. *JWT Signature Verification*: Verify the outer JWT signature per
standard JWT processing rules. This is REQUIRED in both modes
and provides baseline integrity for the entire token, including
the actor_chain.
2. *Structural Validation*: Verify that actor_chain is a JSON array
with at least one element. Verify that each element contains the
required identity fields (sub, iss, iat).
3. *Per-Entry Signature Verification* (Self-Attested Mode only).
For each entry at index i:
* *Compute expected digest*: If i == 0, compute expected_digest
= SHA-256(canonical_json({sub, iss, iat})) from the entry's
own identity claims. If i > 0, compute expected_digest = SHA-
256(canonical_json(actor_chain[0..i-1])).
* *Verify chain_digest*: Confirm that the entry's chain_digest
matches expected_digest.
* *Verify chain_sig*: Verify chain_sig against chain_digest
using the actor's public key.
4. *PoR Verification* (if present):
* Verify each PoR assertion according to [[!I-D.draft-mw-spice-
transitive-attestation]].
5. *Policy Evaluation*:
* Apply local authorization policy against the verified actor
chain.
If any verification step fails, the Relying Party MUST reject the
token.
6. Relation to Other IETF Work
This proposal extends and complements several ongoing efforts:
Prasad, et al. Expires 29 August 2026 [Page 14]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
+================+=================================================+
| Specification | Relationship |
+================+=================================================+
| *RFC 8693* | This document extends [[RFC8693]] by defining |
| [[RFC8693]] | actor_chain as a replacement for the |
| | informational-only nested act claim. The |
| | actor_chain claim is backward-compatible: an AS |
| | MAY populate both act (for legacy consumers) |
| | and actor_chain (for chain-aware consumers). |
+----------------+-------------------------------------------------+
| *Transitive | Provides the "North-South" residency proof |
| Attestation* | (agent to local WIA) that complements the |
| [[!I-D.draft- | "East-West" delegation proof (agent to actor- |
| mw-spice- | chain) provided by this document. |
| transitive- | |
| attestation]] | |
+----------------+-------------------------------------------------+
| *SPICE | Defines the overarching workload identity |
| Architecture* | architecture within which this extension |
| [[!I-D.ietf- | operates. |
| spice-arch]] | |
+----------------+-------------------------------------------------+
| *WIMSE | This proposal aligns with the WIMSE delegation |
| Architecture* | and impersonation patterns for distributed |
| [[!I-D.ietf- | microservices architectures. |
| wimse-arch]] | |
+----------------+-------------------------------------------------+
| *Attestation- | Provides the client-to-AS attestation mechanism |
| Based Auth* | that can be leveraged to populate the hardware- |
| [[!I-D.ietf- | rooted por claims in Actor Chain Entries. |
| oauth- | |
| attestation- | |
| based-client- | |
| auth]] | |
+----------------+-------------------------------------------------+
| *SCITT* [[!I- | Verifiable actor chains can be recorded in |
| D.ietf-scitt- | SCITT transparency logs to provide long-term, |
| architecture]] | tamper-proof auditability of delegation paths. |
+----------------+-------------------------------------------------+
| *RATS* | Provides the attestation foundation for PoR |
| [[RFC9334]] | assertions embedded in Actor Chain Entries. |
+----------------+-------------------------------------------------+
| *DPoP* | actor_chain complements DPoP by providing |
| [[RFC9449]] | delegation-chain context alongside proof-of- |
| | possession. |
+----------------+-------------------------------------------------+
Table 1
Prasad, et al. Expires 29 August 2026 [Page 15]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
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. Security Considerations
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.
Prasad, et al. Expires 29 August 2026 [Page 16]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
* 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.
Prasad, et al. Expires 29 August 2026 [Page 17]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
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:
Prasad, et al. Expires 29 August 2026 [Page 18]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
7.6.1. Pseudonymous Identifiers
Instead of using globally unique or stable identifiers (like email
addresses or client IDs), the Authorization Server (AS) can issue
pairwise pseudonyms for actors. In the chain a -> b -> c -> d -> e:
- The AS replaces sub: "a" with a pseudonym sub: "pseudo-xyz" that is
only meaningful to the AS. - Relying Party e sees that the chain
started with a verified actor, but does not know it was a. - The AS
maintains a mapping to allow for forensic reconstruction if
authorized.
7.6.2. Selective Disclosure (SD-JWT)
The actor_chain MAY be implemented using Selective Disclosure for
JWTs [[!I-D.ietf-oauth-selective-disclosure-jwt]]. This allows
individual Actor Chain Entries to be hashed with unique salts,
enabling verification of the entry's integrity without revealing its
cleartext content unless a corresponding disclosure is provided.
7.6.3. Identity Bridging for Anonymity
An Identity Bridge [[!I-D.ietf-spice-arch]] MAY act as an
"Anonymizer" by performing a token exchange that replaces sensitive
predecessor entries in the actor_chain with generic or pseudonymous
identifiers, while still vouching for the chain's security
properties.
7.6.4. Targeted Selective Disclosure
A more advanced privacy model involves disclosing actor identities
only to trusted intermediate parties. In the chain a -> b -> c -> d
-> e, actor a may be visible to b, c, and d, but hidden from e.
This is achieved through *Targeted Disclosure* using SD-JWT: - The AS
generates the actor_chain with actor a's identity hashed and salted.
- Alongside the JWT, the AS provides a "Disclosure" string (the salt
and cleartext value) for actor a. - When the AS issues a token for b,
c, or d, it includes this disclosure string. This allows these
"internal" actors to "unlock" the hash and see a's true identity. -
When the final token is exchanged for recipient e, the AS (or the
last internal actor d) simply omits the disclosure string for actor
a. - Actor e receives the same JWT but without the "key" to unlock a.
e can verify the cryptographic integrity of the entire chain (proving
that a verified, though anonymous, actor started it) without ever
seeing a's identity.
Prasad, et al. Expires 29 August 2026 [Page 19]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
+===========+===============+======================+================+
| Recipient | JWT Payload | Disclosure provided? | Interpretation |
+===========+===============+======================+================+
| *Actor b* | _sd: | *Yes* | b sees sub: a |
| | [hash_a] | | |
+-----------+---------------+----------------------+----------------+
| *Actor e* | _sd: | *No* | e sees sub: |
| | [hash_a] | | <hidden> |
+-----------+---------------+----------------------+----------------+
Table 2
7.6.5. Encryption (JWE)
The entire actor_chain claim can be encrypted using JWE [[RFC7516]]
so that only the final intended audience e can decrypt it, preventing
intermediate actors like b, c, and d from seeing the IDs of their
predecessors. Alternatively, the chain can be nestedly encrypted for
different parties in the path.
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. IANA Considerations
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]]:
Prasad, et al. Expires 29 August 2026 [Page 20]
Internet-Draft SPICE-ACTOR-CHAIN February 2026
* *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]
Authors' Addresses
A Prasad
Oracle
Email: a.prasad@oracle.com
Ram Krishnan
JPMorgan Chase & Co
Email: ramkri123@gmail.com
Diego R. Lopez
Telefonica
Email: diego.r.lopez@telefonica.com
Srinivasa Addepalli
Aryaka
Email: srinivasa.addepalli@aryaka.com
Prasad, et al. Expires 29 August 2026 [Page 21]