OAuth Actor Chain: Protocol and Interoperability

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 16 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 often delegate a request across several services before reaching a protected resource. The resource may need evidence about earlier actors, while disclosure policy limits which identities and relationships it may learn. For example, a document API may require evidence from the initiating service and its immediate connector without needing every intermediary's identity.¶

OAuth 2.0 Token Exchange [RFC8693] supports exchanging credentials and representing actor history in nested act claims. Earlier actors in that history remain informational for access control. Actor Chain adds explicit rules for constructing the history, controlling disclosure, and delivering actor-signed evidence through a separate top-level extension. It retains the Authorization Server's (AS's) responsibility for authorization and token issuance.¶

A -> B -> C -> D

2. Standards Boundary

This document profiles OAuth 2.0 Token Exchange and does not change the base meaning of sub, act, or may_act. When actp is absent, this document adds no processing rules. Earlier actors in nested act remain informational for access-control purposes as specified by RFC 8693.¶

When actp selects a profile in this document:¶

• the token-level sub remains the subject of the workflow;¶

• act names the actors disclosed in that token; it does not change sub;¶

• may_act retains its RFC 8693 meaning as a statement about who may act; it does not record an Actor Chain transition;¶

• acti identifies this sequence of actor transitions as one workflow; and¶

• in a Verified profile, actc carries the AS acceptance and optional acte delivers actor-signed evidence to the recipient.¶

This specification does not define application roles, business policy, transaction semantics, task execution, result correctness, complete branch discovery, or a general delegation-policy language. It compares OAuth scope as written; differently named scopes in different domains are not assumed to mean the same thing.¶

3. Authorization Policy Model

The AS applies issuance policy to its authoritative accepted workflow state. The recipient applies normal OAuth authorization and its configured evidence policy. RFC 8693 Section 4.1's rule for earlier nested act identities is preserved: those identities alone remain informational. This profile defines the top-level acte extension as an additional source of authenticated actor records. Section Section 18.5 specifies its use.¶

With disclosed coverage, the recipient verifies the actors disclosed to it. It trusts the token issuer's attestation that the selected records belong to this token's accepted path. It need not obtain or verify undisclosed actors; different authorized recipients can receive and verify different subsets. For example, a recipient requiring A and C can verify their disclosed records without B's proof. A recipient requiring B must receive and verify B's evidence; another recipient's check satisfies that requirement only under an explicit local trust policy. Complete-path verification is an additional policy choice, not a requirement of disclosed coverage. Participation does not establish business approval, argument-level permission, or execution results. Application policy determines which authenticated records are relevant; this specification defines no role or approval language.¶

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

This document uses OAuth terminology from [RFC6749] and [RFC8693]. It also defines:¶

• ActorID: the issuer-qualified actor identifier { "iss": ..., "sub": ... }.¶

• Current actor: the actor authenticated by the AS for a root or extend transition.¶

• Presenting actor: the entity that presents the issued access token to its recipient.¶

• Actor-visible chain: the ordered ActorID sequence the current actor is authorized to know at its transition. The actor commits to that sequence without exposing it in the step proof.¶

• Disclosed chain: the ordered ActorID sequence shown in a token's nested act claim. Disclosure can be narrower than the actor-visible chain.¶

• Acceptance: the AS-signed compact JWS, carried as actc, that accepts one exact actor proof and links it to the preceding acceptance, if any.¶

• Evidence coverage: current supplies the latest proof and acceptance; disclosed supplies the original proof and acceptance for each disclosed actor occurrence; path supplies the continuous root-to-current proofs, acceptances, and actor-view openings.¶

• Evidence delivery: inline carries evidence in the token; introspection supplies it through authenticated token introspection.¶

• Commitment-only: a Verified token carrying actc without acte.¶

• Protected state: actp, acti, actc, and any carried acte. A preserve transition transports these values without transcription.¶

5. Profiles: Assurance and Disclosure

Each profile makes two separate choices: how an actor transition is supported (assurance) and how much actor history a token reveals (disclosure). Declared assurance relies on the issuing AS's assertion. Verified assurance adds an actor proof and AS acceptance at each actor transition. Full disclosure shows the whole actor path; Subset shows an authorized subset; Actor-Only shows only the current actor. These choices yield six profiles:¶

The evidence option is separate from the six profiles. In a Verified profile, current permits direct verification of the latest actor proof. disclosed permits direct verification of every actor occurrence in the token's act, with issuer-attested membership in this token's accepted path. path permits direct verification of every actor proof and original AS acceptance on one root-to-current path, and is available only with Full disclosure in this version.¶

These artifacts prove only the checks specified here. Neither actc nor acte proves that an actor performed a task, produced a correct result, remained uncompromised, or that every branch or off-protocol actor was disclosed. Live possession by the token presenter requires a separate sender constraint.¶

6. Conformance

An implementation MAY support any subset of the six profiles, but MUST publish its supported capabilities as specified in Section Section 17. For each profile it accepts, the implementation MUST apply the common rules and the rules for that profile's assurance and disclosure choices.¶

The request selects exactly one actor_chain_profile. The AS either issues a token with the matching actp value or rejects the request. actp and the workflow identifier acti remain unchanged throughout that workflow. A party MUST NOT infer a profile from the shape of act or from acte.¶

Unknown profile values, versions, transition kinds, evidence coverage values, delivery values, or protected artifact types, and missing required members, MUST fail closed. That means processing stops rather than guessing a default. JSON objects used by this specification MUST reject duplicate members.¶

7. Common Data Model

Self-contained profiled access tokens MUST be signed JWTs [RFC7519] and MUST contain iss, sub, aud, iat, exp, jti, actp, and acti. They carry act as required by the selected disclosure mode. Verified tokens MUST additionally carry actc and MAY carry acte.¶

An ActorID is a JSON object containing exactly two non-empty string members: iss and sub. In this object, sub identifies the actor; it is distinct from the access token's top-level workflow subject. iss is an absolute issuer URI. ActorID equality is exact equality of the pair. Newly issued nested act nodes MUST carry both members.¶

VisibleChain(act) reads nested act from the innermost prior actor to the outermost current actor. EncodeVisibleChain([A,B]) is:¶

