OAuth Actor Chain: Overview and Design

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

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

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

The companion protocol specification, [ACTOR-CHAIN-PROTOCOL], defines the implementation and interoperability requirements.¶

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

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

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

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": "<random workflow identifier>",
  "act": { "iss": "https://actors.example/c", "sub": "C" },
  "actc": "<acceptance_C>"
}

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

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

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; <proof_C> 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": "<proof_C>", "acceptance": "<acceptance_C>" }
    ]
  }
}

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

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

Authors' Addresses