OAuth A. Prasad Internet-Draft Intended status: Informational R. Krishnan Expires: 21 April 2027 D. Lopez S. Addepalli S. Krishnan 18 October 2026 OAuth Actor Chain: Overview and Design draft-mw-oauth-actor-chain-overview-00 Abstract A request can pass through several services before reaching an API. OAuth Token Exchange can represent an actor history in nested act claims. It leaves the rules for constructing that history, limiting its disclosure, and verifying an actor's own signature to additional profiles. Actor Chain proposes those rules while keeping the Authorization Server responsible for issuing tokens and applying policy. This document provides a new overview of the authors' Actor Chain proposal, whose Internet-Draft lineage began in SPICE in February 2026. The companion OAuth Actor Chain: Protocol and Interoperability specification continues the existing OAuth draft series and defines wire formats and processing requirements. 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 21 April 2027. Prasad, et al. Expires 21 April 2027 [Page 1] Internet-Draft ACTOR-CHAIN-OVERVIEW October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 2. Illustrative Workflow . . . . . . . . . . . . . . . . . . . . 3 3. Assurance and Disclosure . . . . . . . . . . . . . . . . . . 4 4. Token Claims and Example . . . . . . . . . . . . . . . . . . 5 5. Evidence Delivery . . . . . . . . . . . . . . . . . . . . . . 6 6. Deployment Requirements . . . . . . . . . . . . . . . . . . . 7 7. Cross-Domain Preservation . . . . . . . . . . . . . . . . . . 7 8. Security and Privacy Considerations . . . . . . . . . . . . . 7 9. Questions for IETF Review . . . . . . . . . . . . . . . . . . 8 10. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. Informative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Applications delegate requests across services. Each receiving service authorizes calls and may need actor identities, participation evidence, and disclosure policy. Actors are services or agents acting for the token's subject. OAuth 2.0 Token Exchange [RFC8693] can represent history in nested act claims. The Authorization Server (AS) decides whether to include it. Under RFC 8693 Section 4.1, access control considers top-level claims and the current actor; earlier actors are informational. Actor Chain, this proposal, specifies history construction, disclosure, and verification. A workflow is a sequence of related authorization transitions. The AS authenticates each new actor, checks authority, and issues the next token. Prasad, et al. Expires 21 April 2027 [Page 2] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 The companion protocol specification, [ACTOR-CHAIN-PROTOCOL], defines the implementation and interoperability requirements. 1.1. Motivation A receiving service may trust its immediate caller but still need to know which earlier services participated in the request. Different recipients need different parts of that history. These examples illustrate why: +==============+================================================+ | Disclosure | Example authorization need | +==============+================================================+ | "Full" | A production executor checks the initiating | | | planner and immediate policy broker. The | | | release gateway additionally checks the | | | executor and accepted route through all three. | +--------------+------------------------------------------------+ | "Subset" | A connector checks the request agent and | | | planner. The repository checks the agent and | | | connector without needing the planner's | | | identity. | +--------------+------------------------------------------------+ | "Actor-Only" | An external payroll API authorizes the | | | registered payroll connector without learning | | | the internal HR agents that prepared the | | | request. | +--------------+------------------------------------------------+ Table 1 Each recipient applies normal OAuth authorization and its configured evidence policy. Earlier identities in nested act remain informational; any required direct verification uses the applicable actor evidence. Participation does not prove business approval or successful execution. Workflow accountability is a separate need. Retained records can help an authorized auditor correlate accepted actor steps across a workflow, even when an individual resource needs only its immediate caller. 2. Illustrative Workflow For a report request, orchestrator A asks planner B to select documents; B invokes connector C, which retrieves records from API D. Prasad, et al. Expires 21 April 2027 [Page 3] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 For illustration, A/B use Agent2Agent (A2A) [A2A-SPEC], B/C use remote Model Context Protocol (MCP) [MCP-AUTH], and D runs on Kubernetes. These are optional deployment choices. A orchestrator --A2A--> B planner B planner --MCP--> C connector --HTTPS--> D document API With exchange permissions configured, A obtains a token for B; B exchanges it for a token addressed to C, and C exchanges that for one addressed to D. Each exchange records its requesting actor; each receiver checks its token. Reusing a token for status checks adds no step. For "Verified" assurance, C signs an actor proof requesting access to D from B's accepted step. The AS checks the proof and authority, then signs an acceptance. C signs the request; the AS signs its acceptance. 3. Assurance and Disclosure *Assurance models:* * *Declared:* The Authorization Server asserts actor-chain history and continuity. * *Verified:* Each actor signs its transition request, and the AS signs an acceptance. Evidence coverage determines which actor signatures and links the recipient independently verifies. *Disclosure* determines what actor history is visible to the recipient, while assurance determines how that history is substantiated. Verified assurance does not require the recipient to see or independently verify the complete chain. For the A → B → C → D illustrative workflow: +============+========================+======================+ | Disclosure | History visible to D | Assurance | +============+========================+======================+ | Full | A, B, C | Declared or Verified | +------------+------------------------+----------------------+ | Subset | A and C (illustrative, | Declared or Verified | | | if authorized) | | +------------+------------------------+----------------------+ | Actor-Only | C | Declared or Verified | +------------+------------------------+----------------------+ Table 2 Prasad, et al. Expires 21 April 2027 [Page 4] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 The six assurance/disclosure profiles are selected at workflow start and remain fixed. A disclosed subset such as A/C does not establish adjacency or the absence of intervening actors. 4. Token Claims and Example This example uses "Verified" assurance and "Actor-Only" disclosure: +=======+======================================================+ | Claim | Meaning in C's token for D | +=======+======================================================+ | sub | The party or context represented by the workflow | +-------+------------------------------------------------------+ | aud | The intended recipient, D | +-------+------------------------------------------------------+ | actp | The profile: verified-actor-only | +-------+------------------------------------------------------+ | acti | A random identifier shared by this workflow's tokens | +-------+------------------------------------------------------+ | act | C's identity: issuer and subject pair | +-------+------------------------------------------------------+ | actc | The AS-signed acceptance of C's proof | +-------+------------------------------------------------------+ Table 3 This partial JSON Web Token (JWT) omits issuer, lifetime, token identifier, and sender binding. Angle brackets mark placeholders. { "sub": "workflow-subject-alias", "aud": ["https://d.example"], "actp": "verified-actor-only", "acti": "", "act": { "iss": "https://actors.example/c", "sub": "C" }, "actc": "" } is the complete AS-signed acceptance JWT encoded as a string. It hashes C's proof and B's acceptance. These fingerprints identify exact records without embedding them; supplying those records enables substitution checks. Prasad, et al. Expires 21 April 2027 [Page 5] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 5. Evidence Delivery D checks the AS's actc; C's signature additionally needs C's proof. Resources advertise requirements through authenticated OAuth Protected Resource Metadata [RFC9728]. The optional acte supplies evidence: +==========+===================+==============================+ | Field | This example | Alternative | +==========+===================+==============================+ | coverage | current: C's step | disclosed: actors in act; | | | | path: complete "Full" path | +----------+-------------------+------------------------------+ | delivery | inline: inside | introspection: authenticated | | | the token | AS retrieval [RFC7662] | +----------+-------------------+------------------------------+ Table 4 For "Subset", disclosed carries one original proof/acceptance pair per actor occurrence in act. If D requires A/C, it receives and verifies A/C without B's proof. Another authorized recipient may receive B's evidence according to its policy. The issuer attests that selected records belong to this token's accepted path. Signatures prove the requests signed, not adjacency across omitted actors. current verifies C only; path independently checks the complete accepted path. Inline delivery avoids retrieval but enlarges tokens. Introspection needs an available endpoint. Missing required evidence or conflicting disclosure policy causes failure. Here v=1 identifies the evidence format; is C's signed access request for D. Each steps entry pairs a proof with its acceptance: { "acte": { "v": 1, "coverage": "current", "delivery": "inline", "steps": [ { "proof": "", "acceptance": "" } ] } } Prasad, et al. Expires 21 April 2027 [Page 6] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 D requires this acceptance to equal token actc, verifies both signatures, and matches the acceptance's proof hash to the supplied proof. Current evidence can hide A/B. disclosed uses envelope version 2; each selected signature is checked, and the final acceptance equals actc. Historical signed targets may reveal omitted services; conflicting privacy requirements cause failure. SD-JWT could supply selective field disclosure in a future encoding profile [RFC9901]; this version preserves ordinary JWT signatures and defines no SD-JWT wire format. 6. Deployment Requirements Clients, ASs, and verifiers need Actor Chain support. Each receiving service that continues the workflow needs AS authorization to exchange its inbound token; receiving a sender-bound token does not transfer the previous actor's key. When authorization relies on the immediate actor as the live presenter, MCP's Bearer presentation [MCP-AUTH] needs a compatible sender constraint, such as explicitly agreed certificate-bound mutual TLS [RFC8705]. This does not satisfy a resource requirement for DPoP. Kubernetes credentials [K8S-SA] authenticate workloads without creating actor proofs. The protocol specification's "Agent and Workload Integration" section [ACTOR-CHAIN-PROTOCOL] details these requirements. Live interoperability remains untested. 7. Cross-Domain Preservation Transfer between ASs preserves accepted state and original signatures without adding an application actor. The protocol specification's "Cross-Domain Preservation" section [ACTOR-CHAIN-PROTOCOL] defines it. Mapping read to destination permission documents.read needs destination authorization. An earlier signature still covers read; it does not attest to the translated meaning. Direct verification of a new step requires its actor's fresh signature on local values. The same applies to translated subject and resource names. 8. Security and Privacy Considerations With uncompromised actor keys, independently authorized ActorID bindings, and checked proof-to-acceptance linkage, an AS cannot fabricate an actor's signed request. Under disclosed coverage, it can misstate path membership, misapply policy, issue other tokens, or collude. Evidence does not prove correct execution or faithful interpretation of user intent. Prasad, et al. Expires 21 April 2027 [Page 7] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 C's exchange-time signature does not establish who presents the token now. The protocol specification [ACTOR-CHAIN-PROTOCOL] uses Demonstrating Proof of Possession (DPoP) [RFC9449] to check control of the token-bound key. Other sender-binding mechanisms need explicit agreement. Exact retries reuse one acceptance. Separate requests can branch; one verified path does not prove uniqueness. Full evidence reveals relationships and timing; workflow identifiers permit correlation. Historical verification needs retained proofs and key history. Introspection and replay state add live dependencies. 9. Questions for IETF Review 1. Do these use cases justify a common contract beyond RFC 8693? 2. Does issuer-attested membership meet Subset authorization needs? 3. Are disclosure requirements and recipient policy boundaries sufficient? 4. Does cross-domain preservation accurately describe mappings' assurance? 10. Design Evolution The authors' SPICE -00 (25 February 2026) carried actor signatures in self-attested tokens [SPICE-ACTOR-CHAIN-00]. SPICE -01 (16 March 2026) moved them to exchange-time proofs with hash-linked AS acceptances [SPICE-ACTOR-CHAIN-01]. OAuth -01 (15 June 2026) continued this work [OAUTH-ACTOR-CHAIN-01]. The companion protocol -02 continues that series and specifies evidence delivery. 11. IANA Considerations This overview requests no IANA action. Registration requests are defined in [ACTOR-CHAIN-PROTOCOL]. 12. Informative References [A2A-SPEC] A2A Project, "Agent2Agent Protocol Specification, version 1.0.0", . [ACTOR-CHAIN-PROTOCOL] Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli, "OAuth Actor Chain: Protocol and Interoperability", 4 October 2026, . Prasad, et al. Expires 21 April 2027 [Page 8] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 [K8S-SA] Kubernetes, "Kubernetes Service Accounts", . [MCP-AUTH] Model Context Protocol, "Model Context Protocol Authorization, revision 2026-07-28", . [OAUTH-ACTOR-CHAIN-01] Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli, "Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange", 15 June 2026, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [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, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", February 2020, . [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, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [SPICE-ACTOR-CHAIN-00] Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli, "Cryptographically Verifiable Actor Chain for OAuth 2.0 Prasad, et al. Expires 21 April 2027 [Page 9] Internet-Draft ACTOR-CHAIN-OVERVIEW October 2026 Token Exchange", 25 February 2026, . [SPICE-ACTOR-CHAIN-01] Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli, "Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange", 16 March 2026, . Authors' Addresses A Prasad Email: ap1729@gmail.com Ram Krishnan Email: ramkri123@gmail.com Diego R. Lopez Email: diego.r.lopez@telefonica.com Srinivasa Addepalli Email: srinivasa.addepalli@aryaka.com Suresh Krishnan Email: suresh.krishnan@gmail.com Prasad, et al. Expires 21 April 2027 [Page 10]