{
  "iss": "B.iss",
  "sub": "B.sub",
  "act": { "iss": "A.iss", "sub": "A.sub" }
}

The AS MUST mint acti at root using a CSPRNG with at least 122 bits of entropy. It MUST remain stable and MUST NOT encode actor, profile, target, or business information.¶

Profiled access tokens SHOULD normally expire within one to ten minutes after issuance. Implementations MUST validate iss, aud, exp, and jti according to their governing OAuth and JWT specifications before Actor Chain processing.¶

8. Target And Scope Binding

A Verified actor transition targets one protected resource, such as the destination API. The proof's target_context has a required resource member and may have a scope member:¶

{ "resource": "https://api.example/", "scope": "read" }

resource is one non-empty string. It MUST equal the single RFC 8707 [RFC8707] resource value in the request and MUST be an HTTPS Resource Identifier without a fragment as defined by RFC 9728 [RFC9728]. It MUST NOT contain user information. A query component SHOULD be omitted unless the deployment requires it. Actor Chain transitions MUST NOT request more than one resource. Fan-out uses distinct tokens and distinct request_id values.¶

Identifiers covered by a proof must match exactly. This specification compares Unicode code points after JSON unescaping, with no Unicode normalization. Implementations MUST NOT case-fold a scheme or host, remove a default port, add or remove a trailing slash, resolve dot segments, decode percent-encoding, reorder a query, follow a redirect, or apply another URI normalization before comparing a signed identifier. Parsing to enforce URI syntax is allowed; changing the string before comparison is not. Producers SHOULD publish and sign one stable form. A signed target is an identifier. It MUST NOT be dereferenced merely because it appears in a valid proof. Exact string comparison avoids security-dependent differences among URI libraries [RFC3986].¶

accepting_issuer MUST be an RFC 8414 issuer identifier and MUST equal, under the same exact comparison rule, both the authenticated AS metadata issuer and the acceptance iss.¶

The actor proof does not duplicate the access token's aud. RFC 8707 permits an AS to use the resource value as the audience or map it to another audience identifier. The AS MUST audience-restrict the token to the proof-bound resource using its established mapping and MUST NOT retarget the proof. A recipient validates token aud independently under JWT and its OAuth profile; a JWT audience may be one string or an array, and every comparison is the exact, case-sensitive comparison defined by RFC 7519 [RFC7519]. This separation keeps an AS-local audience mapping from becoming portable actor-signed state.¶

For a Verified root or extend, requested OAuth scope and target_context.scope MUST either both be present or both be absent. When present, each MUST satisfy the scope grammar in RFC 6749 Section 3.3 [RFC6749] and describe the same lexical set. The proof uses the canonical form: reject duplicates, sort tokens by ascending ASCII value, and join them with one U+0020 SPACE. Scope tokens are case-sensitive. Empty strings, leading or trailing spaces, repeated separators, and non-scope-token characters MUST be rejected.¶

When both members are absent, the actor authorizes the empty OAuth scope set. For these Verified transitions, the AS's predefined default under RFC 6749 Section 3.3 MUST be that empty set. An AS that cannot apply this default MUST reject an omitted-scope request with invalid_scope. The AS MUST NOT apply a non-empty default scope or issue a token with non-empty scope. An empty granted set omits token scope; a non-empty granted set MUST be stated explicitly in the token. Required default scopes must be known before signing and explicitly included in the proof and token request. An AS that cannot issue under these rules MUST reject with invalid_scope. These constraints apply only to Verified transitions; Declared processing retains the governing OAuth scope rules.¶

The AS either issues for the exact proof-bound resource or rejects; it does not "narrow" one URI into another. It MAY narrow scope. Scope narrowing is set inclusion over lexical scope tokens. This rule does not establish semantic equivalence between differently named cross-domain scopes. Cross-domain scope translation requires an explicitly authorized mapping, as specified in Section Section 19. An unknown mapping MUST be rejected.¶

Each proof binds the outgoing target for that transition only. In A -> B -> C -> D, the successive resources can legitimately identify B, C, and D; those URIs do not form an ordered set. Each accepting AS validates its transition's request, proof, issued token, and authorization. D can directly compare the final proof with D's authenticated RFC 9728 resource identifier. Without a retained historical token, path evidence does not reconstruct the audience or effective authority of that historical token.¶

9. Actor-View Commitment

The actor proof does not carry a clear growing actor path. It carries a salted commitment to the exact actor-visible ActorID array. Let salt32 be 32 random octets freshly generated for the transition. The commitment is:¶

b64url(SHA-256(
  ASCII("urn:ietf:params:oauth:actor-chain:view:v1") || 0x00 ||
  salt32 || 0x00 || JCS(actor_view_array)))

JCS is the JSON Canonicalization Scheme [RFC8785]. b64url is unpadded base64url as defined by [RFC7515]. SHA-256 is fixed for this commitment version; there is no per-workflow hash negotiation.¶

The actor supplies an opening containing salt and act to the accepting AS in the actor_chain_view_opening request parameter. That parameter is the base64url encoding of the UTF-8 JCS representation of:¶

{
  "salt": "<base64url 32 octets>",
  "act": [
    { "iss": "https://actors.example/a", "sub": "A" }
  ]
}

The opening contains exactly salt and act. salt MUST decode to exactly 32 octets. act MUST be a non-empty array of valid ActorIDs in actor-visible order. The decoded parameter MUST equal its UTF-8 JCS representation.¶

The AS MUST validate the opening against authenticated actor identity, inbound state, append-only processing, disclosure policy, and the proof commitment. It MUST NOT place the opening in current evidence.¶

10. Actor Step Proof

Every Verified root and extend transition creates exactly one actor step proof. It is a compact JWS whose protected header contains exactly alg, kid, and typ, with typ=oauth-act-step+jwt. The following example uses ES256; permitted algorithms are defined in Section Section 23:¶

{ "alg": "ES256", "kid": "<key identifier>",
  "typ": "oauth-act-step+jwt" }

The payload has version v=2. A root payload contains exactly:¶

{
  "v": 2,
  "kind": "root",
  "actp": "verified-full",
  "acti": "<workflow identifier>",
  "actor": { "iss": "https://actors.example/a", "sub": "A" },
  "sub": "<workflow subject>",
  "accepting_issuer": "https://as1.example",
  "target_context": {
    "resource": "https://api.example/",
    "scope": "read"
  },
  "view_commitment": "<base64url SHA-256>",
  "request_id": "<request-unique identifier>",
  "iat": 1786827601
}

An extend payload contains the same members with kind=extend and one additional member:¶

"prev": "<b64url SHA-256 of exact preceding compact actc>"

The actor key MUST be independently authorized for the exact ActorID in actor. A valid signature from a key associated with another actor MUST be rejected. The actor MUST equal the authenticated current actor; actp, acti, and sub MUST equal accepted workflow state; accepting_issuer MUST identify the AS processing the transition; and iat MUST be an integer NumericDate within the AS acceptance window measured against the AS clock. A default maximum age of 60 seconds, plus a separately configured allowance for future clock skew, is RECOMMENDED.¶

request_id MUST be a non-empty string of at most 128 UTF-8 octets. The actor MUST assign a fresh value to every intended root or extend transition and MUST NOT intentionally reuse it for a different proof. The probability of an accidental duplicate in the same accepting-issuer, ActorID, and workflow context MUST be negligible. At least 96 bits of pseudorandom data or a UUIDv4 value is sufficient, following the equivalent identifier guidance in [RFC9449].¶

The proof binds authorization requested by the actor. It does not require the AS to issue that authority. The AS MAY narrow the result but MUST NOT broaden it.¶

11. Authorization Server Acceptance

After accepting a Verified actor proof, the AS creates one compact JWS actc. Its protected header contains exactly alg, kid, and typ=oauth-actc+jwt. Its payload has version v=2.¶

A root acceptance contains exactly:¶

{
  "v": 2,
  "kind": "root",
  "iss": "https://as1.example",
  "acti": "<workflow identifier>",
  "actp": "verified-full",
  "step_hash": "<b64url SHA-256 of exact proof compact JWS>",
  "accepted_at": 1786827651
}

An extend acceptance additionally contains:¶

"prev": "<b64url SHA-256 of exact preceding compact actc>"

The AS signature key MUST be authorized for iss at accepted_at. step_hash is computed over the ASCII octets of the exact proof compact JWS. For extend, prev is computed over the ASCII octets of the exact prior compact actc. kind, acti, actp, and prev MUST equal the proof values, and iss MUST equal the proof's accepting_issuer.¶

accepted_at MUST be the AS time at acceptance. It MUST NOT precede proof iat by more than permitted future clock skew or exceed proof iat by more than the configured acceptance window. A later evidence verifier checks this signed relationship; it does not apply the original short proof-freshness window relative to its current clock.¶

The exact compact actc is the current chain head. There is no separately transported curr, negotiated halg, or repeated evidence head. Re-encoding an actc changes the artifact and therefore changes successor linkage.¶

12. Evidence Envelope

acte is OPTIONAL in a Verified access token. Absence is integrity protected by the token signature and means commitment-only delivery. Presence selects one coverage and one delivery mode.¶

An inline current envelope is:¶

{
  "v": 1,
  "coverage": "current",
  "delivery": "inline",
  "steps": [
    { "proof": "<current proof>", "acceptance": "<current actc>" }
  ]
}

Every envelope contains exactly v, coverage, delivery, and, when expanded, steps; an introspection descriptor omits steps. A current step contains exactly proof and acceptance, both compact JWS strings. A path step contains exactly those members plus opening as defined in Section Section 9. Extra or missing members and wrong JSON types MUST be rejected.¶

current MUST contain exactly one step. It MUST NOT contain an actor-view opening. The step acceptance MUST equal the token's actc as an exact string. The proof ActorID MUST be authorized for disclosure and MUST equal the outermost current ActorID in the token's act. A Subset token carrying current evidence therefore MUST include that actor in act; hidden predecessors remain hidden.¶

An inline path envelope is:¶

{
  "v": 1,
  "coverage": "path",
  "delivery": "inline",
  "steps": [
    {
      "proof": "<proof A>",
      "acceptance": "<actc A>",
      "opening": {
        "salt": "<salt A>",
        "act": [{ "iss": "https://actors.example/a", "sub": "A" }]
      }
    },
    {
      "proof": "<proof B>",
      "acceptance": "<actc B>",
      "opening": {
        "salt": "<salt B>",
        "act": [
          { "iss": "https://actors.example/a", "sub": "A" },
          { "iss": "https://actors.example/b", "sub": "B" }
        ]
      }
    }
  ]
}

path MUST contain the continuous root-to-current sequence in order. Every step MUST contain an opening, each proof and acceptance MUST verify, each prev MUST hash the exact preceding acceptance, and the final acceptance MUST equal token actc. The final opened actor-view array MUST equal the complete VisibleChain(act) in the token. This version permits path only with verified-full. Subset and Actor-Only recipients can receive current evidence without hidden predecessors; they MUST NOT receive path under this version. They can also receive disclosed evidence as defined below.¶

{
  "v": 2,
  "coverage": "disclosed",
  "delivery": "inline",
  "steps": [
    { "proof": "<proof A>", "acceptance": "<actc A>" },
    { "proof": "<proof C>", "acceptance": "<actc C>" }
  ]
}

{ "v": 1, "coverage": "current", "delivery": "introspection" }

13. Transition State Machine

For Verified profiles, implementations MUST process exactly the following transitions. Declared profiles retain the corresponding workflow transitions without actor proofs or acceptances, as specified in Section Section 14.3.¶

For root, the AS authenticates the actor, allocates acti and sub, authorizes a target bound in a short-lived bootstrap context, validates the root proof and opening, atomically reserves the replay key, durably finalizes the exact actc, applies disclosure policy, and issues the token.¶

For extend, the AS validates the inbound token and current actc, verifies that the authenticated actor was an intended recipient of the inbound token, validates the extend proof and opening, checks exact predecessor linkage and authority narrowing, atomically reserves the replay key, appends the actor, durably finalizes the exact new actc, applies disclosure and evidence requirements, and issues the successor token.¶

For preserve, the AS validates the inbound cross-domain grant, creates no actor step, preserves protected Actor Chain state exactly, applies only authorized identity/target translations, and issues a local token or rejects. A preserve operation MUST NOT be represented as actor participation.¶

14. Bootstrap And Token Exchange

{
  "actor_chain_bootstrap_context": "<opaque redemption context>",
  "actor_chain_bootstrap_binding": {
    "actor": { "iss": "https://actors.example/a", "sub": "A" },
    "acti": "<workflow identifier>",
    "actp": "verified-full",
    "sub": "<workflow subject>",
    "accepting_issuer": "https://as1.example",
    "target_context": {
      "resource": "https://api.example/", "scope": "read"
    },
    "expires_in": 60
  }
}

15. Disclosure Processing

The AS is the disclosure policy decision and enforcement point. No claim, identifier, error, evidence envelope, or auxiliary encoding may reveal more actor-chain information than the selected profile permits.¶

• Full: act is REQUIRED and MUST equal the complete accepted actor path.¶

• Subset: act MAY be omitted. If present, it MUST be an ordered subsequence of the accepted actor-visible chain authorized for that recipient. A non-contiguous subset such as [A,C] does not assert that A directly preceded C. When current or disclosed evidence is present, act is REQUIRED and MUST include the directly proved current actor.¶

• Actor-Only: act is REQUIRED and MUST contain exactly the current actor. No prior actor may be disclosed in the token or current evidence. disclosed evidence MUST likewise contain only that current actor.¶

The current actor validates that returned disclosure does not exceed what it was authorized to know. A recipient authorizes using only the actors actually disclosed to it. Omission does not assert absence.¶

The actor-view commitment prevents a transported current proof from exposing the clear chain the actor knew. It does not conceal the current actor, target, scope, accepting AS, workflow identifier, or timing carried in that proof.¶

For disclosed delivery, the AS MUST apply recipient disclosure policy to all contents of every selected signed record, including historical targets, subject identifiers, issuers, times, and predecessor digests. Omitting an ActorID from act does not ensure that a historical target hides the same service. If a required record conflicts with privacy policy, issuance fails; the AS MUST NOT silently omit that record or downgrade required coverage.¶

16. Protected Resource Evidence Requirements

A protected resource advertises its Actor Chain evidence floor through OAuth 2.0 Protected Resource Metadata [RFC9728]. The provisional extension is:¶

{
  "resource": "https://api.example/",
  "authorization_servers": ["https://as.example"],
  "actor_chain_evidence_required": {
    "v": 1,
    "coverage": "current",
    "delivery": ["inline", "introspection"]
  },
  "dpop_bound_access_tokens_required": true
}

Absence of actor_chain_evidence_required means commitment-only Verified tokens are acceptable from the perspective of this specification. Presence requires the exact coverage and one listed delivery mode. A client preference does not weaken this authenticated resource requirement.¶

The v and coverage pair MUST be one defined in Section Section 12. A resource requiring the original signatures of all disclosed actor occurrences advertises v=2 and coverage=disclosed, with its permitted delivery modes. Actor identity requirements remain authenticated application policy; this metadata does not expose hidden actors or define a general policy language. A recipient MUST reject missing locally required actors or evidence. Verification by another recipient does not replace a local requirement unless explicit local policy authorizes that trust.¶

When a resource receives no token or an insufficient token, it MAY use the RFC 9728 WWW-Authenticate resource_metadata parameter to direct the client to its metadata. An evidence-specific diagnostic MUST NOT become an unauthenticated alternative source of policy and MUST NOT reveal hidden actors.¶

A resource that bases authorization on the immediate actor being the live presenter MUST also require sender-constrained presentation that binds the issued token to a key controlled by that authenticated actor. DPoP [RFC9449] is the concrete interoperable realization defined here: the AS binds the current actor and proof-of-possession key during issuance, the token carries cnf.jkt, and the resource validates the DPoP proof, access-token hash, and JWK thumbprint [RFC7638]. Another standardized sender-constraining mechanism MAY be used by agreement only when it provides an unambiguous token-to-key binding, the AS binds that key to the same authenticated current actor, and the resource validates possession on presentation. Client authentication or a protected transport channel alone does not establish this property.¶

17. Authorization Server Metadata

An AS publishes the following RFC 8414 [RFC8414] metadata:¶

{
  "actor_chain_bootstrap_endpoint":
    "https://as.example/actor-chain/bootstrap",
  "actor_chain_capabilities": {
    "profiles": [
      "declared-full", "declared-subset", "declared-actor-only",
      "verified-full", "verified-subset", "verified-actor-only"
    ],
    "proof_versions": [
      2
    ],
    "commitment_versions": [
      2
    ],
    "evidence_versions": [
      1, 2
    ],
    "coverage": ["current", "path", "disclosed"],
    "delivery": ["inline", "introspection"],
    "limits": { "max_depth": 10, "max_inline_bytes": 32768 }
  },
  "identity_chaining_requested_token_types_supported": [
    "urn:ietf:params:oauth:token-type:actor-chain-preserve"
  ]
}

actor_chain_bootstrap_endpoint is the URL of the endpoint defined in Section Section 14.1. An AS supporting Actor Chain root issuance, including Declared profiles, MUST advertise this endpoint. The actor_chain_capabilities value is a JSON object whose members advertise the supported profiles, artifact versions, evidence coverage and delivery modes, and issuance limits shown above. An implementation MUST ignore unknown members of that object unless another specification defines otherwise.¶

Clients MUST verify the metadata issuer and MUST NOT assume an omitted capability. The limits object is informational about advertised issuance limits; every participant still enforces its own configured acceptance limits.¶

An AS advertising disclosed MUST advertise evidence version 2. Version 1 support covers only advertised current and/or path; version 2 support covers only disclosed. Clients MUST select the exact supported version and coverage required by authenticated resource policy. A legacy version 1 implementation rejects version 2 rather than accepting reduced evidence.¶

18. Validation

19. Cross-Domain Preservation

Cross-domain preservation uses OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] rather than a parallel Actor Chain exchange flag.¶

The source-domain AS performs RFC 8693 Token Exchange targeted to the destination AS and requests the provisional token type:¶

urn:ietf:params:oauth:token-type:actor-chain-preserve

The resulting JWT authorization grant is used at the destination AS as defined by [RFC7523] and the Identity Chaining specification. Its ordinary JWT claims include iss, sub, aud, iat, exp, and jti. Its Actor Chain protected state includes exact actp and acti, plus actc and any carried acte in Verified profiles. Declared grants MUST NOT carry actc or acte. An introspection descriptor MUST remain unchanged; it is not expanded inside the grant. Evidence custody needed to satisfy that descriptor MUST be established through authorized source introspection or a separately authenticated AS-to-AS mechanism. This specification does not define a separate custody-transfer encoding. If the destination AS cannot obtain and serve the required evidence for its issued token, it MUST reject preservation.¶

Disclosure remains profile-controlled during preservation. Full and Actor-Only act values MUST be preserved exactly. A Subset act MAY be preserved or further narrowed to an ordered subsequence but MUST NOT be broadened. An omitted act MUST NOT be reconstructed from hidden state.¶

When current, disclosed, or path evidence is carried or referenced, the corresponding act MUST be preserved exactly so that coverage and occurrence bindings remain valid. A Subset act may be narrowed during preserve only when no acte is carried or referenced. A later ordinary extend can apply a different authorized Subset disclosure; preserve MUST NOT silently filter the protected evidence or rewrite its signed records.¶

Identity Chaining permits claims transcription. This Actor Chain token type is a narrow profile of that behavior: the source and destination AS MUST NOT add, remove, alter, or normalize the protected state. actp, acti, and any carried actc require exact value equality, and every compact proof or acceptance string in acte MUST be preserved byte-for-byte. Re-serializing the enclosing JSON does not change those values. Ordinary identity and authorization claims MAY be transcribed only as the enclosing protocol and local policy allow. The destination AS MUST reject if it cannot validate and preserve the protected state or cannot satisfy the authenticated destination resource's evidence requirement.¶

A preserve transition creates no proof and no acceptance. A later actor under the destination AS performs a normal extend; its proof hashes the exact foreign actc, and the destination AS creates one new local actc. Path evidence therefore retains original signer provenance:¶

proof_A / actc_A  signed by A / AS1
proof_B / actc_B  signed by B / AS2
proof_C / actc_C  signed by C / AS3

An AS cannot synthesize missing historical path evidence after the relevant proofs or openings have been discarded. If a later resource may require path coverage, the required evidence must be retained and preserved across every boundary. Failure is preferable to silent downgrade or privacy-violating reconstruction.¶

The same custody requirement applies to selected originals needed for disclosed. An AS-to-AS exchange must establish accepted-path membership from authenticated preserved state or retained predecessor records before a destination AS attests a new selection. No recipient is required to receive hidden state for this purpose. Lack of authoritative association or authorized evidence custody causes rejection when selected evidence is required.¶

Subject, audience, resource, or scope translation is a separate trust boundary. Audience mappings are AS-local and are not copied into actor proofs. A destination AS MAY use an authorized and auditable subject, target, or scope mapping, but MUST NOT describe the mapping as actor-proven semantic equivalence. Unknown mappings are rejected. An authorized mapping does not relax recipient evidence validation. When direct evidence is required, the preserved final proof MUST still satisfy the destination resource's exact resource and lexical-scope comparisons. A mapping that cannot satisfy those comparisons requires a fresh authorized extend and actor proof; otherwise preservation MUST be rejected.¶

Preservation never rewrites a historical proof's resource or scope. A later actor may make a normal extend transition only by signing a fresh proof over that transition's exact local resource and scope. That proof can establish current coverage for the new actor and local values; it does not make earlier actors' signatures attest to those local values. If the destination AS cannot authorize the transition, it MUST reject. For a later ordinary extend, the AS MAY issue commitment-only assurance when historical evidence is unavailable only if both the authenticated resource requirement and local policy permit that posture; otherwise it MUST reject. This option does not permit a preserve transition to remove or alter carried protected acte. Inability to preserve required evidence causes rejection. Resource URIs at different hops are not required to be equal or lexically nested.¶

20. Replay, Retry, And Fan-Out

The accepting AS MUST enforce input-size limits and authenticate the current requester before consulting replay state. Before reserving a previously absent key, it MUST also complete signature, predecessor, target, authority, opening, freshness, and other semantic checks. It then enforces atomic uniqueness of:¶

(accepting_issuer, actor.iss, actor.sub, acti, request_id)

Malformed, unauthenticated, unauthorized, or otherwise invalid input MUST NOT consume this key. A previously absent key can be accepted only while the proof is fresh. The AS MUST create a durable pending record binding the key to the exact proof, or its SHA-256 step_hash, using one linearizable replay-state operation.¶

The AS then creates actc and atomically finalizes the record with that exact compact artifact before returning success. A computed but uncommitted actc MUST NOT be returned. A different proof at the same key MUST be rejected even while the winner is pending. Identical concurrent requests MUST converge on at most one committed actc; other workers return that artifact after commit or fail without returning success. Crash takeover MUST fence stale workers so they cannot finalize or emit a different result.¶

An exact retry matched by a retained committed record is idempotent and reuses the exact stored actc; it does not create a new acceptance. The AS MAY rely on the committed record for an originally valid one-time bootstrap context or grant that the first request consumed. It SHOULD return the original success response. If it instead issues a new token carrying the same Actor Chain state, the token MUST NOT have broader authority, evidence, or an authorization horizon later than the original response. The AS MUST still authenticate the current request and apply current token-issuance, target, sender-constraint, disclosure, evidence, and authorization policy. Failure of a current check rejects the request without changing the committed record. Because no new acceptance occurs, the original proof need not remain fresh at retry time.¶

Replay state MUST be durable and linearizable across the AS deployment. After success has been returned, failover MUST NOT expose state older than that commit. A node that cannot consult or durably update authoritative replay state during partition or failover MUST NOT return success.¶

The AS MUST retain the key, proof-match value, exact actc, and the response state needed to enforce the preceding retry limits through the later of the proof acceptance interval, including clock-skew allowance, and the deployment's maximum supported exact-retry delay measured from first acceptance. Retention MUST NOT slide on retry. The supported retry delay SHOULD be at least the proof acceptance window plus permitted clock skew. After this state expires, idempotent retry is no longer guaranteed and ordinary proof freshness still applies. Implementations MAY store fixed-length cryptographic hashes of replay identifiers to bound storage and reduce raw identifier exposure.¶

Distinct request_id values MAY create authorized fan-out from one predecessor. The accepting issuer scopes the replay domain: each AS enforces the rule for actor transitions it accepts, while preserve creates no actor proof and no Actor Chain transition replay record. Replay handling for the enclosing grant remains governed by its applicable specifications. This document does not define branch merging, sibling enumeration, or proof of branch uniqueness.¶

21. Error And Challenge Handling

Token endpoint errors use OAuth [RFC6749] and RFC 8693 [RFC8693] error values. This table classifies Actor Chain failures; ordinary OAuth failures retain the errors defined by their governing specifications.¶

Loss of authoritative replay state is not evidence that a grant is invalid. If the AS cannot consult or durably update that state, or cannot determine whether an identical pending request committed within its bounded wait, it MUST return HTTP 503 (Service Unavailable) [RFC9110] and MUST NOT return success or invalid_grant. It SHOULD include Retry-After. The external response MUST NOT reveal whether the replay key is absent, pending, or committed. No Actor Chain-specific OAuth error value is defined for this condition.¶

After such a 503, the requester SHOULD retry the exact token request after the indicated delay. The compact proof and its signed request_id MUST remain unchanged. A new request_id requires a fresh actor proof and represents a distinct transition that can create authorized fan-out; it MUST NOT be used merely to recover an uncertain result. If the first request committed, the exact retry returns the retained success as specified in Section Section 20. If it did not commit, ordinary proof freshness still applies.¶

A protected resource uses the applicable token authentication scheme and the RFC 9728 resource_metadata challenge parameter to point to its authoritative metadata. A request without a token uses HTTP 401 and omits an OAuth error as required by RFC 6750 [RFC6750]. A presented token whose Actor Chain evidence is absent, weaker than required, malformed, or invalid uses the generic invalid_token error and HTTP 401; the challenge SHOULD include resource_metadata and SHOULD omit error_description. Ordinary OAuth scope insufficiency remains insufficient_scope with HTTP 403; Actor Chain evidence posture MUST NOT be mislabeled as scope.¶

For example:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token",
  resource_metadata="https://r.example/m"

If the resource cannot validate required evidence because an introspection, key/status, or authenticated-metadata dependency is temporarily unavailable, it MUST fail closed with HTTP 503, SHOULD include Retry-After, MUST NOT label the token invalid_token, and MUST NOT downgrade the evidence requirement. The presenter SHOULD retry the same token after the indicated delay.¶

An insufficient-evidence challenge can lead the presenter to initiate a fresh exchange. The AS does not mutate or upgrade the rejected token; it issues a new token only after revalidating authority, evidence availability, disclosure authorization, and resource limits.¶

Error bodies and logs MUST NOT reveal hidden actors, openings, proofs, keys, or policy details beyond the requesting party's authorized disclosure. They also MUST NOT reveal which hidden step failed, whether historical evidence exists, or whether replay state was absent, pending, or committed.¶

22. Resource Limits

Implementations MUST enforce configured byte limits before deep parsing, cryptographic work, decompression, or external retrieval. They MUST also bound chain depth, evidence steps, protected-header bytes, signatures, distinct issuers, key lookups, redirects, introspection response bytes, and network time.¶

The following defaults are RECOMMENDED starting points, not universal transport guarantees:¶

Local policy MAY use lower limits. Exceeding a limit fails profile processing. Signature and key-selection limits count nested actor proofs and AS acceptances; ordinary token and sender-constraint validation are separate OAuth work. Depth 10 therefore requires 20 nested verifications plus the token signature. Twenty authorities allow every nested signer to differ without increasing that work budget.¶

The 32768-byte ceiling applies both to inline tokens and expanded introspection acte; the entire HTTP message is independently bounded. One validation attempt MUST NOT make more than one Actor Chain introspection request. Signed targets are never dereferenced. Key and metadata retrieval use authenticated or preconfigured endpoints, bounded issuer caches, local redirect and timeout policy, and the fail-closed behavior in Section Section 21.¶

The measured depth-10 Full-path fixture is 23673 bytes inline and 16303 bytes expanded. These sizes are illustrative; actual sizes depend on identifiers, scopes and encoding and MUST satisfy configured limits. actc and current overhead remain approximately constant for fixed identifier and scope sizes. Full disclosure and the number of path signatures grow linearly with depth. Because each path opening repeats the growing actor-view array, aggregate opening size and processing grow quadratically.¶

Disclosed evidence work grows with the number of disclosed occurrences, not with hidden steps. The existing limits apply to it unchanged. The quoted measurements describe the preceding Full-path fixture, not a measurement of this newly specified coverage mode.¶

23. JWT, JWS, And Introspection Binding

JWT access tokens SHOULD use typ=at+jwt. Actor proofs use typ=oauth-act-step+jwt; AS acceptances use typ=oauth-actc+jwt; preserve grants use typ=oauth-act-preserve+jwt.¶

For Actor Chain proof, acceptance, and preserve JWS objects, the protected header contains exactly alg, kid, and typ. Implementations of this specification MUST implement ES256 [RFC7518]. Producers MUST use ES256 unless support for another algorithm has been established for every intended verifier through authenticated metadata, configuration, or prior agreement. Any additional algorithm MUST be a registered, fully specified asymmetric signature algorithm [RFC9864] that is allowed by current verifier policy. The deprecated polymorphic EdDSA identifier, alg=none, and symmetric algorithms MUST NOT be accepted. This version's interoperability vectors use ES256.¶

Before processing a signature, the verifier MUST fix the allowed algorithm set for that typ; an attacker-controlled alg value cannot enlarge it. Each trusted key record MUST bind the key to exactly one algorithm, signer identity, and permitted Actor Chain artifact type. The JWS alg, key type, curve or parameters, and any JWK alg, use, or key_ops restrictions MUST agree. Implementations MUST use mutually exclusive validation rules for each typ as required by [RFC8725].¶

kid is a lookup hint within an issuer-qualified trust namespace, not a global identity or trust assertion. A verifier resolves the tuple of expected signer, kid, alg, typ, and applicable event time and MUST reject no match or an ambiguous match. A key's presence in a JWKS alone does not authorize an ActorID or AS to sign that artifact type. Signers MUST NOT reuse a kid for another key or signer within the period in which an artifact under the prior key can be accepted. The closed header excludes attacker-selected key URLs. Network key resolution MUST use only preconfigured or authenticated issuer metadata and MUST be bounded and cached by issuer; a verifier MUST NOT dereference an untrusted issuer or header value.¶

The closed protected-header set is intentional for proof and acceptance version 2. An additional protected header, including crit, requires a future version or an update to this specification; it MUST NOT be silently accepted by a version 2 parser. This rule prevents unreviewed key-selection or processing semantics from entering the signed-artifact contract.¶

Proof and acceptance payloads use ordinary UTF-8 JSON. Their linkage hashes the exact compact JWS strings and therefore does not require whole-payload JCS. JCS is used for actor-view commitments and the serialized opening request parameter. JWK thumbprints use the member-selection and serialization rules of [RFC7638]. Parsers MUST reject duplicate members, malformed UTF-8, base64url padding, unknown payload members, wrong JSON types, non-integer NumericDate values, and unsupported versions before semantic acceptance.¶

An RFC 7662 introspection endpoint returning Actor Chain evidence MUST:¶

• authenticate and authorize the caller for the resource and requested evidence;¶

• process the exact presented token;¶

• return only evidence the caller is permitted to learn;¶

• return active=false without evidence when the token is inactive or the authenticated caller is not authorized to learn state about that token;¶

• apply the same limits and validation rules as inline evidence; and¶

• prevent cached evidence from outliving applicable token, revocation, privacy, or key-status constraints.¶

Invalid caller credentials or insufficient endpoint privileges use the applicable RFC 7662 authentication error, rather than an active=false response. An authorized query for a token the caller is not permitted to inspect returns active=false without evidence.¶

Availability and latency of introspection are deployment properties. A resource requiring introspection delivery fails closed when it cannot obtain a valid response.¶

24. Security Considerations

25. Privacy Considerations

Full path evidence reveals actors, organizations, order, targets, timing, and stable workflow correlation. It is therefore optional and restricted to Full disclosure in this version. A resource and AS SHOULD select the minimum evidence satisfying the resource's authenticated requirement.¶

current evidence contains no actor-view opening and is compatible with Subset and Actor-Only disclosure. It still reveals the current actor, accepting AS, workflow identifier, target, scope, and time. acti MUST be opaque and workflow-local. Actor and subject identifiers SHOULD be pairwise or pseudonymous where possible.¶

The AS observes the authenticated actor and opening even when the recipient does not. Evidence stores, replay records, and introspection services therefore concentrate sensitive relationship and correlation data. Operators MUST enforce purpose-limited access, encryption, retention limits, disclosure logging, and audience filtering. Replay records SHOULD be removed when their required retention ends. Replication for availability MUST NOT silently broaden disclosure.¶

A Subset sequence is an ordered subsequence, not proof of adjacency or complete history. Recipients MUST treat omitted actors as unknown. Selective-disclosure or encrypted overlays MAY be used by agreement but MUST preserve the base profile's semantics and must not weaken validation [RFC9901].¶

disclosed omits actor-view openings but can reveal historical targets, AS identities, subject aliases, times, and linkable digests. It promises only the disclosure permitted by the complete-record policy check, not anonymity of every omitted service. Existing plain JWS records cannot be selectively redacted. A future SD-JWT proof profile would need its own artifact and hashing contract; this version reuses original compact JWS records unchanged.¶

26. IANA Considerations

This document requests the registrations below. The Change Controller for all of them is the IETF.¶

27. Worked Token Examples

Assume A -> B -> C -> D, where C is the live presenter to protected resource D. The JSON below consists of excerpts and illustrative placeholders, not complete deployable tokens. Required claims omitted from an excerpt remain required by the data model; cryptographic artifacts and openings are shown symbolically.¶

{
  "iss": "https://as3.example",
  "sub": "workflow-subject-alias",
  "aud": ["https://d.example"],
  "scope": "payments.read payments.submit",
  "actp": "verified-actor-only",
  "acti": "workflow-7",
  "act": { "iss": "https://actors.example/c", "sub": "C" },
  "actc": "<actc_C>",
  "cnf": { "jkt": "<C presenter-key thumbprint>" }
}

{
  "actp": "verified-actor-only",
  "acti": "workflow-7",
  "act": { "iss": "https://actors.example/c", "sub": "C" },
  "actc": "<actc_C>",
  "acte": {
    "v": 1,
    "coverage": "current",
    "delivery": "inline",
    "steps": [
      { "proof": "<proof_C>", "acceptance": "<actc_C>" }
    ]
  },
  "cnf": { "jkt": "<C presenter-key thumbprint>" }
}

{
  "actp": "verified-full",
  "acti": "workflow-7",
  "actc": "<actc_C>",
  "acte": {
    "v": 1,
    "coverage": "path",
    "delivery": "inline",
    "steps": [
      { "proof": "<proof_A>", "acceptance": "<actc_A>",
        "opening": "<opening_A>" },
      { "proof": "<proof_B>", "acceptance": "<actc_B>",
        "opening": "<opening_B>" },
      { "proof": "<proof_C>", "acceptance": "<actc_C>",
        "opening": "<opening_C>" }
    ]
  }
}

"acte": { "v": 1, "coverage": "current",
          "delivery": "introspection" }

{
  "actp": "verified-subset",
  "acti": "workflow-7",
  "act": {
    "iss": "https://actors.example/c",
    "sub": "C",
    "act": { "iss": "https://actors.example/a", "sub": "A" }
  },
  "actc": "<actc_C>",
  "acte": {
    "v": 2,
    "coverage": "disclosed",
    "delivery": "inline",
    "steps": [
      { "proof": "<proof_A>", "acceptance": "<actc_A>" },
      { "proof": "<proof_C>", "acceptance": "<actc_C>" }
    ]
  }
}

28. Deployment Choices

The resource starts with the narrowest assurance question it actually needs:¶

Inline delivery favors availability and independent retention but increases token and logging exposure. Introspection favors smaller requests and centralized authorization but adds live dependency and cache policy. Neither delivery changes what the signatures prove.¶

One application domain's manager, approver, or operator concept may not mean the same thing in another domain. Such policy remains with the application and its authorization systems. Actor Chain standardizes only mechanically comparable OAuth scope tokens and protocol state.¶

29. Design Rationale

30. Executable Test Vectors And Independent Validation

To reduce byte-level ambiguity and improve interoperability confidence, this specification includes structured examples and explicit failure rules. The authors retain local test vectors for the preceding current/path contract and a focused selected-evidence fixture for this revision. Those materials are not incorporated as external dependencies of this document. This revision's new coverage mode still requires independent implementation and interoperability review; preceding test results do not establish those properties for it.¶

These materials are informative. They do not replace the normative requirements, independent implementation review, or security analysis. They provide examples for checking exact-artifact hashing, canonicalization, linkage, disclosure, rejection, limits, replay, and errors. Implementation languages used by the package are not part of the protocol contract.¶

31. Implementation Checklist

An implementation claiming conformance should be able to answer yes to each applicable item:¶

• Is profile selection explicit and immutable for acti?¶

• Are actor and AS keys authorized for the exact issuer-qualified identity and event time?¶

• Are duplicate JSON members, unknown fields, wrong types, and unsupported versions rejected?¶

• Does extend hash the exact prior compact actc?¶

• Is the final resource exactly equal, and is lexical scope equal or narrowed?¶

• Does current omit every actor-view opening?¶

• Does disclosed match every disclosed occurrence in order, omit openings, verify all selected signatures, and require exact final-head equality?¶

• Does the issuer establish selected membership from authoritative accepted state, enforce complete-record privacy, and avoid substitution from branches?¶

• Is path continuous, Full-disclosure, bounded, and final-head-equal?¶

• Does required evidence fail closed on absence or introspection failure?¶

• Is reliance on the immediate actor as the live presenter sender constrained?¶

• Do exact retries reuse one committed actc while current issuance policy still applies?¶

• Are replay records durable and linearizable, with stale workers fenced and unavailable partitions failing closed?¶

• Does cross-domain handling preserve protected state values and compact artifacts without transcription?¶

• Are byte, depth, signature, issuer, key-lookup, and network limits applied before attacker-amplified work?¶

• Are evidence custody, historical key context, and privacy retention aligned with every audit claim made to relying parties?¶

32. Future Work

Receiver acknowledgments, terminal result receipts, arbitrary suffix or independently verified selective path membership, branch transparency, evidence export after token expiry, and additional discovery or interoperability profiles for sender-constraining mechanisms are candidates for companion work. They are not required to implement this base protocol.¶

33. Relationship To RFC 8693

This section is informative.¶

34. Relationship to Other Work

This section is informative.¶

Holder-issued chains support delegation without an AS exchange at every step [DELEGATE-SD-JWT]. Actor Chain retains AS issuance policy and varies evidence delivery by resource requirements. These are deployment tradeoffs. SD-JWT provides selective disclosure of signed fields [RFC9901]; this version's selected original JWS evidence does not define a new field-redaction format.¶

35. Agent and Workload Integration

This section is informative. Actor Chain operates at authorization transitions; it does not change MCP tool messages, A2A task semantics, or Kubernetes RBAC. The example is A, an orchestrator, calling B, an A2A planner; B calling C, an MCP connector; and C calling D, a Kubernetes-hosted API.¶

MCP HTTP authorization specifies Bearer presentation and authenticated resource discovery [MCP-AUTH]. A conforming deployment retains resource-specific tokens instead of forwarding C's inbound MCP token to D. Actor Chain requires support at the AS, exchange client, and resource verifier; ordinary OAuth middleware does not implement these extensions automatically. Local MCP stdio does not use the HTTP authorization flow.¶

DPoP-bound access tokens use the DPoP authentication scheme. A Bearer-only MCP transport therefore does not implement this specification's concrete DPoP presentation merely by adding a proof header. An explicitly agreed RFC 8705 certificate-bound deployment [RFC8705] can retain Bearer presentation when the AS associates the certificate key with the authenticated current actor and the resource verifies its token binding and TLS possession. This is an application of the existing sender-constraint alternative, not a new interoperability profile. If metadata requires DPoP, mTLS is not a fallback. A TLS-terminating gateway needs a trusted certificate-validation boundary; a forwarded certificate header alone does not establish possession.¶

A2A advertises security schemes and obtains credentials outside task messages [A2A-SPEC]. Its task or context identifier is not acti. Polling, streaming, and token refresh do not automatically create actor steps. Step-up authority needs fresh authorization; it does not enlarge previously signed scope.¶

Kubernetes projected service-account tokens can authenticate workloads under an explicit trust and audience policy [K8S-SA]. They are issuer-signed credentials, not actor step signatures or token-to-key bindings. Verified actors additionally use authorized signing keys with retained event-time bindings. Shared service identities do not imply distinct pod attribution. A signing proxy is attributed according to its authenticated identity; its signature does not become an unmodified application's own signature.¶

Before signing, clients select the exact resource identifier from authenticated metadata. Resource-verifier adapters apply the exact signed-resource comparison even when ordinary URL or audience middleware normalizes equivalent spellings.¶

An inbound DPoP binding belongs to the actor that presented the token to the receiving service. Receiving that token does not transfer the sender's private key. The AS needs an explicitly authorized recipient-exchange policy that preserves applicable subject-token checks and authenticates the new actor. Token possession, client authentication, and a new step signature do not prove possession of the original sender's key. This is a deployment prerequisite to the example; AS-specific behavior needs integration testing before claiming end-to-end interoperability.¶

The Kubernetes API server and its RBAC policy are not implicitly extended by Actor Chain. Deployment requires explicit application or gateway validation; workload identity and ordinary cluster auditing do not implement these rules.¶

Authors' Addresses