



Web Authorization Protocol                                 K. McGuinness
Internet-Draft                                               Independent
Intended status: Standards Track                           30 April 2026
Expires: 1 November 2026


                   OAuth Actor Profile for Delegation
                draft-mcguinness-oauth-actor-profile-00

Abstract

   OAuth deployments increasingly involve agents and workloads acting on
   behalf of human users across organizational boundaries.  Existing
   specifications provide relevant building blocks (notably the act
   claim from RFC 8693 Token Exchange) but do not define a consistent
   profile for representing delegated actor relationships across JWT
   assertion grants (RFC 7523), JWT access tokens (RFC 9068), and
   Transaction Tokens, nor for classifying actor entity types or
   signaling support between authorization servers and resource servers.
   The result is inconsistent actor representation and actor-
   representation interoperability gaps that force deployments to rely
   on proprietary conventions.

   This document defines the OAuth Actor Profile for Delegation.  It
   specifies a common act claim structure extended with sub_profile for
   entity-type classification, processing rules for authorization
   servers and resource servers across the three token families and
   their Token Exchange inputs, and OAuth discovery metadata parameters
   for advertising actor-profile support.  The profile applies uniformly
   across token types and integrates with existing sender-constraint
   mechanisms (DPoP, mTLS).  It does not standardize the policies by
   which systems determine whether a given actor is permitted to act for
   a subject; those decisions remain deployment-specific.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://mcguinness.github.io/draft-mcguinness-oauth-actor-profile/
   draft-mcguinness-oauth-actor-profile.html.  Status information for
   this document may be found at https://datatracker.ietf.org/doc/draft-
   mcguinness-oauth-actor-profile/.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.
   Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.



McGuinness               Expires 1 November 2026                [Page 1]

Internet-Draft             OAuth Actor Profile                April 2026


   Source for this draft and an issue tracker can be found at
   https://github.com/mcguinness/draft-mcguinness-oauth-actor-profile.

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 1 November 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  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Illustrative Use Case . . . . . . . . . . . . . . . . . .   7
     1.2.  Relationship to Related Work  . . . . . . . . . . . . . .   7
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   8
   3.  Actor Profile for Delegation  . . . . . . . . . . . . . . . .   9
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Profile Invariants  . . . . . . . . . . . . . . . . . . .  10
     3.3.  Profile Scope . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Representation and Policy . . . . . . . . . . . . . .  11
       3.3.2.  Token Format Scope  . . . . . . . . . . . . . . . . .  11
       3.3.3.  Supported Token Types and Request Semantics . . . . .  12
     3.4.  Actor Object Structure  . . . . . . . . . . . . . . . . .  13



McGuinness               Expires 1 November 2026                [Page 2]

Internet-Draft             OAuth Actor Profile                April 2026


     3.5.  Delegation Chains . . . . . . . . . . . . . . . . . . . .  15
     3.6.  Delegation Chain Validation and Construction  . . . . . .  17
       3.6.1.  Terminology . . . . . . . . . . . . . . . . . . . . .  18
       3.6.2.  Validation Steps  . . . . . . . . . . . . . . . . . .  18
       3.6.3.  Construction Steps  . . . . . . . . . . . . . . . . .  20
     3.7.  Sender Constraint and Proof-of-Possession Validation  . .  22
       3.7.1.  Top-Level cnf Governs the Current Presenter . . . . .  22
       3.7.2.  Token Exchange Continuation . . . . . . . . . . . . .  23
       3.7.3.  Token Exchange Rebind . . . . . . . . . . . . . . . .  23
       3.7.4.  Bearer-to-PoP Upgrade . . . . . . . . . . . . . . . .  24
   4.  JWT Assertion Grants  . . . . . . . . . . . . . . . . . . . .  24
     4.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  24
     4.2.  Authorization Grant Processing  . . . . . . . . . . . . .  27
   5.  JWT Access Tokens . . . . . . . . . . . . . . . . . . . . . .  30
     5.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  30
     5.2.  Delegated Token Issuance  . . . . . . . . . . . . . . . .  32
   6.  Token Exchange Processing . . . . . . . . . . . . . . . . . .  33
     6.1.  Presenter Transition Model  . . . . . . . . . . . . . . .  34
     6.2.  Subject Tokens  . . . . . . . . . . . . . . . . . . . . .  36
       6.2.1.  Token-State Subject Tokens  . . . . . . . . . . . . .  36
       6.2.2.  Identity-Only Subject Tokens  . . . . . . . . . . . .  39
     6.3.  Actor Tokens  . . . . . . . . . . . . . . . . . . . . . .  43
       6.3.1.  JWT Client Assertion  . . . . . . . . . . . . . . . .  43
       6.3.2.  Workload Identity Credential  . . . . . . . . . . . .  45
       6.3.3.  JWT Access Token  . . . . . . . . . . . . . . . . . .  47
     6.4.  may_act . . . . . . . . . . . . . . . . . . . . . . . . .  48
     6.5.  Output Token Rules  . . . . . . . . . . . . . . . . . . .  49
       6.5.1.  JWT Assertion Grant Output  . . . . . . . . . . . . .  50
       6.5.2.  JWT Access Token Output . . . . . . . . . . . . . . .  50
   7.  Transaction Token Service Processing  . . . . . . . . . . . .  54
     7.1.  Transaction Tokens  . . . . . . . . . . . . . . . . . . .  54
       7.1.1.  Actor Claim in Transaction Tokens . . . . . . . . . .  55
     7.2.  Presenter Authentication and Transition . . . . . . . . .  56
     7.3.  Supported Subject Tokens  . . . . . . . . . . . . . . . .  57
       7.3.1.  JWT Assertion Grant . . . . . . . . . . . . . . . . .  57
       7.3.2.  JWT Access Token  . . . . . . . . . . . . . . . . . .  57
       7.3.3.  Transaction Token . . . . . . . . . . . . . . . . . .  58
     7.4.  Transaction Token Output Rules  . . . . . . . . . . . . .  58
   8.  Resource Server Processing  . . . . . . . . . . . . . . . . .  61
     8.1.  Actor Authorization . . . . . . . . . . . . . . . . . . .  61
     8.2.  JWT Access Token Processing . . . . . . . . . . . . . . .  63
     8.3.  Transaction Token Processing  . . . . . . . . . . . . . .  65
     8.4.  Token Introspection . . . . . . . . . . . . . . . . . . .  66
   9.  Error Responses . . . . . . . . . . . . . . . . . . . . . . .  68
   10. Metadata and Discovery  . . . . . . . . . . . . . . . . . . .  71
     10.1.  Authorization Server Metadata  . . . . . . . . . . . . .  71
     10.2.  Protected Resource Metadata  . . . . . . . . . . . . . .  74
     10.3.  Transaction Token Capability Signaling . . . . . . . . .  76



McGuinness               Expires 1 November 2026                [Page 3]

Internet-Draft             OAuth Actor Profile                April 2026


     10.4.  Capability Signaling Usage . . . . . . . . . . . . . . .  76
   11. Companion Profiles and Extension Points . . . . . . . . . . .  77
   12. Deployment Considerations . . . . . . . . . . . . . . . . . .  78
     12.1.  Migration and Adoption . . . . . . . . . . . . . . . . .  78
       12.1.1.  RFC 8693 Backwards Compatibility . . . . . . . . . .  78
       12.1.2.  Migrating from Implicit to Explicit Delegation . . .  79
     12.2.  Trusting Actor Identifier Pairs  . . . . . . . . . . . .  81
     12.3.  Token Lifetime for Delegation Chains . . . . . . . . . .  82
   13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . .  83
     13.1.  Issuing Authorization Server . . . . . . . . . . . . . .  83
     13.2.  Transaction Token Service  . . . . . . . . . . . . . . .  83
     13.3.  Resource Server  . . . . . . . . . . . . . . . . . . . .  84
     13.4.  Client . . . . . . . . . . . . . . . . . . . . . . . . .  84
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  85
     14.1.  Delegation Chain Integrity and Trust . . . . . . . . . .  85
     14.2.  Self-Issued Authorization Grants . . . . . . . . . . . .  85
     14.3.  Assertion Replay Prevention  . . . . . . . . . . . . . .  87
     14.4.  Token Substitution . . . . . . . . . . . . . . . . . . .  87
     14.5.  Confused Deputy  . . . . . . . . . . . . . . . . . . . .  87
     14.6.  Actor-Authorization Bypass . . . . . . . . . . . . . . .  87
     14.7.  Client Identity and Delegation . . . . . . . . . . . . .  88
     14.8.  sub_profile Trust  . . . . . . . . . . . . . . . . . . .  89
     14.9.  Subject Namespace Translation  . . . . . . . . . . . . .  89
     14.10. Presenter Binding  . . . . . . . . . . . . . . . . . . .  90
     14.11. Delegation Depth Limits  . . . . . . . . . . . . . . . .  90
     14.12. Actor Identity Rotation  . . . . . . . . . . . . . . . .  90
     14.13. Delegation Revocation  . . . . . . . . . . . . . . . . .  91
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  91
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  93
     16.1.  OAuth URI Registration . . . . . . . . . . . . . . . . .  93
     16.2.  OAuth Authorization Server Metadata Registry . . . . . .  93
     16.3.  OAuth Protected Resource Metadata Registry . . . . . . .  93
     16.4.  OAuth Error Registry . . . . . . . . . . . . . . . . . .  94
     16.5.  OAuth Token Introspection Response Registry  . . . . . .  94
     16.6.  JWT Claims Registry  . . . . . . . . . . . . . . . . . .  95
     16.7.  OAuth Token Type Registry  . . . . . . . . . . . . . . .  95
     16.8.  OAuth Entity Profiles Registry . . . . . . . . . . . . .  95
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  95
     17.1.  Normative References . . . . . . . . . . . . . . . . . .  95
     17.2.  Informative References . . . . . . . . . . . . . . . . .  98
   Appendix A.  Service-to-Service Delegation Example  . . . . . . .  99
     A.1.  Scenario  . . . . . . . . . . . . . . . . . . . . . . . .  99
     A.2.  Access Token  . . . . . . . . . . . . . . . . . . . . . .  99
     A.3.  Transaction Token . . . . . . . . . . . . . . . . . . . . 100
   Appendix B.  Cross-Domain AI Agent Flow: ID Token to Transaction
           Token . . . . . . . . . . . . . . . . . . . . . . . . . . 101
     B.1.  Scenario and Parties  . . . . . . . . . . . . . . . . . . 101
     B.2.  Capability Discovery (Preflight)  . . . . . . . . . . . . 103



McGuinness               Expires 1 November 2026                [Page 4]

Internet-Draft             OAuth Actor Profile                April 2026


     B.3.  Step 1: User Authentication (ID Token)  . . . . . . . . . 104
     B.4.  Step 2: Enterprise Token Exchange (ID Token to ID-JAG)  . 105
     B.5.  Step 3: Agent Exchanges ID-JAG for Access Token at Travel
           Provider AS . . . . . . . . . . . . . . . . . . . . . . . 106
     B.6.  Step 4: Agent Calls Booking Tool API  . . . . . . . . . . 107
     B.7.  Step 5: Booking Tool Exchanges Access Token for Transaction
           Token . . . . . . . . . . . . . . . . . . . . . . . . . . 108
     B.8.  Step 6: Booking Tool Calls Inventory Service  . . . . . . 109
     B.9.  Summary of Token Transformations  . . . . . . . . . . . . 110
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 111
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 111

1.  Introduction

   When an agent acts on behalf of a user across trust domains, every
   system in the path needs to know who authorized the request and who
   is making it.  Existing specifications provide relevant building
   blocks ([RFC8693] introduced the act claim for Token Exchange) but do
   not define a consistent, interoperable way to represent delegated
   actor relationships across JWT assertion grants, JWT access tokens,
   and Transaction Tokens, nor how common Token Exchange input
   credentials should feed that representation.

   Several actor-representation interoperability gaps result from the
   absence of such a profile:

   *  *No standard entity classification.* The sub claim is routinely
      overloaded to represent heterogeneous entity types (end users,
      service accounts, AI agents, and workloads) without a standard
      classification mechanism, preventing deterministic cross-domain
      policy evaluation.

   *  *Inconsistent actor representation across token types.* Actor
      context, including key material associated with the acting party,
      has no standard representation that survives token transformation,
      as JWT assertion grants, JWT access tokens, and Transaction Tokens
      are specified in separate documents with differing claim
      conventions.

   *  *Implicit delegation via client identity.* Many deployments
      address actor representation through implicit delegation,
      inferring the acting party from the OAuth client identity
      (client_id or azp); this approach does not generalize to
      deployments where a single client registration fronts multiple
      agents, where requests pass through intermediary services, or
      where tokens cross organizational trust boundaries, because the
      client registration does not uniquely identify the runtime actor
      in those cases.



McGuinness               Expires 1 November 2026                [Page 5]

Internet-Draft             OAuth Actor Profile                April 2026


   *  *No discovery for actor-profile support.* Neither AS metadata
      [RFC8414] nor Protected Resource Metadata [RFC9728] define
      parameters for advertising actor-profile support, requiring
      bilateral out-of-band configuration that does not scale to
      environments where clients dynamically discover services across
      trust domains.

   The design center of this document is delegation clarity.  client_id
   identifies the OAuth client registration, sub identifies the
   authorizing principal, and act.sub identifies the actor exercising
   that authorization.  These are distinct concepts.  This profile makes
   the actor explicit in the token rather than leaving it to be inferred
   from client registration context, and it does so without redefining
   client identity or top-level subject semantics.

   This document addresses that gap by specifying:

   *  A common actor profile structure that reuses act from [RFC8693]
      and adds sub_profile for entity-type classification.

   *  Processing rules for JWT assertion grants, JWT access tokens, and
      Transaction Tokens, covering Token Exchange inputs and outputs.

   *  A Token Exchange migration model that lets deployments move from
      bearer-style inputs to proof-of-possession outputs while
      preserving stable actor semantics.

   *  Resource-server guidance for evaluating delegated access using the
      (sub, outermost act.sub) pair.

   *  Integration with OAuth Entity Profiles and discovery metadata so
      actor classification and capability signaling can be used
      consistently across deployments.

   *  A stable extension model for companion profiles that add
      supplemental delegation data without altering core claim
      semantics.

   The mechanisms are general-purpose and apply beyond AI agent
   scenarios.  This document is a profile and extension of existing
   OAuth building blocks; unless stated otherwise, the requirements of
   [RFC8693], [RFC9068], [RFC9449], and
   [I-D.ietf-oauth-transaction-tokens] continue to apply.








McGuinness               Expires 1 November 2026                [Page 6]

Internet-Draft             OAuth Actor Profile                April 2026


1.1.  Illustrative Use Case

   Alice authorizes an AI agent to book a business trip on her behalf,
   and the request crosses from the enterprise identity provider's
   domain into an external booking domain and then into the booking
   provider's internal service mesh.  The enterprise authorization
   server first issues a delegated credential that keeps Alice as sub
   and the agent as act; downstream issuers later transform that
   credential into an access token and, for the internal tool hop, a
   Transaction Token rebound to the booking tool as the new presenter.
   Across those steps, the subject remains Alice, the immediate actor
   changes only when a new presenter is explicitly established, and each
   trust-domain boundary re-issues the token under local control.  The
   cross-domain example (Appendix B) provides the full end-to-end
   walkthrough.

1.2.  Relationship to Related Work

   *OAuth Token Exchange ([RFC8693])*: This document profiles the act
   claim from [RFC8693].  The actor object structure and processing
   rules supplement, and do not replace, the base Token Exchange
   requirements.

   *Identity Chaining ([I-D.ietf-oauth-identity-chaining])*: Identity
   Chaining addresses cross-domain subject-identity propagation; this
   document addresses actor representation within those same tokens.
   The two are complementary and designed to be used together.

   *Identity Assertion JWT Authorization Grant
   ([I-D.ietf-oauth-identity-assertion-authz-grant])*: ID-JAG defines
   how an IdP issues a JWT authorization grant via Token Exchange and
   how a downstream AS consumes it.  ID-JAG permits actor_token inputs
   but leaves actor-delegation validation and resulting act claims to
   future profiles or extensions.  This document defines one such
   profile: when an implementation uses ID-JAG with actor-profile
   claims, the Token Exchange and JWT assertion-grant processing rules
   in this document apply.  See the cross-domain example (Appendix B)
   for an end-to-end walkthrough.

   *OAuth Entity Profiles ([I-D.mora-oauth-entity-profiles])*: Defines
   sub_profile, client_profile, entity_profiles_supported, and the
   entity profile registry.  This document consumes those mechanisms for
   actor classification and makes no independent registry requests.

   *Transaction Tokens ([I-D.ietf-oauth-transaction-tokens])*: This
   document extends the Transaction Token claim model with actor-profile
   support and adds actor-profile-specific TTS processing rules.  Base
   Transaction Token requirements continue to apply.



McGuinness               Expires 1 November 2026                [Page 7]

Internet-Draft             OAuth Actor Profile                April 2026


   *WIMSE Workload Identity
   ([I-D.ietf-wimse-workload-creds][I-D.ietf-wimse-wpt])*: Defines
   workload credentials used to authenticate workloads at token
   endpoints.  This document is mechanism-agnostic; the cross-domain
   example (Appendix B) illustrates a WIMSE-based TTS presenter binding.

2.  Conventions and Definitions

   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.

   Unless otherwise specified, OAuth terms such as client, authorization
   server, resource server, access token, refresh token, grant,
   Transaction Token, and Transaction Token Service (TTS) are used as
   defined in [RFC6749], [RFC8693], [I-D.ietf-oauth-transaction-tokens],
   and related specifications.

   The following terms are used in this document:

   Actor:  The party that is actively making a request.  When delegation
      is present, the actor is distinct from the subject; the subject is
      the principal on whose behalf the actor is acting.

   Subject:  The principal whose authorization is being exercised.  In a
      delegated token, the subject is the original authorizing party
      (e.g., an end-user or an upstream service), not the party making
      the immediate network request.

   Delegation:  The act by which a principal authorizes another party
      (the actor) to exercise a subset of the principal's rights.

   Cross-Domain Delegation:  A delegation scenario in which the subject
      and actor are governed by different trust domains or different
      identifier namespaces under deployment policy.  This document does
      not define a universal interoperable algorithm for classifying a
      particular token instance as cross-domain.  Deployments typically
      make that determination from issuer context, actor identifier
      context, and the applicable trust framework or bilateral
      agreement.  The token's top-level iss alone is not sufficient to
      make that determination in all deployments.

   Actor Authorization at the Resource Server:  An authorization policy
      evaluation that considers both the subject and the actor, and the
      relationship between them, as policy inputs.  Under this profile,
      the relevant actor is ordinarily the outermost actor.



McGuinness               Expires 1 November 2026                [Page 8]

Internet-Draft             OAuth Actor Profile                April 2026


   Delegation Chain:  The sequence of actors representing how
      authorization has flowed from the subject principal (sub) to the
      first actor (innermost act) through any intermediate parties to
      the immediate actor (outermost act.sub).  The chain is conveyed
      structurally as the nested act claim.

   Outermost Actor:  The act object at the top level of the delegation
      chain (the one not nested inside any other act object).  When a
      delegation chain of depth greater than one is present, the
      outermost actor identifies the immediate bearer of the token.

   Local Policy:  Deployment-specific rules, configurations, or
      decisions made by an individual AS, RS, or organization that are
      not specified by this document.  Local policy MAY include
      delegation approval rules, scope-reduction algorithms, actor-
      identifier namespace mappings, and entity-profile acceptance
      criteria.  When this document references local policy, the
      specific decision logic is intentionally not standardized.

   Identifier Reconciliation:  The process by which an AS or RS applies
      locally configured mapping rules to determine whether two
      identifiers from different claims or namespaces refer to the same
      underlying entity.  Identifier reconciliation is performed by
      applying configured mapping rules; string similarity, shared
      naming patterns, or deployment intuition are not sufficient bases
      for reconciliation.  When this document states that an
      implementation SHOULD perform identifier reconciliation, it SHOULD
      apply its configured mapping rules to determine whether the two
      identifiers are known to refer to the same entity.  When no
      applicable mapping rule exists or reconciliation cannot be
      established, the identifiers MUST be treated as distinct.

   Examples in this document are illustrative and focus on actor-
   profile-related claims and processing.  They may omit unrelated
   claims, parameters, or validation steps required by the underlying
   specifications for a complete deployment.

   This document uses dot-path notation to refer to nested claim values.
   For example, act.sub refers to the sub member of the act object, and
   act.act.sub refers to the sub member of the act object nested within
   the outer act object (the immediately prior actor in a depth-2
   chain).

3.  Actor Profile for Delegation







McGuinness               Expires 1 November 2026                [Page 9]

Internet-Draft             OAuth Actor Profile                April 2026


3.1.  Overview

   This profile specifies an extended form of the act claim defined in
   [RFC8693].  When an implementation elects to use this profile in a
   context where an actor is distinct from the subject, it MUST apply
   the profile as defined in this section.  This document standardizes
   actor-profile claim structure, processing rules, and discovery
   metadata.  It does not standardize delegation approval policy, trust
   framework decisions, or identifier-mapping logic; those remain
   deployment-specific.  The absence of an explicit actor-carrying
   inbound credential MUST NOT be interpreted as meaning that the OAuth
   client automatically defines the delegated actor.

3.2.  Profile Invariants

   This document defines the following invariants:

   *  sub is the authorizing principal.

   *  The outermost act.sub is the immediate actor for the current token
      presentation.

   *  The canonical actor identifier conveyed by this profile is the
      (act.iss, act.sub) pair.

   *  act.iss identifies the issuer or namespace context in which
      act.sub is to be interpreted; implementations MUST NOT reinterpret
      it as the issuer of the current token, a credential-issuer claim,
      or a hop-provenance marker.

   *  Nested act objects are preserved prior-actor context unless a
      deployment explicitly applies additional local-policy processing
      to them; they are not independently authenticated by the current
      issuer merely because they appear in a re-issued token.

   *  client_id and azp are OAuth client identifiers, not actor
      identifiers.

   *  When the (act.iss, act.sub) pair identifies the same entity as the
      (iss, sub) pair of the token, no delegation is expressed and
      consumers MUST NOT infer a meaningful delegation relationship.
      String equality of act.sub and sub alone is not a sufficient test;
      the issuer or namespace context must also be considered.

3.3.  Profile Scope






McGuinness               Expires 1 November 2026               [Page 10]

Internet-Draft             OAuth Actor Profile                April 2026


3.3.1.  Representation and Policy

   The interoperability defined by this profile operates at the
   representation and propagation layer, not at the authorization policy
   layer.  Conformance means that issuers and consumers represent,
   preserve, validate, and interpret actor claims consistently: using
   the same claim structure, the same processing rules across token
   types, and the same discovery metadata.  What this profile does not
   standardize is whether a specific actor is permitted to act on behalf
   of a specific subject for a specific scope; that authorization policy
   decision requires bilateral agreement, a trust framework, or
   deployment-specific configuration outside this document.  This
   document does not close that policy gap; it makes the actor explicit
   and consistently represented in the token so that such agreements can
   be applied deterministically.

   This document does not require every deployment to enforce
   authorization of the (sub, outermost act.sub) pair on every request,
   although such enforcement is RECOMMENDED for security-sensitive
   delegated access.  Same-domain deployments will often satisfy the
   representation and propagation requirements with straightforward
   local configuration for actor identifier context and identifier
   mapping.  Cross-domain deployments require explicit trust-framework
   or bilateral agreement decisions covering the permitted delegation
   relationships and therefore carry a higher interoperability burden
   beyond what this profile alone provides.

3.3.2.  Token Format Scope

   This profile defines actor-profile requirements for JWT assertion
   grants, JWT-formatted access tokens, and Transaction Tokens.  Opaque
   access tokens are not conformant token formats under this profile.
   However, when an AS supports introspection, this document defines
   optional equivalent introspection response semantics for delegated
   opaque access tokens in Token Introspection (Section 8.4).  Such
   support is an introspection-based compatibility path; it does not
   make the opaque token itself conformant to this profile.  Use of
   opaque access tokens as subject_token or actor_token inputs to Token
   Exchange remains outside the interoperable scope of this document.
   An AS MAY translate introspection results for an opaque access token
   into equivalent local inputs for deployment-specific use, but that
   input-processing behavior is not interoperable behavior defined by
   this document.








McGuinness               Expires 1 November 2026               [Page 11]

Internet-Draft             OAuth Actor Profile                April 2026


3.3.3.  Supported Token Types and Request Semantics

   The actor profile defines processing rules for the following token
   types as issued outputs: JWT assertion grants (JWT Assertion Grants
   (Section 4)), JWT-formatted access tokens (JWT Access Tokens
   (Section 5)), and Transaction Tokens (Transaction Tokens
   (Section 7.1)).  It also defines Token Exchange input processing for
   JWT assertion grants, JWT access tokens, OpenID Connect ID tokens,
   refresh tokens, and Transaction Tokens as subject_token, and for
   workload identity credentials, JWT client assertions, and JWT access
   tokens as actor_token.  This document defines limited processing for
   the may_act claim as an optional delegation-authorization input, as
   described in may_act (Section 6.4); may_act is not itself a source of
   actor identity and is never propagated.

   Subject to endpoint policy and the underlying token-exchange or grant
   mechanism, implementations MAY transform a supported input token type
   into a supported output token type for which this document defines
   the relevant issuance processing.  This document normatively defines
   JWT assertion grant issuance (JWT Assertion Grant Output
   (Section 6.5.1)), JWT access token issuance via JWT Access Token
   Output (Section 6.5.2) after authorization-grant processing, Token
   Exchange processing, or Transaction Token Service processing, and
   Transaction Token issuance from inbound JWT assertion grants, JWT
   access tokens, or Transaction Tokens under Transaction Token Output
   Rules (Section 7.4).  It does not require every implementation to
   support every possible cross-product of supported inputs and outputs.
   When an implementation supports a path defined by this document,
   actor profile information MUST be preserved and validated as
   specified for the resulting token type.

   This document profiles token contents and the processing of those
   contents once present.  It does not redefine the request semantics of
   [RFC8693], including the syntax or baseline meaning of subject_token,
   actor_token, resource, audience, or requested_token_type.  When such
   inputs carry or imply actor information, this document defines only
   how that information is represented in issued tokens and how issuers
   and consumers process it.

   For worked examples showing the actor profile in use in both same-
   domain service delegation and cross-domain delegation, see the
   service-to-service example (Appendix A) and the cross-domain example
   (Appendix B).








McGuinness               Expires 1 November 2026               [Page 12]

Internet-Draft             OAuth Actor Profile                April 2026


3.4.  Actor Object Structure

   An actor object conforming to this profile is a JSON object that is
   the value of the act claim.  In addition to the sub claim required by
   [RFC8693], a profile-conformant actor object MUST contain an iss
   claim and SHOULD contain a sub_profile claim.  An act object that
   omits iss conforms to [RFC8693] but does not conform to this profile;
   handling of such objects is specified in Migration and Adoption
   (Section 12.1).

   act-object = {
     "sub"           : StringOrURI,        ; REQUIRED
     "iss"           : StringOrURI,        ; REQUIRED
     ? "sub_profile" : JSON String,        ; RECOMMENDED
     * StringOrURI => any                  ; extension claims
   }

   sub:  REQUIRED.  The subject identifier of the actor, as defined in
      [RFC8693], Section 4.1.  This value identifies the acting party.
      It is a StringOrURI as defined in [RFC7519].

   iss:  REQUIRED.  Identifies the issuer or namespace context in which
      the actor identifier carried in act.sub is to be interpreted,
      playing the same role for act.sub that the JWT iss claim plays for
      the token sub: just as iss + sub form a globally unique principal
      identifier in a JWT (see [RFC9493]), act.iss + act.sub form a
      canonical actor identifier within the delegation chain.  For URI,
      client, workload, or other deployment-specific identifiers, the
      value of act.iss MUST identify the context the issuer used when
      assigning or asserting that actor identifier.  See "Cross-Domain
      Delegation" in Conventions and Definitions (Section 2).  The value
      is a StringOrURI as defined in [RFC7519].

      The canonical actor identifier conveyed by this profile is the
      (act.iss, act.sub) pair.  Implementations MUST NOT interpret
      act.iss as the issuer of the current token, as a credential-issuer
      claim, or as a hop-provenance marker.  The actor identifier
      context, the token issuer, and the credential issuer may be the
      same entity or different entities.  In many deployments the value
      is an HTTPS URL, but other well-known identifier schemes (for
      example, a URN for workload identities) are also possible.
      Preserved inner act objects remain prior-actor context as
      described in Carry Prior-Actor Context (Section 3.6.2.4).

      For example, a TTS might issue a Transaction Token with top-level
      iss equal to https://tts.travel-provider.example while setting
      act.iss for the booking tool to https://as.travel-
      provider.example, if local policy uses that AS's identifier



McGuinness               Expires 1 November 2026               [Page 13]

Internet-Draft             OAuth Actor Profile                April 2026


      namespace for booking tool identifiers.  This is valid and
      expected: the TTS is the token issuer, while https://as.travel-
      provider.example is the actor identifier context for the booking
      tool identifier.

   sub_profile:  RECOMMENDED.  A space-delimited list of entity profile
      values classifying the actor identified by act.sub, as defined in
      Section 4.2 of [I-D.mora-oauth-entity-profiles].  Values used
      within act objects MUST be registered with the "Actor Profile"
      usage location in the OAuth Entity Profiles registry (Section 14.1
      of [I-D.mora-oauth-entity-profiles]) or be privately defined
      collision-resistant values.

      If the acting entity fits more than one profile, multiple values
      MAY be included as a space-delimited string (e.g., "service
      ai_agent").  Interoperability requirements and implementation
      guidance for multi-value strings are defined in
      [I-D.mora-oauth-entity-profiles].

      When sub_profile is absent from an act object, implementations
      MUST NOT assume a specific entity type for the actor; resource
      servers that enforce entity-type-based access control MUST treat
      an absent sub_profile as an unclassified actor and SHOULD apply
      the more restrictive policy applicable to unknown entity types.

      The sub_profile claim MAY also appear as a top-level JWT claim
      outside any act object to classify the entity type of the token's
      sub; it applies exclusively to sub and does not affect sub_profile
      values within act objects.  Issuers SHOULD include a top-level
      sub_profile when they can authoritatively classify the subject
      entity type.

   Per-actor key provenance within the delegation chain is outside the
   scope of this profile.  The current presenter's keying material is
   conveyed only by the token's top-level cnf claim, as described in
   Sender Constraint and Proof-of-Possession Validation (Section 3.7).
   Other members carried inside an act object, including any
   confirmation-style members defined by another profile, do not have
   standardized proof-of-possession semantics under this document unless
   another specification explicitly defines them.

   The client_profile claim defined in [I-D.mora-oauth-entity-profiles]
   classifies the OAuth client and MUST NOT appear within an act object.
   Client classification belongs at the top level of the token.  An AS
   or RS that encounters a client_profile member inside an act node MAY
   reject the token or ignore the offending member; it MUST NOT treat it
   as a valid actor classification.




McGuinness               Expires 1 November 2026               [Page 14]

Internet-Draft             OAuth Actor Profile                April 2026


   When an act object contains extension members beyond those defined in
   this document, issuers and consumers MUST ignore unrecognized members
   unless another specification or local policy defines their meaning.
   An issuer that re-issues a validated delegation chain MAY preserve
   unrecognized extension members in inherited act objects under local
   policy.  However, companion profiles that need independently
   verifiable provenance, per-hop receipts, or other chain-wide state
   SHOULD use the top-level extension pattern described in Companion
   Profiles and Extension Points (Section 11) rather than relying on
   inherited act-object extension members.

3.5.  Delegation Chains

   Delegation chains MUST be represented by nesting act objects as
   specified in [RFC8693], Section 4.1.  In a nested structure, the
   outermost act object identifies the immediate actor; inner act
   objects represent prior actors in the chain, with the innermost
   representing the first actor authorized by the subject.  This
   structure records delegated-actor history within the trust model of
   the issuer that conveys it; it does not, by itself, provide
   independent cryptographic provenance for each prior hop.  This
   profile defines a single linear delegation chain per token;
   concurrent delegations to multiple independent actors are out of
   scope and yield separate tokens with their own chains.

   This document uses the following terminology consistently:

   *  A *single-hop actor object* is an act object with no nested act;
      it represents delegation depth 1.

   *  An *inbound delegation chain* is the complete act structure
      received in an inbound token, whether depth 1 or greater.

   *  A *preserved delegation chain* is an inbound delegation chain that
      an issuer has validated and copied into a newly issued token
      without rewriting inherited actor entries.

   *  A *new outermost actor* is the actor object created by the current
      issuer to represent the newly identified outermost actor for the
      token it is issuing.











McGuinness               Expires 1 November 2026               [Page 15]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "sub": "https://idp.enterprise.example/users/alice",
     "sub_profile": "user",
     "act": {
       "sub": "https://tools.example.com/booking-tool",
       "iss": "https://as.travel-provider.example",
       "sub_profile": "service",
       "act": {
         "sub": "https://agents.example.com/travel-assistant",
         "iss": "https://as.enterprise.example",
         "sub_profile": "ai_agent"
       }
     }
   }

   In this example the booking tool (outermost act) is the current
   outermost actor.  The delegation chain originates with Alice (sub),
   who first authorized the travel assistant (nested act); the travel
   assistant then sub-delegated to the booking tool, which is now the
   immediate presenter.  The chain carries prior-actor information to
   the extent that the current token issuer is trusted to have validated
   and faithfully propagated it.

   Delegation depth is defined as the number of act objects in the
   chain, counting from the outermost.  A token with a single act object
   and no nested act within it has depth 1; each additional level of
   nesting adds 1.  Depth is counted on the resulting chain after any
   new outermost act is added, not on the inbound token.

   Depth 1 is the minimum interoperable depth.  Implementations intended
   for cross-domain multi-hop interoperability SHOULD support a local
   maximum of at least depth 4 (sufficient for the reference
   architecture user → orchestrator → agent → tool, with the tool as
   current presenter) and SHOULD document the configured maximum.  An
   implementation that supports only depth 1 is conformant to this
   document but will not interoperate with multi-hop deployments.  Same-
   domain deployments MAY enforce a shallower local maximum when that
   limit is sufficient for their architecture.

   Implementations MUST define and enforce a local maximum delegation
   depth.  Implementations that receive a token exceeding their
   configured local maximum MUST reject it with invalid_request.  When a
   request would result in a chain exceeding that limit, the AS MUST
   reject with invalid_request; it MUST NOT silently truncate the chain.







McGuinness               Expires 1 November 2026               [Page 16]

Internet-Draft             OAuth Actor Profile                April 2026


   A token represents delegation when the party exercising the token's
   authorization at runtime (the actor) is distinct from the token
   subject (sub) and the actor has been authorized by the subject to do
   so.  The conditions that establish this are:

   1.  A validated actor_token identifying a distinct actor was present
       in the exchange request that produced this token.

   2.  An inbound subject_token from a trusted upstream issuer already
       carried an act chain, establishing that delegation was present
       before the current exchange.

   3.  The issuing AS has an independent delegation basis such as a pre-
       registered grant, explicit consent record, a may_act claim in a
       validated upstream token (see may_act (Section 6.4)), or a policy
       rule establishing that the current client or actor is acting as a
       distinct party on behalf of sub (see JWT Access Tokens
       (Section 5) for the outside-Token-Exchange case).

   When a token represents delegation, the act claim MUST be present and
   MUST conform to Actor Object Structure (Section 3.4).  When none of
   the above conditions holds, the token does not represent delegation
   and the act claim MUST be omitted.  The AS MUST NOT include act
   solely because sub and the OAuth client identifier differ; the
   distinction between sub and client_id is expected and does not by
   itself constitute delegation under this profile.

3.6.  Delegation Chain Validation and Construction

   The following normative algorithm governs how an AS validates an
   inbound delegation chain and constructs the delegation chain in the
   issued token.  It applies to all token types defined in this profile,
   on request paths where actor-profile conformance is required or
   claimed, either because one of the type-specific processing sections
   (Authorization Grant Processing (Section 4.2), Token Exchange
   Processing (Section 6), or Transaction Token Output Rules
   (Section 7.4)) mandates it or because local policy or advertised
   metadata requires profile conformance for the request path.  Those
   type-specific sections reference this algorithm and add type-specific
   preconditions.  Actor objects that do not conform to this profile
   (for example, RFC 8693 act objects that omit iss) MUST NOT be
   processed by this algorithm; Migration and Adoption (Section 12.1)
   specifies how such objects are handled.  This algorithm governs claim
   handling only; it does not by itself create new delegation-
   authorization requirements beyond those imposed by the invoking
   processing section and local policy.





McGuinness               Expires 1 November 2026               [Page 17]

Internet-Draft             OAuth Actor Profile                April 2026


3.6.1.  Terminology

   *  *Depth* of a delegation chain: the number of nested act objects
      counted from the outermost.  A single act object with no nested
      act has depth 1; each additional nesting level adds 1.  Depth is
      measured on the chain as it appears in the issued token, after any
      new outermost actor is added.

   *  *Security-relevant entry*: an inner act object that local policy
      uses as an additional input to issuance decisions (authorization,
      scope determination, or identity mapping).  Use of such entries is
      deployment-specific and outside the baseline interoperable
      behavior of this profile.

   *  *Prior-actor context*: an inner act object preserved for audit or
      downstream authorization purposes without being used as a direct
      input to the current issuance decision.

3.6.2.  Validation Steps

   The AS applies the validation steps in the following order:

   1.  Validate the carrier token using Validate Carrier Token
       (Section 3.6.2.1).

   2.  Validate the outermost actor using Validate Outermost Actor
       (Section 3.6.2.2).

   3.  If inner actors are used as inputs to issuance decisions,
       validate those entries using Validate Inner Actors Used for
       Decisions (Section 3.6.2.3).

   4.  For inner actors preserved only as prior-actor context, apply
       Carry Prior-Actor Context (Section 3.6.2.4).

   5.  Enforce the configured maximum chain depth using Enforce Depth
       Limit (Section 3.6.2.5).

3.6.2.1.  Validate Carrier Token

   The AS MUST validate the token carrying the inbound delegation chain
   per the type-specific rules applicable to that token before
   extracting actor claims.

3.6.2.2.  Validate Outermost Actor

   For the outermost act object the AS MUST:




McGuinness               Expires 1 November 2026               [Page 18]

Internet-Draft             OAuth Actor Profile                April 2026


   1.  Verify that both act.sub and act.iss are present.  If either is
       absent, reject with invalid_request.

   2.  Verify that the token issuer is trusted under local policy to
       assert the (act.iss, act.sub) actor identifier pair.  This trust
       decision is outside the representation-layer interoperability
       defined by this profile (Representation and Policy
       (Section 3.3.1)); non-normative validation examples are in
       Trusting Actor Identifier Pairs (Section 12.2).  This step does
       not interpret act.iss as the token issuer or as proof that prior
       hops were independently authenticated.  If the token issuer is
       not trusted to assert the actor identifier pair, reject with
       invalid_grant.  The JWT assertion-grant path adds token-type-
       specific requirements in Authorization Grant Processing
       (Section 4.2).

   3.  When the applicable processing path uses Extend Chain with New
       Actor (Section 3.6.3.1), the AS MUST evaluate whether that actor
       (act.sub) is authorized to exercise delegation on behalf of sub
       under local policy (for example, a pre-registered grant, explicit
       consent record, or policy rule covering the acting party).  When
       the processing path uses Preserve Inbound Chain (Section 3.6.3.2)
       for an existing chain from a validated, trusted upstream issuer,
       delegation was evaluated upstream; the AS SHOULD evaluate the
       preserved relationship under local policy but is not required to
       do so for baseline interoperability.  If the required delegation
       relationship is prohibited by policy or cannot be confirmed,
       reject with actor_unauthorized.  The JWT assertion-grant path
       adds token-type-specific requirements in Authorization Grant
       Processing (Section 4.2).

3.6.2.3.  Validate Inner Actors Used for Decisions

   Interoperable processing under this profile is defined around sub and
   the outermost act.sub.  If local policy additionally uses an inner
   act object as an input to issuance decisions, the AS SHOULD apply the
   same three sub-steps as Validate Outermost Actor (Section 3.6.2.2)
   for that entry, including delegation-confirmation only when the
   current processing path or local policy requires it for that entry.
   Such use of inner actors is deployment-specific.











McGuinness               Expires 1 November 2026               [Page 19]

Internet-Draft             OAuth Actor Profile                April 2026


3.6.2.4.  Carry Prior-Actor Context

   For inner act objects preserved solely as prior-actor context without
   being used for any issuance decision, the AS MAY rely on trust in the
   outer token issuer established by Validate Carrier Token
   (Section 3.6.2.1) rather than independently validating each hop.  The
   AS MUST NOT treat preserved prior-actor context as independently
   authenticated; an inner act entry carried in a token is endorsed only
   by the outer token issuer's signature, not by independent
   verification at each prior hop.

3.6.2.5.  Enforce Depth Limit

   Compute the depth of the resulting chain, including any new outermost
   actor added by Extend Chain with New Actor (Section 3.6.3.1).  If
   that depth exceeds the locally configured maximum (Delegation Chains
   (Section 3.5)), reject with invalid_request.

3.6.3.  Construction Steps

   The AS selects exactly one construction step in the following order:

   1.  If a new actor is identified for the issued token, use Extend
       Chain with New Actor (Section 3.6.3.1).

   2.  Otherwise, if a validated inbound delegation chain is present,
       use Preserve Inbound Chain (Section 3.6.3.2).

   3.  Otherwise, use Omit act (Section 3.6.3.3).

3.6.3.1.  Extend Chain with New Actor

   When a new actor is identified, the AS creates a new outermost act
   object and nests any validated inbound chain beneath it.

AddOutermostActor(inbound_chain, new_actor):
  outermost.sub         = new_actor.sub      // REQUIRED
  outermost.iss         = new_actor.iss      // REQUIRED: issuer or namespace context for new_actor.sub
  outermost.sub_profile = new_actor.sub_profile  // RECOMMENDED when known

  if inbound_chain is present:
    outermost.act = inbound_chain  // nest entire validated inbound chain
    verify depth(outermost) <= local_max_depth  // see Enforce Depth Limit

  return outermost






McGuinness               Expires 1 November 2026               [Page 20]

Internet-Draft             OAuth Actor Profile                April 2026


   The act.iss value in the new outermost actor MUST be set by the
   issuing AS.  The AS MUST NOT rewrite act.iss or any other field in
   inherited inner actor objects; those fields were set by upstream
   issuers at the time of authorship and are immutable.  Dropping prior
   actors from the inbound chain to produce a shallower chain in the
   issued token is NOT permitted.  If preserving the inbound chain would
   cause the resulting depth to exceed the local maximum, the AS MUST
   reject with invalid_request rather than silently truncate.  The only
   exception is when the inbound token carries no act claim, in which
   case no prior chain exists and the issued token begins a new chain at
   depth 1.  When the new actor identifies the same party as the inbound
   outermost act.sub (same act.sub and act.iss under the same issuer or
   namespace context), the AS MAY use Preserve Inbound Chain
   (Section 3.6.3.2) instead, preserving the existing chain unchanged
   rather than creating a redundant nested entry.

   Detection of identifier reappearance deeper in the inbound chain (for
   example, the same actor appearing in both inner and outer positions
   of a longer chain) is not standardized by this profile.  An AS MAY
   apply local policy to such cases; the chain-construction algorithm
   itself neither requires nor prohibits cycle detection.

3.6.3.2.  Preserve Inbound Chain

   When no new actor is identified and an inbound chain is present, the
   AS copies the validated inbound chain unchanged.

   PreserveChain(inbound_chain):
     return inbound_chain  // copy without modification

   The AS MUST copy the validated inbound chain exactly into the issued
   token.  The AS MUST NOT add, remove, or rewrite any field in any
   actor object of a preserved chain.

3.6.3.3.  Omit act

   When no delegation is present and no actor information should appear
   in the issued token, the AS MUST NOT include an act claim.  The AS
   MUST NOT silently drop an inbound act claim; if it cannot preserve or
   extend the chain, it MUST reject the request per Error Responses
   (Section 9).










McGuinness               Expires 1 November 2026               [Page 21]

Internet-Draft             OAuth Actor Profile                April 2026


3.7.  Sender Constraint and Proof-of-Possession Validation

   When sender-constrained tokens are used with a delegated token, the
   top-level cnf claim identifies the key or certificate of the
   immediate presenter of that token.  When delegation is present, that
   immediate presenter is ordinarily the party identified by the
   outermost actor.  The following normative rules govern proof-of-
   possession (PoP) validation for all token types and credential
   exchanges defined in this profile.  Individual processing sections
   reference these rules and MUST apply them in addition to any type-
   specific requirements stated there.

   For Token Exchange, this profile uses exactly two presenter-
   transition modes:

   *  *Presenter continuation*: the issued token keeps the presenter of
      the inbound subject_token.  This mode is interoperable only when
      the inbound subject_token is PoP-capable and carries top-level
      cnf.

   *  *Presenter rebind*: the issued token installs a new presenter.
      This document defines presenter rebind only when a validated
      actor_token directly identifies the new presenter.

   This profile does not define per-actor confirmation members within
   nested act objects.  Stronger prior-hop key provenance, if needed,
   would require another profile layered on top of this one using the
   companion-profile extension pattern in Companion Profiles and
   Extension Points (Section 11).

   DPoP nonce handling per [RFC9449], Section 8 applies unchanged to all
   DPoP-bound token requests under this profile; this profile does not
   modify DPoP nonce semantics.

3.7.1.  Top-Level cnf Governs the Current Presenter

   The top-level cnf claim of any token identifies the key or
   certificate of the current presenter.  When delegation is present,
   that current presenter is the party identified by the outermost act
   claim: when DPoP ([RFC9449]) is used, the top-level cnf.jkt MUST
   identify that party's key; when mTLS ([RFC8705]) is used, the top-
   level cnf.x5t#S256 MUST identify that party's certificate.  The AS or
   RS MUST validate proof of possession against the top-level cnf.
   Confirmation-style members that appear inside an act object due to
   another specification do not have standardized proof-of-possession
   semantics under this document.





McGuinness               Expires 1 November 2026               [Page 22]

Internet-Draft             OAuth Actor Profile                April 2026


3.7.2.  Token Exchange Continuation

   When Token Exchange runs in presenter-continuation mode, the
   subject_token itself supplies the current presenter's binding state.
   This mode applies only to PoP-capable subject_token inputs that carry
   top-level cnf.

   *  If the subject_token carries top-level cnf, the requester MUST
      prove possession for that binding using the mechanism applicable
      to the subject_token type and deployment.

   *  If the subject_token does not carry top-level cnf, this document
      does not define presenter continuation for that request.

3.7.3.  Token Exchange Rebind

   When Token Exchange runs in presenter-rebind mode, the request
   establishes a new presenter for the issued token.  This document
   defines that presenter as established only by a validated actor_token
   that directly identifies it using its own top-level subject identity.

   *  The issuer MUST validate the actor_token and any accompanying
      proof required by that credential profile or deployment.

   *  The issuer MUST validate proof for the newly established presenter
      rather than requiring proof of possession for any prior
      subject_token binding solely because the inbound subject_token was
      sender-constrained.

   *  A delegated JWT access token or any other actor_token whose acting
      identity is available only through an embedded act claim does not
      qualify as a direct presenter credential for interoperable
      presenter rebind under this profile.

   Rebind requires an actor_token whose own top-level sub names the new
   presenter.  An actor holding only a delegated credential cannot
   rebind; intermediate actors that may become new presenters must
   possess a direct presenter credential (workload credential (Workload
   Credential Processing (Section 6.3.2.2)), RFC 7523 client assertion
   (JWT Client Assertion (Section 6.3.1)), or non-delegated JWT access
   token (JWT Access Token as actor_token (Section 6.3.3))).










McGuinness               Expires 1 November 2026               [Page 23]

Internet-Draft             OAuth Actor Profile                April 2026


3.7.4.  Bearer-to-PoP Upgrade

   When the inbound subject_token is a bearer credential or an identity-
   only credential and the request supplies a validated actor_token
   establishing a new presenter, the issuer MAY issue a sender-
   constrained output token bound to that new presenter.  The absence of
   inbound top-level cnf creates no continuity obligation in this case.

4.  JWT Assertion Grants

   This section defines the actor-profile structure and authorization-
   grant processing rules for JWT assertion grants.  JWT access-token
   structure, Token Exchange processing, and Transaction Token Service
   processing are defined in later sections.

4.1.  Structure

   Actor-profile requirements apply to any JWT used as an authorization
   grant under [RFC7521] and [RFC7523], independent of how or by which
   specification it was produced.  One such profile is the Identity
   Assertion JWT Authorization Grant (ID-JAG,
   [I-D.ietf-oauth-identity-assertion-authz-grant]), a JWT bearer grant
   produced by Token Exchange.  When the grant is an ID-JAG, this
   document acts as an actor-delegation profile layered on the base ID-
   JAG specification: ID-JAG defines the token-exchange and JWT-bearer
   flow, while this document defines how actor_token-derived actor
   identity and any resulting act claim are represented and processed.

   Such a JWT MAY include an act claim conforming to the actor profile
   defined in Actor Profile for Delegation (Section 3).  Use of this
   claim in JWT client authentication assertions is out of scope for
   this document because such assertions have different issuer and
   subject semantics.  However, implementers should note that some
   deployments rely on the authenticated OAuth client itself as implicit
   evidence of the acting party.  This document does not prohibit that
   input, but when delegation is to be expressed explicitly and
   propagated across token transformations, the acting party is
   represented by act rather than inferred solely from client
   authentication.

   The following claims are defined for a JWT assertion grant that
   carries actor-profile delegation.  Claims not listed here follow the
   requirements of [RFC7521] and [RFC7523].

   iss (REQUIRED):  Identifies the assertion issuer.  MUST be authorized
      by local policy to assert the relationship between sub and
      act.sub.




McGuinness               Expires 1 November 2026               [Page 24]

Internet-Draft             OAuth Actor Profile                April 2026


   sub (REQUIRED):  The principal on whose behalf the grant is being
      made.

   sub_profile (RECOMMENDED):  Classifies the entity type of sub.  MUST
      conform to the values defined in Actor Profile for Delegation
      (Section 3).

   act (REQUIRED when delegation is asserted):  The actor object
      identifying the entity exercising the subject's delegated rights.
      MUST conform to the actor object structure defined in Actor
      Profile for Delegation (Section 3).  MUST include act.sub and
      act.iss.

   cnf (REQUIRED when sender-constrained; otherwise OPTIONAL):  When the
      JWT assertion grant is sender-constrained, the assertion MUST
      carry a top-level cnf claim identifying the binding: cnf.jkt per
      [RFC9449] when DPoP is used, or cnf.x5t#S256 per [RFC8705] when
      mTLS is used.  When the assertion is not sender-constrained, top-
      level cnf is OPTIONAL unless required by another profile or local
      policy.

   When the assertion or request context also identifies an OAuth client
   via client_id, azp, or an authenticated client credential,
   interoperable processing SHOULD use act.sub rather than treating that
   client identity as a substitute for it (see Client Identity and
   Delegation (Section 14.7) and Authorization Grant Processing
   (Section 4.2)).

   Clients SHOULD use JWT assertion grants carrying actor-profile claims
   only when the AS's support for the actor-determination model has been
   confirmed via deployment documentation, prior agreement, or
   discovery.  For ID-JAG specifically, that confirmation SHOULD include
   whether the AS supports the actor-delegation extension model defined
   by this document.

   The following example shows an AS-issued assertion grant, which is
   the recommended pattern.  The Enterprise IdP AS performed Token
   Exchange, authenticated the agent as the OAuth client, established
   the delegation relationship under local policy, and signed the
   assertion.  act.iss equals the token iss here because the enterprise
   AS's issuer identifier is also the actor identifier context for the
   agent:









McGuinness               Expires 1 November 2026               [Page 25]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.enterprise.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "aud": "https://as.resource-domain.example/token",
     "jti": "a1b2c3d4-...",
     "exp": 1711820400,
     "iat": 1711816800,
     "sub_profile": "user",
     "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" },
     "act": {
       "sub": "https://agents.enterprise.example/travel-assistant",
       "iss": "https://as.enterprise.example",
       "sub_profile": "ai_agent"
     }
   }

   The top-level sub_profile classifies the JWT's sub; sub_profile
   within act classifies the actor.  The top-level cnf.jkt binds the
   assertion to the agent's DPoP key.

   The AS-issued grant is the pattern defined by this document because
   the issuing AS independently authenticated the agent and validated
   the delegation relationship before signing.  The receiving AS needs
   to trust the enterprise AS as an issuer and as an authority for
   asserting the actor identifier pair carried in the grant.

   For AS-issued grants, the issuing AS MUST set act.iss to the issuer
   or namespace context in which act.sub is to be interpreted; for
   actors registered in the issuing AS's own namespace, this is often
   the AS's own issuer URI.

   This document defines the following issuer patterns:

   *  an AS-issued delegated assertion where JWT iss is a trusted AS and
      act.sub identifies the actor (recommended),

   *  an assertion carrying a pre-existing nested act chain where the
      current JWT iss is a trusted AS carrying forward prior actor
      assertions.

   A deployment MAY additionally accept a self-issued actor assertion
   when explicitly enabled by another specification or local policy, but
   that behavior is outside the scope of this document.  Implementations
   MUST reject self-issued assertion grants by default; see Self-Issued
   Authorization Grants (Section 14.2) for the security controls any
   such deployment MUST independently establish.





McGuinness               Expires 1 November 2026               [Page 26]

Internet-Draft             OAuth Actor Profile                April 2026


4.2.  Authorization Grant Processing

   When an AS receives a JWT assertion grant containing an act claim:

   1.  The AS MUST validate the assertion per [RFC7523], including
       signature, iss, sub, aud, exp, and jti.

       *  *Non-sender-constrained grants*: When neither a DPoP proof
          ([RFC9449]) nor an mTLS client certificate ([RFC8705]) is
          required at the token endpoint, the AS MUST reject any
          assertion whose jti has already been accepted within the
          assertion's validity window.

       *  *Sender-constrained grants*: The AS SHOULD additionally apply
          jti replay prevention as defense-in-depth, consistent with
          [RFC7523].

   2.  The AS MUST verify that the JWT iss is trusted under local policy
       to assert delegation on behalf of the actor identified by
       act.sub.

          Note: Under this document the JWT iss is expected to be a
          trusted AS.  Self-issued grants, where the acting entity is
          also the token issuer, are a deployment-specific extension
          outside the scope of this document; see Self-Issued
          Authorization Grants (Section 14.2).

   3.  The AS MUST verify that the JWT iss is trusted under local policy
       to assert the (act.iss, act.sub) actor identifier pair.

       *  If act.iss is absent: reject with invalid_request (structural
          violation).

       *  If the JWT iss is not trusted to assert the actor identifier
          pair: reject with invalid_grant.

          Note: See Validate Outermost Actor (Section 3.6.2.2) for the
          trust-validation framing and Trusting Actor Identifier Pairs
          (Section 12.2) for non-normative examples.

   4.  The AS MUST evaluate whether the identified actor is authorized
       to exercise delegation on behalf of sub.  The required strength
       of that evaluation depends on how the outermost actor was
       introduced:







McGuinness               Expires 1 November 2026               [Page 27]

Internet-Draft             OAuth Actor Profile                April 2026


       *  *New actor*: When the request supplies an actor_token or self-
          issued assertion that introduces a new act.sub not carried by
          the inbound chain, the AS MUST confirm the delegation
          relationship under local policy (for example, a pre-registered
          grant, explicit consent record, or policy rule).

       *  *Preserved chain*: When the request preserves an existing
          chain from a validated, trusted upstream issuer, the issuer
          trust established in step 2 provides the baseline assurance;
          the AS SHOULD additionally evaluate under local policy but is
          not required to do so for baseline interoperability.

       In either case:

       *  If the delegation relationship is prohibited by AS policy or
          cannot be confirmed: reject with actor_unauthorized.

   5.  If the inbound assertion's act object contains a nested act claim
       (indicating that the asserted actor is itself a delegatee), the
       AS MUST handle the inner chain as follows:

       *  *Propagation decision*: The AS MUST determine whether to
          propagate the inner chain into the issued token.  The AS
          SHOULD propagate it by preserving the nested structure,
          provided the total resulting chain depth does not exceed the
          limit in Delegation Chains (Section 3.5).  If the AS does not
          accept pre-chained assertions, it MUST reject the request.

       *  *Entries used by the AS for issuance decisions*: Interoperable
          processing is defined around sub and the outermost act.sub.
          If local policy additionally uses an inner act object for
          authorization, scope determination, or another issuance
          decision, the AS MUST validate the act.sub and act.iss pair
          and MUST evaluate the delegation relationship before using
          that entry as a security input.  Such use of inner act objects
          is deployment-specific rather than part of the baseline
          interoperable behavior of this profile.

       *  *Preserved prior-actor context*: For inner act objects the AS
          preserves only as prior-actor context, apply Carry Prior-Actor
          Context (Section 3.6.2.4).  Downstream authorization
          interoperability is defined around sub and the outermost
          act.sub.

   6.  The AS MUST verify proof of possession according to the token-
       endpoint mechanism in use and the top-level cnf semantics in
       Sender Constraint and Proof-of-Possession Validation
       (Section 3.7).



McGuinness               Expires 1 November 2026               [Page 28]

Internet-Draft             OAuth Actor Profile                April 2026


       *  *DPoP*: When the inbound assertion grant is DPoP-bound, it
          MUST carry a top-level cnf.jkt; reject with invalid_request if
          absent.  The AS MUST:

          -  Verify the DPoP proof is valid per [RFC9449] with
             htm="POST" and htu equal to the AS token endpoint URI.

          -  Verify the jkt in the DPoP proof exactly matches the
             cnf.jkt in the assertion.

          -  Use the assertion's cnf.jkt as set by the upstream issuer;
             MUST NOT substitute a locally registered key.

          -  Reject with invalid_dpop_proof or invalid_grant if the
             proof is absent or invalid.

             Note: The ath claim is not applicable at the token endpoint
             and MUST NOT be required.  See also
             [I-D.parecki-oauth-jwt-dpop-grant] for related work on
             DPoP-bound JWT grants.

       *  *mTLS*: When the inbound assertion grant is mTLS-bound, it
          MUST carry a top-level cnf.x5t#S256; reject with
          invalid_request if absent.  The AS MUST:

          -  Validate the client certificate presented at the token
             endpoint against cnf.x5t#S256.

          -  Use the cnf.x5t#S256 value set by the upstream issuer; MUST
             NOT substitute a locally registered certificate.

          -  Reject per [RFC8705] if the presented certificate does not
             match.

       *  When this JWT assertion grant is later used as a subject_token
          in Token Exchange, presenter continuation and presenter rebind
          are determined by Presenter Transition Model (Section 6.1) and
          Sender Constraint and Proof-of-Possession Validation
          (Section 3.7), not by nested act contents.

   7.  If the assertion or authenticated request context identifies an
       OAuth client separately from act.sub:

       *  The AS MAY use that client identity as an additional
          authorization input.






McGuinness               Expires 1 November 2026               [Page 29]

Internet-Draft             OAuth Actor Profile                April 2026


       *  The AS SHOULD NOT infer that the client is authorized to act
          on behalf of the subject solely because the client initiated
          the request.  Such inference is outside the interoperable
          behavior defined by this profile.

       *  When local policy maps the client identity to an actor
          identifier expected to match act.sub, the AS SHOULD perform
          identifier reconciliation before issuing a token.  If
          reconciliation cannot be established, the AS MUST either treat
          the identifiers as distinct or reject the request according to
          local policy.

   8.  If the AS accepts the assertion, it MUST propagate the actor
       information into the issued token according to the rules for the
       output token type being issued.  For JWT access tokens, see JWT
       Access Token Output (Section 6.5.2).  For Transaction Tokens, see
       Transaction Token Output Rules (Section 7.4).  When the output is
       another JWT assertion grant profile, the resulting assertion MUST
       preserve the validated actor information subject to local policy
       and the chain-depth limit in Delegation Chains (Section 3.5).

   9.  When constructing a new outermost act object using Extend Chain
       with New Actor (Section 3.6.3.1), the AS MAY enrich that object
       with sub_profile based on its own knowledge of the actor's entity
       type.  The AS MAY also set or enrich the top-level sub_profile of
       the issued token based on its knowledge of sub.  The AS MUST NOT
       add, modify, or remove any claim in preserved inner act objects;
       those entries are immutable under Preserve Inbound Chain
       (Section 3.6.3.2).

5.  JWT Access Tokens

   This section defines the actor-profile structure of delegated JWT
   access tokens used by this document.  Processing rules that lead to
   issuance of such tokens are defined in Token Exchange Processing
   (Section 6) and Transaction Token Service Processing (Section 7).

5.1.  Structure

   A delegated JWT access token is a JWT access token per [RFC9068] that
   carries an act claim conforming to the actor profile defined in Actor
   Profile for Delegation (Section 3).  Claims not listed here follow
   [RFC9068] and any other applicable token profile.

   The following claims are defined for a JWT access token that carries
   actor-profile delegation:

   iss (REQUIRED):  Identifies the access token issuer.



McGuinness               Expires 1 November 2026               [Page 30]

Internet-Draft             OAuth Actor Profile                April 2026


   sub (REQUIRED):  Identifies the principal on whose behalf the access
      token is issued.

   sub_profile (RECOMMENDED):  Classifies the entity type of sub.  MUST
      conform to the values defined in Actor Profile for Delegation
      (Section 3).

   act (REQUIRED when the token represents delegation per Delegation
   Chains (Section 3.5)):  The actor object identifying the entity
      exercising the subject's delegated rights.  MUST conform to the
      actor object structure defined in Actor Profile for Delegation
      (Section 3).  MUST include act.sub and act.iss.  When the token
      does not represent delegation, act MUST be omitted.

   cnf (REQUIRED when sender-constrained; otherwise OPTIONAL):  Binds
      the access token to the current presenter when a sender-
      constraining mechanism such as DPoP or mTLS is used.

   client_id and azp (OPTIONAL):  Identify the OAuth client when carried
      in the token.  They do not identify the delegated actor and MUST
      NOT be used as a substitute for act.

   Some deployments also carry an azp claim as an auxiliary client-
   identity signal, often as an OpenID Connect carry-over used by
   vendors in practice.  When an issuer uses both azp and act.sub to
   represent the same acting party, it SHOULD perform identifier
   reconciliation between them or else treat them as distinct
   identifiers under local policy.  See Migrating from Implicit to
   Explicit Delegation (Section 12.1.2) and Client Identity and
   Delegation (Section 14.7) for migration, reconciliation, and the
   normative client-identity rules.

   The following example shows a JWT access token with actor profile
   claims:

















McGuinness               Expires 1 November 2026               [Page 31]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.resource-domain.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "client_id": "travel-assistant-client-id",
     "azp": "https://agents.example.com/travel-assistant",
     "aud": "https://api.resource-domain.example",
     "jti": "xyz987",
     "exp": 1711820400,
     "iat": 1711816800,
     "scope": "travel:book",
     "sub_profile": "user",
     "cnf": {
       "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ"
     },
     "act": {
       "sub": "https://agents.example.com/travel-assistant",
       "iss": "https://as.enterprise.example",
       "sub_profile": "ai_agent"
     }
   }

   In this single-hop case the top-level bearer key identifies the same
   party as the outermost actor because the actor is the bearer.  The
   differing client_id, azp, and act.sub values in this example are
   intentional: they illustrate a deployment where client-facing
   identifiers and actor identifiers are distinct and must be
   reconciled, if at all, only through trusted local mapping rules.  In
   multi-hop chains each actor remains a distinct identity in the chain;
   see the cross-domain example (Appendix B).

5.2.  Delegated Token Issuance

   When an AS issues a JWT access token outside Token Exchange and the
   token represents delegation through an independent delegation basis
   (Delegation Chains (Section 3.5)), it MUST establish that basis for
   the (sub, actor) relationship before including act.  Examples include
   a pre-registered delegation grant, an explicit consent record, or a
   policy rule covering the acting party or a class of acting parties.

   A client registration MAY satisfy this requirement only when it
   uniquely identifies a single distinct acting entity and the AS can
   derive that actor's identifier from the registration alone (for
   example, a dedicated registration for a specific agent or service).
   A client registration that fronts multiple distinct acting entities
   (for example, an agent orchestration platform or shared-client
   deployment) does NOT satisfy this requirement, because client_id
   alone does not identify the runtime actor in those cases.




McGuinness               Expires 1 November 2026               [Page 32]

Internet-Draft             OAuth Actor Profile                April 2026


   When the AS determines the actor from authenticated client context,
   local delegation policy, or other deployment-specific inputs rather
   than from an explicit actor-carrying artifact, that is an operational
   allowance rather than an interoperable actor-proof mechanism defined
   by this document.  The interoperability defined here applies to the
   issued token and its processing, not to the upstream method by which
   the AS determined the actor.

   The authorization code flow is within scope of the preceding rules.
   When a resource owner interactively authorizes an agent via
   /authorize, the AS MAY include act in the issued access token if it
   has an independent delegation basis establishing that the OAuth
   client is acting as a distinct actor on behalf of the resource owner.
   The actor identity MUST be derived from that delegation basis.  If no
   such basis exists, the AS MUST NOT include act in the access token.

   This document does not define an authorization request parameter,
   authorization endpoint interaction, or token request parameter for
   selecting or proving the actor in the authorization code flow.  When
   actor-profile claims are included in access tokens issued from an
   authorization code grant, the AS determines the actor from local
   state established during authorization, client registration, consent,
   enterprise policy, or another deployment-specific mechanism.  Such
   issuance is interoperable only at the issued-token representation and
   resource-server processing layer.

6.  Token Exchange Processing

   Each credential type presented as subject_token or actor_token in a
   Token Exchange request is processed per the applicable rules in this
   section.  These rules explain how subject or actor identity is
   introduced into the actor-profile model; they do not redefine the
   core act semantics in Actor Profile for Delegation (Section 3).

   This section covers RFC 8693 Token Exchange input processing and the
   output-token issuance rules for JWT assertion grants and JWT access
   tokens.  JWT assertion-grant structure is defined in JWT Assertion
   Grant Structure (Section 4.1).  JWT access-token structure is defined
   in JWT Access Token Structure (Section 5.1).  Transaction Token
   issuance is defined separately in Transaction Token Service
   Processing (Section 7).

   Authorization-server error handling for requests processed in this
   section is defined in Error Responses (Section 9).

   This profile defines three JWT-based actor_token credential types.
   JWT access tokens use actor_token_type=urn:ietf:params:oauth:token-
   type:access_token (JWT Access Token as actor_token (Section 6.3.3)).



McGuinness               Expires 1 November 2026               [Page 33]

Internet-Draft             OAuth Actor Profile                April 2026


   RFC 7523 client assertions (JWT Client Assertion (Section 6.3.1)) and
   workload identity credentials (Workload Credential Processing
   (Section 6.3.2.2)) both use
   actor_token_type=urn:ietf:params:oauth:token-type:jwt and are
   distinguished as follows.

   A JWT is identified as the RFC 7523 client-assertion profile when it
   is presented as client_assertion with
   client_assertion_type=urn:ietf:params:oauth:client-assertion-
   type:jwt-bearer AND its sub equals the client_id of the
   authenticating client.  A JWT presented as client_assertion whose sub
   does not equal client_id is not a conformant RFC 7523 assertion and
   MUST NOT be identified as the RFC 7523 client-assertion profile
   solely on the basis of the client_assertion parameter; the AS MUST
   instead apply workload identity credential processing if the
   credential otherwise matches that profile, or reject with
   invalid_grant if no profile matches.  If the AS cannot identify
   exactly one supported actor-credential profile for the actor_token,
   it MUST reject the request with invalid_grant.  When client_assertion
   and actor_token are different JWTs, the AS MUST process them
   independently per the rules of their respective types; the
   disambiguation rule above applies only to the actor_token.

6.1.  Presenter Transition Model

   For PoP migration, this profile distinguishes two semantic classes of
   subject_token input based on whether they carry inbound act state and
   presenter-continuity information:























McGuinness               Expires 1 November 2026               [Page 34]

Internet-Draft             OAuth Actor Profile                April 2026


      +===============+=================+==============+============+
      | Input type    | Carries inbound | Carries top- | Presenter  |
      |               | act state       | level cnf    | continuity |
      +===============+=================+==============+============+
      | ID token      | No              | No           | Not        |
      |               |                 |              | available  |
      +---------------+-----------------+--------------+------------+
      | Refresh token | No              | No           | Not        |
      |               |                 |              | available  |
      +---------------+-----------------+--------------+------------+
      | JWT assertion | Yes (if         | Yes (if      | Available  |
      | grant         | present)        | present)     |            |
      +---------------+-----------------+--------------+------------+
      | JWT access    | Yes (if         | Yes (if      | Available  |
      | token         | present)        | present)     |            |
      +---------------+-----------------+--------------+------------+
      | Transaction   | Yes (if         | Yes (if      | Available  |
      | Token         | present)        | present)     |            |
      +---------------+-----------------+--------------+------------+

                                  Table 1

   Identity-only inputs (ID tokens, refresh tokens) establish sub and
   MAY establish supporting subject state such as sub_profile or an
   authorization ceiling.  They do not establish inbound act state or
   presenter continuity, and do not by themselves justify carrying act
   into the issued token.

   Token-state inputs (JWT assertion grants, JWT access tokens,
   Transaction Tokens) establish sub and MAY establish sub_profile,
   inbound act chain state, and current-presenter binding through top-
   level cnf.  They are the only subject_token inputs from which this
   document defines interoperable delegation-chain preservation and
   presenter continuation.

   Token Exchange under this profile runs in exactly one of two
   presenter-transition modes:

   *  *Presenter continuation*: no validated actor_token establishing a
      new presenter is supplied.  The issued token keeps the presenter
      of a PoP-capable token-state subject_token.

   *  *Presenter rebind*: a validated actor_token establishes a new
      presenter for the issued token.  When the output token is sender-
      constrained, its top-level cnf is bound to that new presenter.






McGuinness               Expires 1 November 2026               [Page 35]

Internet-Draft             OAuth Actor Profile                April 2026


   This document defines presenter rebind only when a validated
   actor_token establishes the new presenter.  Other ways an
   implementation might authenticate or install a new presenter are
   deployment-specific and outside the scope of this document.

   When the inbound subject_token is bearer or identity-only, presenter
   continuation is unavailable, but presenter rebind remains available.
   This bearer-to-PoP upgrade path lets a deployment exchange an
   existing bearer-style input for a sender-constrained output token
   without changing the actor semantics defined by this profile.

   A rebind-capable actor_token under this profile is a *direct
   presenter credential*: its own top-level subject identity names the
   new presenter, and the request proves possession according to that
   credential profile when sender-constrained output is being
   established.

   For legacy bearer-to-PoP migration, the recommended interoperable
   pattern is to present the existing bearer-style or identity-only
   credential as subject_token, present a direct presenter credential as
   actor_token, and issue a sender-constrained output token in
   presenter-rebind mode.  Deployments that need to preserve an inbound
   delegation chain while changing presenters SHOULD use the delegated
   credential as subject_token and a separate direct presenter
   credential as actor_token.

   JWT assertion grants are not suitable for use as actor_token in Token
   Exchange.  Their sub identifies the subject of delegation rather than
   the acting party.  Requests that need to establish an agent,
   workload, or client as the actor SHOULD use one of the actor
   credential types defined in this section instead.

6.2.  Subject Tokens

   This section is organized by the two semantic subject_token classes
   defined in Presenter Transition Model (Section 6.1).  The class-level
   text defines the common actor-profile consequences.  The individual
   token sections then define only the validation and extraction rules
   specific to each token type.  SAML 1.1 and SAML 2.0 assertions are
   not supported subject_token inputs under this profile; while
   [RFC8693] defines token type URNs for SAML assertions, actor-profile
   extraction from XML-based SAML credentials is outside scope.

6.2.1.  Token-State Subject Tokens

   JWT assertion grants, JWT access tokens, and Transaction Tokens are
   token-state subject_token inputs.  For these inputs, this document
   defines the following common model:



McGuinness               Expires 1 November 2026               [Page 36]

Internet-Draft             OAuth Actor Profile                April 2026


   *  the validated token establishes the inbound sub;

   *  sub_profile, if present and trusted, becomes inbound supporting
      subject state;

   *  act, if present, becomes inbound delegation-chain state for JWT
      Access Token Output (Section 6.5.2) or Transaction Token Output
      Rules (Section 7.4);

   *  top-level cnf, if present, makes the input eligible for presenter
      continuation under Sender Constraint and Proof-of-Possession
      Validation (Section 3.7);

   *  if top-level cnf is absent, the token still MAY be used in
      presenter-rebind mode for bearer-to-PoP upgrade.

6.2.1.1.  JWT Assertion Grant

   When a Token Exchange request ([RFC8693]) presents a JWT assertion
   grant as the subject_token, the AS MUST apply the inbound validation
   rules of Authorization Grant Processing (Section 4.2) to validate the
   inbound token.  Assertion-grant output construction from that section
   does not apply; propagation and scope reduction are governed by the
   rules below and by JWT Access Token Output (Section 6.5.2).

   A JWT assertion grant used as subject_token is a token-state input
   for Presenter Transition Model (Section 6.1).  If it carries top-
   level cnf, presenter continuation requires proof for that binding per
   Sender Constraint and Proof-of-Possession Validation (Section 3.7).
   If it does not carry top-level cnf, it still MAY be used as a bearer
   subject token in presenter-rebind mode for bearer-to-PoP upgrade when
   a validated actor_token establishes the new presenter.

   The AS MUST apply scope reduction per [RFC8693], Section 4 and MUST
   then apply the propagation rules in JWT Access Token Output
   (Section 6.5.2).

6.2.1.2.  JWT Access Token

   When a Token Exchange request ([RFC8693]) presents a JWT access token
   as the subject_token (subject_token_type=urn:ietf:params:oauth:token-
   type:access_token), the AS MUST apply the following steps.  Use of an
   opaque access token as the subject_token is outside the interoperable
   scope of this profile (see Profile Scope (Section 3.3)).

   1.  The AS MUST validate the inbound JWT access token per [RFC9068]:
       signature, iss, sub, exp, nbf, and jti.  Because a JWT access
       token used as subject_token was issued for a resource server, its



McGuinness               Expires 1 November 2026               [Page 37]

Internet-Draft             OAuth Actor Profile                April 2026


       aud will not ordinarily include the Token Exchange AS's token
       endpoint; the AS MUST NOT reject the inbound token solely because
       its aud does not include the AS's token endpoint URI.

   2.  The AS MUST verify that the inbound token's iss is trusted under
       local policy to assert the delegation chain it carries.  If not,
       the AS MUST reject the request with invalid_grant.

   3.  If the inbound token carries top-level cnf, it is a PoP-capable
       token-state input for Presenter Transition Model (Section 6.1),
       and the AS MUST apply the continuation or rebind rules in Sender
       Constraint and Proof-of-Possession Validation (Section 3.7).  If
       the inbound token carries no top-level cnf, it is a bearer
       subject_token for PoP purposes and MAY still be used in
       presenter-rebind mode for bearer-to-PoP upgrade.

   4.  The AS MUST extract sub, sub_profile (if present), and act (if
       present) from the validated token as the inbound delegation state
       for JWT Access Token Output (Section 6.5.2).

   5.  The AS MUST apply scope reduction per [RFC8693], Section 4.  The
       effective scope of the issued token MUST NOT exceed the inbound
       token's effective scope.

   After completing these steps, the AS MUST apply the propagation rules
   in JWT Access Token Output (Section 6.5.2).

6.2.1.3.  Transaction Token

   When a Token Exchange request ([RFC8693]) presents a Transaction
   Token as the subject_token
   (subject_token_type=urn:ietf:params:oauth:token-type:txn_token) to a
   regular AS (not a TTS), the AS MUST apply the following steps.

   1.  The AS MUST validate the Transaction Token per
       [I-D.ietf-oauth-transaction-tokens] (signature, aud, exp, iat,
       and issuer identity).  When the token carries an act claim, the
       top-level iss claim MUST be present and the AS MUST validate it
       as the Transaction Token issuer identifier; if iss is absent, the
       AS MUST reject the request with invalid_request.  When the token
       carries no act claim and iss is absent, the AS MUST determine the
       issuer using the trust-domain and issuer-identification rules of
       [I-D.ietf-oauth-transaction-tokens] and local deployment
       configuration.  If validation fails or the issuer cannot be
       established, the AS MUST reject the request with invalid_grant.






McGuinness               Expires 1 November 2026               [Page 38]

Internet-Draft             OAuth Actor Profile                April 2026


   2.  The AS MUST verify that the Transaction Token issuer identified
       in step 1 is trusted under local policy.  If not, the AS MUST
       reject the request with invalid_grant.

   3.  If the inbound Transaction Token carries a top-level presenter-
       binding claim such as cnf, it is a PoP-capable token-state input
       for Presenter Transition Model (Section 6.1), and the AS MUST
       apply the continuation or rebind rules in Sender Constraint and
       Proof-of-Possession Validation (Section 3.7) using the proof
       mechanism defined by [I-D.ietf-oauth-transaction-tokens] and the
       applicable deployment profile.  If the inbound Transaction Token
       carries no top-level presenter binding, it MAY still be used in
       presenter-rebind mode for bearer-to-PoP upgrade.

   4.  The AS MUST extract sub, sub_profile (if present), and act (if
       present) from the validated Transaction Token as the inbound
       delegation state for JWT Access Token Output (Section 6.5.2).

   5.  The req_wl claim identifies the workload that requested the
       Transaction Token from the TTS and provides informational context
       about the transaction origin.  The AS MAY use req_wl for audit or
       local policy decisions but MUST NOT carry it forward into the
       issued JWT access token.

   6.  The AS MUST apply the propagation rules in JWT Access Token
       Output (Section 6.5.2).  For a Transaction Token used as
       subject_token, this document defines only the actor-profile
       consequences of the inbound sub, act, req_wl, and presenter-
       binding state.  Transaction Token field semantics and any
       transaction-specific scope handling remain defined by
       [I-D.ietf-oauth-transaction-tokens], [RFC8693], and local policy.

6.2.2.  Identity-Only Subject Tokens

   ID tokens and refresh tokens are identity-only subject_token inputs.
   For these inputs, this document defines the following common model:

   *  the validated input establishes sub;

   *  sub_profile, if available from the validated input or trusted
      state, becomes supporting subject state;

   *  the input does not establish inbound act chain state for
      propagation;

   *  the input does not establish presenter continuity;





McGuinness               Expires 1 November 2026               [Page 39]

Internet-Draft             OAuth Actor Profile                April 2026


   *  any act in the issued token therefore comes from a validated
      actor_token or another independent delegation basis under local
      policy;

   *  any sender-constrained issued token is therefore issued in
      presenter-rebind mode, with the new presenter established in the
      current exchange.

6.2.2.1.  OpenID Connect ID Token

6.2.2.1.1.  Overview

   An OpenID Connect ID token [OpenID.Core] is a JWT issued by an OpenID
   Provider (OP) that asserts the authenticated identity of a user.  Its
   sub identifies the user, its aud identifies the relying party (the
   OAuth client) to which it was issued, and it may carry azp as an
   authorized-party/client identifier per [OpenID.Core].  Under this
   profile, aud and azp remain client-identity inputs; they do not
   establish actor identity.  ID tokens carry no act claim and no
   delegation chain; they establish the user's identity only.

   In this profile, ID tokens serve as subject_token in Token Exchange
   requests to introduce a user identity into a delegation chain.  The
   acting party is established by the actor_token.  This is the
   foundational pattern for cross-domain identity chaining: the user's
   OIDC identity flows forward as sub in the issued token while the
   actor identity becomes act.sub.

6.2.2.1.2.  Processing

   When a Token Exchange request ([RFC8693]) presents an ID token as the
   subject_token (subject_token_type=urn:ietf:params:oauth:token-
   type:id_token), the AS MUST apply the following steps.

   1.  The AS MUST validate the ID token per [OpenID.Core] and local
       policy before using it as actor-profile input.  Any checks on aud
       or azp remain OpenID Connect and client-identity checks; they do
       not by themselves establish the delegated actor under this
       profile.

   2.  The AS MUST use the validated ID token's sub as the subject
       identity for the issued token, subject to the same-subject
       preservation rule in JWT Access Token Output (Section 6.5.2).

   3.  The AS SHOULD set sub_profile to user in the issued token if it
       can authoritatively classify the ID token's sub as a human user
       identity and no conflicting subject classification is available
       under local policy.



McGuinness               Expires 1 November 2026               [Page 40]

Internet-Draft             OAuth Actor Profile                April 2026


   4.  The ID token is an identity-only subject_token for Presenter
       Transition Model (Section 6.1).  It does not establish actor
       identity or presenter continuity.  If an actor_token is present,
       the AS MUST process it per its type-specific rules and MUST use
       the derived actor identity as act.sub.  If the issued token is
       sender-constrained, that actor_token also establishes the new
       presenter for presenter-rebind mode.  If no actor_token or
       independent delegation basis is present, the AS MUST NOT include
       act in the issued token.

   5.  The AS MUST apply the propagation rules in JWT Access Token
       Output (Section 6.5.2) to determine the remaining claims in the
       issued token.  Because an ID token carries no inbound act chain
       and no OAuth scope ceiling, delegation-chain construction and
       scope determination come from the actor_token (if any),
       [RFC8693], and local policy rather than from the ID token itself.

6.2.2.2.  Refresh Token

6.2.2.2.1.  Overview

   A refresh token is a long-lived credential issued by an AS to a
   specific OAuth client that authorizes that client to obtain new
   access tokens without repeating end-user authentication.  Refresh
   tokens are opaque by design; they do not carry claims such as sub or
   act and are validated through the issuing AS's own token store rather
   than by signature verification.

   Refresh tokens MAY be presented as subject_token in a Token Exchange
   request to introduce a user's existing authorization into a
   delegation chain; for example, when a client authorized to use a
   user's refresh token needs a delegated access token for a specific
   resource.  This use is intended for same-AS deployments or
   deployments with a trusted back-channel to the issuing AS.  A refresh
   token MUST NOT be treated as a portable cross-domain delegation
   artifact.  Because refresh tokens carry no identity claims directly,
   the actor MUST be established by an actor_token in the same request
   or by an independent delegation basis under local policy.

   Refresh tokens MUST NOT be used as actor_token.  They carry no actor
   identity, are opaque credentials bound to a user authorization grant
   rather than to a workload or client identity, and cannot supply the
   sub value required to construct act.sub.

   This document does not standardize client-binding policy, cross-
   client presentation policy, or cross-AS acceptance policy for refresh
   tokens used as subject_token.  Those behaviors remain deployment-
   specific.  This document defines refresh-token subject_token



McGuinness               Expires 1 November 2026               [Page 41]

Internet-Draft             OAuth Actor Profile                April 2026


   processing only for deployments where the AS can validate the refresh
   token's authorization state directly or through a trusted back-
   channel.  Cross-AS refresh-token presentation without such validation
   is outside the interoperable scope of this profile.

6.2.2.2.2.  Processing

   When a Token Exchange request ([RFC8693]) presents a refresh token as
   the subject_token (subject_token_type=urn:ietf:params:oauth:token-
   type:refresh_token), the AS MUST apply the following steps.

   1.  The AS MUST validate the refresh token through its own token
       store or a trusted back-channel with the issuing AS.  Signature-
       based validation does not apply.  If the AS did not issue the
       refresh token, it MUST NOT accept the token unless it validates
       the token and obtains the associated subject, client binding,
       authorized scope, and revocation state through a trusted back-
       channel with the issuing AS.  If the token is expired, revoked,
       or otherwise invalid, the AS MUST reject the request with
       invalid_grant.

   2.  The AS MUST verify that the requesting client or authenticated
       presenter is authorized to use the refresh token under the
       refresh token's client-binding, sender-constraint, rotation, and
       cross-client presentation policy.  If the requester is not
       authorized to use the refresh token, the AS MUST reject the
       request with invalid_grant.

   3.  The AS MUST extract the subject identity and authorized scope
       associated with the refresh token from its token store or other
       trusted refresh-token state.  The sub of the user associated with
       the refresh token becomes sub in the issued token.  The AS SHOULD
       set sub_profile in the issued token if it can authoritatively
       classify the subject entity type.

   4.  Refresh tokens are identity-only subject_token inputs for
       Presenter Transition Model (Section 6.1); they do not establish
       presenter continuity or actor identity.  A refresh token alone
       does not establish delegation.  The acting party MUST be
       established by an actor_token or an independent delegation basis
       under local policy.  If neither is present, the AS MUST NOT
       include act in the issued token.  If an actor_token is present,
       the AS MUST process it per its type-specific rules and MUST use
       the actor identity derived by those rules as the outermost actor
       in the issued token.  If the issued token is sender-constrained,
       that actor_token also establishes the new presenter for
       presenter-rebind mode.




McGuinness               Expires 1 November 2026               [Page 42]

Internet-Draft             OAuth Actor Profile                April 2026


   5.  The effective scope of the issued token MUST be a subset of the
       scope authorized by the refresh token.  The AS MUST apply scope
       reduction per [RFC8693], Section 4 against that ceiling.

   After completing these checks, the AS MUST apply the propagation
   rules in JWT Access Token Output (Section 6.5.2) to determine the
   remaining claims in the issued token.

   This document does not standardize whether an AS issues refresh
   tokens in response to delegated JWT assertion grant requests, how
   such refresh tokens are revoked, or whether later use of such refresh
   tokens requires re-presentation of upstream delegation artifacts.
   Those decisions remain deployment-specific.

6.3.  Actor Tokens

   An actor_token of any type defined in this profile MUST identify the
   acting party in its top-level sub.  If the actor_token carries an act
   claim, indicating that the credential itself represents a delegation
   chain rather than a direct identity assertion, the AS MUST reject the
   request with invalid_grant.  This uniform rule preserves the
   identity-extraction invariant that the actor_token's top-level sub is
   the new outermost actor.  Type-specific sections below refine
   validation and presenter-rebind handling.

   Interoperable sub-delegation under this profile therefore requires
   every actor that may become a new presenter to possess a direct
   presenter credential naming itself in sub.  Deployments anticipating
   multi-hop chains SHOULD provision intermediate actors accordingly.

6.3.1.  JWT Client Assertion

6.3.1.1.  Overview

   A JWT client assertion per [RFC7523] may be presented as actor_token
   (actor_token_type=urn:ietf:params:oauth:token-type:jwt) to establish
   an OAuth client's own identity as the acting party.  Per [RFC7523],
   the assertion has iss = sub = client_id and is signed with the
   client's private key.  Under Presenter Transition Model
   (Section 6.1), it is a direct presenter credential.  Two usage
   patterns arise:

   *  The same JWT is presented as both client_assertion and actor_token
      in a single request, making the authenticated client identity
      explicit in the issued token's act chain.






McGuinness               Expires 1 November 2026               [Page 43]

Internet-Draft             OAuth Actor Profile                April 2026


   *  The client authenticates by another method (e.g., client_secret,
      mTLS) and presents a separate JWT client assertion as actor_token
      to name that same client as the actor.

   To establish a principal distinct from the OAuth client_id as the
   actor, the request MUST use a different actor credential type, such
   as a workload identity credential (Workload Credential Processing
   (Section 6.3.2.2)), whose sub names that distinct principal.  A
   client assertion conforming to [RFC7523] cannot name a subordinate
   identity.

6.3.1.2.  Processing

   When a Token Exchange request includes an actor_token that is a JWT
   client assertion, the AS MUST apply the following steps.

   1.  The AS MUST validate the actor_token per [RFC7523].  If the same
       JWT is also used as client_assertion for client authentication in
       the same request and this shared validation fails, the AS MUST
       reject the request with invalid_client; otherwise, the AS MUST
       reject the request with invalid_grant.

   2.  The AS MUST verify that the actor_token's iss is a client
       registered with the AS, that sub equals that client's client_id,
       and that local policy permits that client's assertion to be used
       as an actor credential.  If not, the AS MUST reject the request
       with invalid_grant.

   3.  The actor_token's sub identifies the immediate acting party.  The
       AS MUST use it as act.sub in the outermost act of the issued
       token and MUST set act.iss to the issuer or namespace context in
       which that actor identifier is to be interpreted.

   4.  When the actor_token is the same JWT presented as
       client_assertion for client authentication in the same request,
       the AS MAY derive the actor identity from the already-
       authenticated client context rather than re-validating the
       actor_token separately, provided the result is an identical
       act.sub value.  Actor-profile-specific policy failures that occur
       after successful client authentication are still invalid_grant,
       not invalid_client.

   5.  When the request uses this client assertion to establish a
       sender-constrained output token in presenter-rebind mode, the AS
       MUST validate any proof required by the selected proof mechanism
       for the new presenter per Sender Constraint and
       Proof-of-Possession Validation (Section 3.7).




McGuinness               Expires 1 November 2026               [Page 44]

Internet-Draft             OAuth Actor Profile                April 2026


   6.  When a subject_token is also present and carries an act chain:
       the actor_token's sub takes precedence as the new outermost actor
       identity.  Divergence (the actor_token's identified principal and
       the inbound outermost act.sub refer to different entities under
       their respective issuer or namespace contexts, with no trusted
       local mapping establishing equivalence) is the normal case in
       presenter-rebind flows and is permitted by default.  Local policy
       MAY restrict divergence for specific request paths where the
       actor_token is expected only to confirm an existing actor rather
       than introduce a new one; when such a restriction applies and the
       identities diverge, the AS MUST reject with invalid_grant.  Any
       prior act chain in the actor_token itself MUST NOT be
       automatically merged with the subject_token's chain; the AS MUST
       omit it from the issued token unless local policy defines a
       single unambiguous ordering, in which case the AS MAY preserve it
       subject to the chain-depth limit in Delegation Chains
       (Section 3.5).

6.3.2.  Workload Identity Credential

6.3.2.1.  Overview

   A workload identity credential is a JWT that asserts the identity of
   a software workload (such as a microservice, AI agent, or batch job).
   Unlike JWT assertion grants (JWT Assertion Grant Structure
   (Section 4.1)), whose sub identifies the principal on whose behalf
   the grant is made, a workload credential has the workload's own
   identifier in sub, making it the natural credential type for
   establishing an agent or service as the acting party.  Under
   Presenter Transition Model (Section 6.1), it is a direct presenter
   credential.  WIMSE workload credentials are defined in
   [I-D.ietf-wimse-workload-creds]; profile disambiguation is in Token
   Exchange Processing (Section 6).

   The recommended pattern for agentic Token Exchange is:

   *  subject_token: a JWT access token or JWT assertion grant carrying
      the user's sub and the delegation chain (act)

   *  actor_token: a workload identity credential whose sub is the agent
      or service identity

   *  Output: a JWT access token with the user as sub and the workload
      as the outermost act.sub







McGuinness               Expires 1 November 2026               [Page 45]

Internet-Draft             OAuth Actor Profile                April 2026


6.3.2.2.  Processing

   When a Token Exchange request ([RFC8693]) includes an actor_token
   that is a workload identity credential, the AS MUST apply the
   following steps.

   1.  The AS MUST validate the workload identity credential per its
       type specification.  For WIMSE workload identity credentials
       ([I-D.ietf-wimse-workload-creds]), validation follows the rules
       defined in that specification.  If validation fails, the AS MUST
       reject the request with invalid_grant.

   2.  The AS MUST verify that the workload credential's issuer (iss) is
       trusted under local policy to assert the workload's identity.  If
       not, the AS MUST reject the request with invalid_grant.

   3.  The workload credential's sub identifies the immediate acting
       party.  The AS MUST use it as act.sub in the outermost act of the
       issued token and MUST set act.iss to the issuer or namespace
       context in which that actor identifier is to be interpreted.

   4.  When the request uses this workload credential to establish a
       sender-constrained output token in presenter-rebind mode, the AS
       MUST validate the proof required by the workload-credential
       profile: a WIMSE Workload Proof Token (WPT, [I-D.ietf-wimse-wpt])
       per its specification, or a DPoP proof ([RFC9449]) over the token
       endpoint URI when the credential carries cnf.jkt.  If the
       required proof is absent or invalid, the AS MUST reject the
       request with invalid_grant.

   5.  When a subject_token is also present and carries an act chain:

       *  The workload credential's sub takes precedence as the new
          outermost actor identity.

       *  Divergence from the inbound outermost act.sub (the two
          identities refer to different entities under their respective
          issuer or namespace contexts, with no trusted local mapping
          establishing equivalence) is permitted by default, as this is
          the normal case in presenter-rebind flows.  Local policy MAY
          restrict divergence for paths where the actor_token is
          expected only to confirm an existing actor; when such a
          restriction applies and the identities diverge, the AS MUST
          reject with invalid_grant.

       *  Any prior act chain in the actor_token itself MUST NOT be
          automatically merged with the subject_token's chain; the AS
          MUST omit it from the issued token unless local policy defines



McGuinness               Expires 1 November 2026               [Page 46]

Internet-Draft             OAuth Actor Profile                April 2026


          a single unambiguous ordering, in which case the AS MAY
          preserve it subject to the chain-depth limit in Delegation
          Chains (Section 3.5).

6.3.3.  JWT Access Token

6.3.3.1.  Overview

   A non-delegated JWT access token may be presented as actor_token to
   establish a service or workload as the acting party; its top-level
   sub identifies the acting party and satisfies the direct-presenter-
   credential requirement in Presenter Transition Model (Section 6.1).
   A delegated JWT access token (one carrying act) does not satisfy that
   requirement; see Actor Tokens (Section 6.3) for the sub-delegation
   pattern.

6.3.3.2.  Processing

   When a Token Exchange request includes an actor_token that is a JWT
   access token (actor_token_type=urn:ietf:params:oauth:token-
   type:access_token), the AS MUST apply the following steps.  Use of an
   opaque access token as the actor_token is outside the interoperable
   scope of this profile (see Profile Scope (Section 3.3)).

   1.  The AS MUST validate the actor_token per [RFC9068].  If
       validation fails, the AS MUST reject the request with
       invalid_grant.

   2.  The AS MUST verify that the actor_token's iss is trusted under
       local policy to assert the acting party's identity in the top-
       level sub.  If trust cannot be established, the AS MUST reject
       the request with invalid_grant.

   3.  Apply the uniform actor_token rule in Actor Tokens (Section 6.3):
       if the actor_token carries act, the AS MUST reject the request
       with invalid_grant.

   4.  The actor_token's top-level sub identifies the immediate acting
       party.  The AS MUST use it as act.sub in the outermost act of the
       issued token and MUST set act.iss to the issuer or namespace
       context in which that actor identifier is to be interpreted.

   5.  When the request uses this JWT access token to establish a
       sender-constrained output token in presenter-rebind mode and the
       token carries top-level cnf, the AS MUST validate proof for that
       binding per Sender Constraint and Proof-of-Possession Validation
       (Section 3.7).




McGuinness               Expires 1 November 2026               [Page 47]

Internet-Draft             OAuth Actor Profile                April 2026


   6.  When a subject_token is also present and carries an act chain,
       the outermost actor identity derived from this actor_token takes
       precedence as the new outermost actor.  Divergence from the
       inbound outermost act.sub (the two identities refer to different
       entities under their respective issuer or namespace contexts,
       with no trusted local mapping establishing equivalence) is
       permitted by default.  Local policy MAY restrict divergence for
       paths where the actor_token is expected only to confirm an
       existing actor; when such a restriction applies and the
       identities diverge, the AS MUST reject with invalid_grant.

6.4.  may_act

   The may_act claim ([RFC8693], Section 4.4) pre-authorizes a specific
   party to act on behalf of the subject in a subsequent Token Exchange.
   This document defines limited use of may_act as a delegation-
   authorization input when actor identity is established by other
   means: when present in a validated subject_token, it MAY satisfy the
   delegation-authorization check in step 3 of Validate Outermost Actor
   (Section 3.6.2.2) without a separately pre-registered grant.  In no
   case is may_act itself the source of actor identity, and it MUST NOT
   be propagated into any output token.

   Two pre-conditions apply regardless of how the Token Exchange request
   is structured:

   1.  The subject_token issuer is trusted under local policy to assert
       may_act on behalf of the subject.

   2.  The canonical may_act identifier matches the derived actor
       identity under Identifier Reconciliation (Conventions and
       Definitions (Section 2)).

   Because [RFC8693] Section 4.4 defines may_act with only a sub member
   and no iss, the issuer or namespace context for may_act.sub is taken
   to be subject_token.iss; the canonical may_act identifier is
   therefore (subject_token.iss, may_act.sub).  The AS MUST apply
   configured mapping rules and MUST NOT infer equivalence from naming
   similarity alone.

   How actor identity is derived and how the identifier reconciliation
   check is performed depends on what the request supplies:









McGuinness               Expires 1 November 2026               [Page 48]

Internet-Draft             OAuth Actor Profile                April 2026


     +=============+==========================+======================+
     | Request     | Actor identity source    | Identifier           |
     | includes    |                          | Reconciliation       |
     +=============+==========================+======================+
     | actor_token | Derived from actor_token | Reconcile            |
     |             | per type-specific rules, | (subject_token.iss,  |
     |             | yielding (act.iss,       | may_act.sub) against |
     |             | act.sub)                 | (act.iss, act.sub)   |
     +-------------+--------------------------+----------------------+
     | No          | Authenticated            | Reconcile            |
     | actor_token | confidential client      | (subject_token.iss,  |
     |             | credential               | may_act.sub) against |
     |             |                          | the canonical client |
     |             |                          | identifier           |
     +-------------+--------------------------+----------------------+

                                  Table 2

   *actor_token present*: actor identity is derived from the actor_token
   per the applicable type-specific rules in this document, yielding the
   (act.iss, act.sub) pair.  The AS applies Identifier Reconciliation to
   determine whether (subject_token.iss, may_act.sub) refers to the same
   entity as (act.iss, act.sub).  may_act MUST NOT override the actor
   identity derived from the actor_token.

   *No actor_token present*: the requesting client MUST be a
   confidential client that has authenticated in the request; public
   clients MUST NOT use this path.  Actor identity is derived from the
   authenticated client credential.  The AS applies Identifier
   Reconciliation to determine whether (subject_token.iss, may_act.sub)
   refers to the same entity as the authenticated client, and sets
   act.sub to the canonical identifier of the authenticated client.  The
   AS MUST set act.iss to the issuer or namespace context that locally
   registered the authenticated client (typically the AS's own issuer
   URI when the client is registered directly with the AS).  This path
   enables the pre-authorization use case of [RFC8693], where the
   subject_token pre-authorizes a specific client and that client
   presents it directly without a separate actor_token.

   When may_act is absent or the conditions above are not met, the AS
   MUST satisfy the delegation-authorization check through another
   recognized basis (pre-registered grant, consent record, or applicable
   policy rule).  The AS MUST NOT treat the mere presence of may_act as
   authorization for any actor other than the one whose canonical
   identity matches it.

6.5.  Output Token Rules




McGuinness               Expires 1 November 2026               [Page 49]

Internet-Draft             OAuth Actor Profile                April 2026


6.5.1.  JWT Assertion Grant Output

   When requested_token_type in a Token Exchange request ([RFC8693])
   designates a JWT assertion grant as the output, whether by using
   urn:ietf:params:oauth:token-type:jwt or a more specific JWT
   assertion-grant token type defined by another specification (for
   example, an ID-JAG token type), the issued JWT MUST satisfy the
   structural requirements of JWT Assertion Grant Structure
   (Section 4.1).  A JWT assertion-grant token type URI is compatible
   with this section when it is defined as a profile of
   urn:ietf:params:oauth:token-type:jwt; for example,
   urn:ietf:params:oauth:token-type:id-jag as defined by
   [I-D.ietf-oauth-identity-assertion-authz-grant] is one such
   compatible type.  This section defines the actor-profile requirements
   for the resulting JWT assertion grant regardless of which compatible
   JWT assertion-grant output token type was requested.  The delegation
   chain MUST be constructed per JWT Access Token Output
   (Section 6.5.2).  The aud MUST be set to the downstream token
   endpoint (from the resource parameter or deployment configuration),
   and the assertion MUST be signed by the issuing AS.  The AS MUST NOT
   issue a JWT assertion grant as Token Exchange output unless it is
   configured to do so and can establish the delegation relationship
   under local policy.

6.5.2.  JWT Access Token Output

   The issued JWT access token MUST satisfy the structural requirements
   in JWT Access Token Structure (Section 5.1).  This section is the
   common output step for Token Exchange paths in this section that
   produce a JWT access token.  It is reached after completing the
   applicable class-level and type-specific subject_token processing
   defined above, the applicable actor_token processing, or Transaction
   Token Service processing.

   After completing the applicable subject_token processing in this
   section, whether for an identity-only input (ID Token Processing
   (Section 6.2.2.1.2), Refresh Token Processing (Section 6.2.2.2.2)) or
   a token-state input (JWT Assertion Grant as subject_token
   (Section 6.2.1.1), JWT Access Token as subject_token
   (Section 6.2.1.2), Transaction Token as subject_token
   (Section 6.2.1.3)), or after Transaction Token Service processing
   (Transaction Token Output Rules (Section 7.4)), the AS MUST apply the
   following rules when issuing a JWT access token.  These rules govern
   the delegation chain, subject, and scope in the issued token
   regardless of inbound credential type.






McGuinness               Expires 1 November 2026               [Page 50]

Internet-Draft             OAuth Actor Profile                April 2026


   When both a subject_token carrying an inbound act chain and an
   actor_token are present, the validated actor_token determines the new
   outermost actor identity in the issued token.  Any preserved inbound
   act chain from the subject_token is nested beneath that new outermost
   act; the validation and conflict rules are defined in the applicable
   actor_token section.

   When the issued token is sender-constrained, the issuer MUST bind the
   output token's top-level cnf according to Presenter Transition Model
   (Section 6.1):

   *  In presenter-continuation mode, the output token remains bound to
      the continued presenter of the validated PoP-capable
      subject_token.

   *  In presenter-rebind mode, the output token is bound to the new
      presenter established by the validated actor_token.

   *  Bearer-to-PoP upgrade is therefore performed by issuing a sender-
      constrained output token in presenter-rebind mode even when the
      inbound subject_token carried no top-level cnf.

   If a Token Exchange request explicitly seeks a delegated output, for
   example by supplying an actor_token or by presenting a subject_token
   that already carries act, and the AS cannot validate the actor
   information, it MUST reject the request with invalid_grant.  If the
   AS can validate the actor information but cannot establish or confirm
   the required delegation basis, or if local policy prohibits the
   relationship, it MUST reject the request with actor_unauthorized.
   The AS MUST NOT issue a non-delegated JWT access token in place of
   the requested delegated output.

   1.  When the issued access token represents delegation per Delegation
       Chains (Section 3.5), the AS MUST include an act claim.  The AS
       MUST NOT silently drop actor information.  If the inbound
       credential carries no act, no validated actor_token is present,
       and no independent delegation basis exists, the AS MUST omit act.

   2.  The AS MUST preserve sub to refer to the same underlying subject
       as the inbound token.  If the AS uses a different subject-
       identifier namespace, it MAY change the sub value only to re-
       express that same subject in the new namespace under a trusted
       local mapping.  The AS MUST NOT replace sub with an identifier
       for a different subject.  Subject-namespace translation
       requirements and relying-party consequences are described in
       Subject Namespace Translation (Section 14.9).





McGuinness               Expires 1 November 2026               [Page 51]

Internet-Draft             OAuth Actor Profile                April 2026


   3.  The AS MUST construct the act claim using the construction
       decision order in Delegation Chain Validation and Construction
       (Section 3.6).  In summary:

       *  first, when a new actor is identified, create a new outermost
          act object and nest any inbound chain beneath it (Extend Chain
          with New Actor (Section 3.6.3.1));

       *  otherwise, when an inbound chain is present, copy that chain
          unchanged (Preserve Inbound Chain (Section 3.6.3.2));

       *  otherwise, omit act from the issued token (Omit act
          (Section 3.6.3.3)).

       The act.iss obligation applies only to an act object the AS
       creates for the current actor.  Inherited act objects MUST NOT be
       rewritten.

       When the actor identity was derived from an actor_token parameter
       rather than from an act claim in the subject_token, the outermost
       act in the issued token is AS-asserted based on the validated
       actor_token; it is not chain-propagated from the subject_token.
       Consumers MUST NOT infer that the actor_token-derived act was
       present in or endorsed by the subject_token issuer.

   4.  If actor information that would be preserved or added to the
       issued token cannot be validated, or nesting would exceed the
       chain-depth limit in Delegation Chains (Section 3.5), the AS MUST
       reject the request.  The AS MUST return invalid_request when the
       chain-depth limit would be exceeded and invalid_grant when actor
       information fails validation; these error codes apply equally to
       Token Exchange requests producing JWT access tokens.  Note: a
       missing required structural claim (act.sub or act.iss) in the
       inbound token is a structural violation that produces
       invalid_request, not a validation failure that produces
       invalid_grant.  The AS MUST NOT issue a token that partially
       preserves the delegation chain.

   5.  The AS SHOULD include sub_profile in the issued token's top-level
       claims if it can authoritatively classify the token's sub entity
       type.

   6.  The AS MUST apply scope reduction per [RFC8693], Section 4.  If
       the reduction required by [RFC8693] yields an empty scope, the AS
       MUST reject the request with invalid_scope.

       When the AS additionally applies actor-based scope restriction
       based on the (sub, act.sub) pair or the actor's sub_profile:



McGuinness               Expires 1 November 2026               [Page 52]

Internet-Draft             OAuth Actor Profile                April 2026


       *  The AS MUST include the effective scope value in the token
          response so that clients can detect any reduction from the
          requested scope.

       *  If actor-based restriction yields an empty scope because the
          actor is categorically unauthorized for any of the remaining
          scope (for example, the actor's sub_profile is not permitted
          for any of the requested scope values), the AS MUST reject
          with actor_unauthorized.

       *  If actor-based restriction yields an empty scope for a reason
          unrelated to the actor's categorical authorization (for
          example, because the actor's scope ceiling simply does not
          include the requested values), the AS MUST reject with
          invalid_scope.

       *  The scope value in the token response MUST reflect the
          effective granted scope after all reductions, including any
          actor-based reduction.  This is consistent with the existing
          requirement in [RFC8693], Section 4 that scope in the response
          indicate the actual authorized scope.  Silent divergence
          between the requested scope and the issued token's scope is
          not permitted.

   7.  If the inbound credential carries client_id, azp, or both, the AS
       MAY preserve those values per the output token profile or local
       policy.  If preserved:

       *  They MUST continue to identify the OAuth client and MUST NOT
          be rewritten to represent delegation state that belongs in
          act.

       *  If preserving them would create ambiguity about the delegated
          actor relationship, the AS SHOULD omit them.

       See Client Identity and Delegation (Section 14.7) for the
       normative rules governing client identity and actor identity.

   8.  Clients SHOULD use the resource parameter ([RFC8707]) when
       requesting delegated tokens to restrict the issued token's aud
       claim to the intended resource server.  The AS MUST honor
       resource-indicator constraints in delegated token requests per
       [RFC8693], Section 4.2.  Audience-scoped delegation limits the
       blast radius of a compromised token by preventing its
       presentation to resource servers other than the one it was issued
       for.  This profile does not define a new mechanism for audience
       restriction; it applies the existing resource parameter and aud
       claim semantics to the delegated-token context.



McGuinness               Expires 1 November 2026               [Page 53]

Internet-Draft             OAuth Actor Profile                April 2026


7.  Transaction Token Service Processing

   This section defines the actor-profile claim structure for
   Transaction Tokens and the rules a Transaction Token Service (TTS)
   applies when it validates supported subject_token inputs,
   authenticates the new presenter, and issues a delegated Transaction
   Token.

   TTS error handling for requests processed in this section is defined
   in Error Responses (Section 9).

7.1.  Transaction Tokens

   Transaction Tokens [I-D.ietf-oauth-transaction-tokens] are short-
   lived JWTs that capture the workload identity and request context for
   a series of related service calls within a single business
   transaction.  They are issued by a Transaction Token Service (TTS),
   which is a specialized authorization server.

   Transaction Token claims are defined in
   [I-D.ietf-oauth-transaction-tokens].  This profile modifies or adds
   the following claims:

   iss (OPTIONAL in [I-D.ietf-oauth-transaction-tokens]; REQUIRED by
   this profile when carrying act):  Issuer of the Transaction Token.
      MUST be present when the Transaction Token carries an act claim,
      because recipients need to identify the token issuer before
      deciding whether to trust the actor identifier pairs carried in
      the chain.  SHOULD be present when the Transaction Token crosses
      trust-domain boundaries, even in non-delegated cases, as
      recipients can require it to validate issuer identity or chain-of-
      trust per local policy.  MAY be omitted only when no delegation
      (act) is present, all tokens are scoped to a single Trust Domain,
      and all recipients have out-of-band knowledge of the issuer.  When
      iss is omitted, recipients MUST rely on the trust-domain and
      issuer-identification rules of [I-D.ietf-oauth-transaction-tokens]
      and local deployment configuration rather than the generic outer-
      token iss processing rules in this document.

   req_wl:  This claim provides TTS-level workload context and is not a
      substitute for act.sub; see Actor Claim in Transaction Tokens
      (Section 7.1.1).

   act (REQUIRED when delegated; OPTIONAL otherwise):  Represents the
      current acting party and any prior delegation steps, conforming to
      Actor Object Structure (Section 3.4).  See Actor Claim in
      Transaction Tokens (Section 7.1.1) for delegation semantics and
      the relationship between act.sub and req_wl.



McGuinness               Expires 1 November 2026               [Page 54]

Internet-Draft             OAuth Actor Profile                April 2026


7.1.1.  Actor Claim in Transaction Tokens

   A Transaction Token is delegated for purposes of this document when
   it carries an explicit actor credential (either an actor_token in the
   exchange request or an inbound token that already contains an act
   chain) establishing that the requesting workload is acting on behalf
   of the identified sub rather than in its own right.  In a delegated
   Transaction Token, the act claim conforming to this profile MUST be
   included to represent the current acting party and any prior
   delegation steps, as specified in Transaction Token Output Rules
   (Section 7.4).  Because a delegated Transaction Token carries act, it
   MUST also carry a top-level iss claim per Transaction Tokens
   (Section 7.1).  In non-delegated Transaction Tokens (those issued for
   a workload acting under its own independent grant, where no explicit
   actor credential was presented), act is OPTIONAL.  The TTS MUST NOT
   infer delegation solely from the fact that sub and req_wl identify
   different entities; the presence of an explicit actor credential is
   required.

   req_wl identifies the workload that requested the token from the TTS.
   act.sub identifies the immediate acting party in the subject
   identifier namespace used by this profile.  The authoritative actor
   identifier for authorization decisions under this document is the
   outermost act.sub; req_wl is supporting workload context.

   Claim semantics under this profile:

   *  sub: identifies the original initiator.  When a Transaction Token
      is exchanged for a replacement, the new token MUST continue to
      refer to the same underlying subject.  The issuer MAY change sub
      only to re-express that same subject in a different identifier
      namespace.

   *  act.sub (outermost): identifies the immediate acting party.  When
      a TTS sets both req_wl and the new outermost act.sub in a single
      token issuance (presenter-rebind mode), it MUST ensure they
      identify the same entity under local policy.  When a TTS preserves
      req_wl from an inbound token, the TTS SHOULD perform identifier
      reconciliation between req_wl and the outermost act.sub.  When a
      recipient relies on both and cannot reconcile them under local
      policy, the recipient MUST reject the token.

   *  Inner act objects: identify prior presenters in the delegation
      path.  act.sub_profile at each level classifies the entity type of
      that presenter.

   The following example shows a Transaction Token after two hops:




McGuinness               Expires 1 November 2026               [Page 55]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://tts.enterprise.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "sub_profile": "user",
     "scope": "inventory:check",
     "req_wl": "https://tools.example.com/booking-tool",
     "aud": "https://api.travel-provider.example",
     "txn": "550e8400-e29b-41d4-a716-446655440000",
     "exp": 1711816900,
     "iat": 1711816800,
     "tctx": {
       "action": "check-availability"
     },
     "rctx": {
       "req_ip": "203.0.113.42"
     },
     "cnf": {
       "jkt": "0ZcOCORZNYy9ZhHiZN..."
     },
     "act": {
       "sub": "https://tools.example.com/booking-tool",
       "iss": "https://as.travel-provider.example",
       "sub_profile": "service",
       "act": {
         "sub": "https://agents.example.com/travel-assistant",
         "iss": "https://as.enterprise.example",
         "sub_profile": "ai_agent"
       }
     }
   }

   In this example the booking tool is the current presenter.  It is
   identified by req_wl as the workload that requested the token and by
   the outermost act.sub in the actor profile's subject namespace, and
   it has its own top-level cnf.jkt.  The travel assistant appears as a
   nested act object, showing that it was the prior delegated actor
   between Alice and the booking tool.

7.2.  Presenter Authentication and Transition

   The TTS applies the same two presenter-transition modes defined in
   Presenter Transition Model (Section 6.1), but only for token-state
   subject_token inputs:

   *  *Presenter continuation*: the authenticated requester is the same
      current presenter as the inbound token.  This mode is available
      only when the inbound token carries a top-level presenter binding
      and the TTS validates proof for that binding under



McGuinness               Expires 1 November 2026               [Page 56]

Internet-Draft             OAuth Actor Profile                April 2026


      [I-D.ietf-oauth-transaction-tokens] and the applicable deployment
      profile.  When the inbound token carries act, the authenticated
      requester MUST correspond to the outermost (act.iss, act.sub)
      pair.  In this mode the TTS preserves the inbound act chain
      unchanged and MUST NOT add a new outermost act.

   *  *Presenter rebind*: a validated actor_token direct presenter
      credential establishes a different current presenter for the
      issued Transaction Token.  In this mode the TTS creates a new
      outermost act for that presenter and nests any inbound act chain
      beneath it.

   A bearer token-state subject_token that carries no presenter binding
   is not eligible for presenter continuation, but it MAY still be
   upgraded to a sender-constrained Transaction Token in presenter-
   rebind mode when a validated actor_token establishes the new
   presenter.  This document does not define TTS processing for
   identity-only subject_token inputs such as ID tokens or refresh
   tokens.

7.3.  Supported Subject Tokens

   The TTS accepts only token-state subject_token inputs.  Identity-only
   inputs such as ID tokens and refresh tokens do not carry the inbound
   delegation-chain or presenter state needed for Transaction Token
   Output Rules (Section 7.4) and are therefore outside the scope of the
   TTS profile defined here.

7.3.1.  JWT Assertion Grant

   When the TTS receives a JWT assertion grant as subject_token, it MUST
   apply the validation, presenter-continuity, and scope-reduction rules
   in JWT Assertion Grant as subject_token (Section 6.2.1.1).  Instead
   of applying JWT Access Token Output (Section 6.5.2), the TTS uses the
   resulting subject identity, optional sub_profile, inbound act chain,
   proof-of-possession state, and effective scope ceiling as the inbound
   delegation state for Transaction Token Output Rules (Section 7.4).

7.3.2.  JWT Access Token

   When the TTS receives a JWT access token as subject_token, it MUST
   apply the validation and extraction rules in JWT Access Token as
   subject_token (Section 6.2.1.2).  Instead of applying JWT Access
   Token Output (Section 6.5.2), the TTS uses the resulting inbound
   delegation state as input to Transaction Token Output Rules
   (Section 7.4).





McGuinness               Expires 1 November 2026               [Page 57]

Internet-Draft             OAuth Actor Profile                April 2026


7.3.3.  Transaction Token

   When the TTS receives a Transaction Token as subject_token, it MUST
   apply the validation and extraction rules in Transaction Token as
   subject_token (Section 6.2.1.3).  Instead of applying JWT Access
   Token Output (Section 6.5.2), the TTS uses the extracted sub,
   optional sub_profile, inbound act chain, req_wl, and presenter-
   binding state as input to Transaction Token Output Rules
   (Section 7.4).

7.4.  Transaction Token Output Rules

   TTS processing follows the generic delegation chain algorithm defined
   in Delegation Chain Validation and Construction (Section 3.6) and the
   output rules in JWT Access Token Output (Section 6.5.2).  The steps
   below apply those rules to the Transaction Token context and define
   the TTS-specific adaptations: req_wl handling, the TTS presenter-
   authentication model, Transaction Token claim set requirements, and
   the treatment of iss in Transaction Tokens.  Where a step below is
   parallel to JWT access token processing, the TTS-specific detail is
   noted explicitly.

   When a TTS receives a token-exchange request to issue or refresh a
   Transaction Token from an inbound JWT assertion grant, JWT access
   token, or Transaction Token that carries actor-profile claims, it
   MUST apply the following rules:

   1.  The TTS MUST preserve sub from the inbound token to refer to the
       same underlying subject.

       *  The TTS MAY re-express sub in a different identifier namespace
          only when a trusted local mapping establishes that both
          identifiers refer to the same underlying subject (for example,
          when crossing trust-domain boundaries in a federation
          scenario).

       *  The TTS MUST NOT replace sub with an identifier for a
          different subject.

          Note: Subject-namespace translation requirements and relying-
          party consequences are described in Subject Namespace
          Translation (Section 14.9).

   2.  The req_wl field and any Transaction Token fields other than
       actor-profile claims remain governed by
       [I-D.ietf-oauth-transaction-tokens] and local policy.  Under this
       profile, req_wl is supporting workload context and MUST NOT be
       treated as a substitute for the outermost act.sub.



McGuinness               Expires 1 November 2026               [Page 58]

Internet-Draft             OAuth Actor Profile                April 2026


   3.  The TTS MUST compute the depth of the resulting act chain after
       applying step 6.  If that resulting chain would exceed the limit
       in Delegation Chains (Section 3.5), the TTS MUST reject the
       request with invalid_request.

   4.  The TTS MUST validate the inbound token and establish issuer
       trust before preserving or extending any act chain.  For the
       outermost act object in the inbound chain, the TTS MUST:

       *  Verify that the inbound token issuer is trusted under local
          policy to assert the (act.iss, act.sub) actor identifier pair,
          using local trust mechanisms equivalent to Validate Outermost
          Actor (Section 3.6.2.2).

       *  Evaluate the delegation relationship per Validate Outermost
          Actor (Section 3.6.2.2), applying the same creation-vs-
          preservation distinction: MUST evaluate when installing a new
          outermost actor in presenter-rebind mode; SHOULD evaluate
          under local policy when preserving an existing chain from a
          trusted upstream issuer in presenter-continuation mode.

       For inner act objects in the inbound chain:

       *  *Security-relevant use*: If local policy uses an inner entry
          as an input to access control or scope decisions, the TTS
          SHOULD apply the same validation as for the outermost entry.
          If the TTS cannot validate it to the required assurance level,
          it SHOULD reject with invalid_grant.

       *  *Prior-actor context only*: If an inner entry is preserved
          solely for audit purposes without driving any security
          decision, apply Carry Prior-Actor Context (Section 3.6.2.4).

   5.  The TTS MUST determine whether the request is presenter
       continuation or presenter rebind:

       *  *Presenter continuation*: The TTS MUST authenticate the
          requester as the same current presenter as the inbound token.
          When the inbound token carries act, the authenticated
          requester MUST correspond to the outermost (act.iss, act.sub)
          pair or the TTS MUST reject the request with invalid_grant.
          If the required actor relationship is prohibited by local
          policy, absent, or cannot be confirmed from the current inputs
          and policy, the TTS MUST reject the request with
          actor_unauthorized.






McGuinness               Expires 1 November 2026               [Page 59]

Internet-Draft             OAuth Actor Profile                April 2026


       *  *Presenter rebind*: The TTS MUST validate a direct presenter
          actor_token for the new presenter.  Before creating a new
          outermost act object, the TTS MUST evaluate whether the newly
          authenticated presenter is authorized under local policy to
          act on behalf of sub for the requested transaction.  If the
          required actor relationship is prohibited by local policy,
          absent, or cannot be confirmed from the current inputs and
          policy, the TTS MUST reject the request with
          actor_unauthorized.

       If the current inputs satisfy neither presenter-continuation nor
       presenter-rebind requirements, the TTS MUST reject the request
       with invalid_grant.

   6.  When the issued Transaction Token carries delegated actor
       information, the TTS MUST include a top-level iss claim
       identifying itself as the Transaction Token issuer, and it MUST
       construct the act claim using Delegation Chain Validation and
       Construction (Section 3.6).  In summary:

       *  in presenter-continuation mode, preserve the inbound chain
          unchanged (Preserve Inbound Chain (Section 3.6.3.2));

       *  in presenter-rebind mode, create a new outermost act object
          for the new presenter and nest any inbound chain beneath it
          (Extend Chain with New Actor (Section 3.6.3.1)).

       For a new outermost actor, the TTS MUST set act.sub to the new
       presenter's identifier, MUST set act.iss to the issuer or
       namespace context for that identifier, and SHOULD set
       act.sub_profile when known.  Inherited act objects MUST NOT be
       rewritten.

   7.  When the issued Transaction Token includes a top-level presenter-
       binding claim such as cnf, that binding applies to the current
       presenter.  The underlying presenter-authentication and proof
       mechanism is defined by [I-D.ietf-oauth-transaction-tokens] and
       any applicable deployment profile, not by this document.

   8.  Transaction Token fields other than actor-profile claims,
       including scope, tctx, and rctx, are defined by
       [I-D.ietf-oauth-transaction-tokens] and local policy.  This
       document does not standardize their issuance semantics.








McGuinness               Expires 1 November 2026               [Page 60]

Internet-Draft             OAuth Actor Profile                April 2026


   These same preservation rules apply regardless of whether the inbound
   credential is a JWT assertion grant, a JWT access token, or a
   Transaction Token, provided that the TTS supports issuing a
   Transaction Token from that input.  This document does not define
   direct Transaction Token issuance from ID tokens or refresh tokens.

   This document does not define TTS-specific processing for may_act.  A
   deployment MAY use may_act under local policy or another
   specification as a transaction-authorization hint, but that behavior
   is outside the scope of this document and MUST NOT replace validation
   of the inbound credential, presenter authentication, or the rules in
   this document governing whether a new outermost act is created.

8.  Resource Server Processing

   This section brings together the normative rules for delegated-token
   consumers at the resource server and the actor authorization model
   they apply, whether the RS evaluates a JWT directly or relies on
   introspection.

8.1.  Actor Authorization

   When a token contains both sub and an act claim, a resource server
   has two independent principals available for authorization policy:

   *  *Subject principal* (sub): the party whose authorization is being
      exercised.  This principal typically has a relationship with the
      resource (e.g., an account, a role, a permission).

   *  *Actor principal* (act.sub): the party that is making the
      immediate request.  This principal may be in a different
      organizational domain and trust level from the subject.

   For Transaction Tokens, the primary policy pair remains (sub,
   act.sub).  The req_wl claim provides workload context from the TTS
   and is not a replacement for act.sub.  Nested act objects provide
   prior-actor context for audit or other deployment-specific
   processing; this document does not standardize their authorization
   use.

   Actor authorization is conditional under this profile.  When an RS
   accepts a token as satisfying a delegated-access requirement, it MUST
   NOT ignore the act claim and authorize the request solely as if the
   token were non-delegated.  The RS SHOULD evaluate the (sub, outermost
   act.sub) pair according to local policy.  Resource servers that
   receive delegated tokens SHOULD define and document their actor
   authorization policy.  The following steps describe one approach for
   resource servers that choose to enforce actor authorization policy:



McGuinness               Expires 1 November 2026               [Page 61]

Internet-Draft             OAuth Actor Profile                April 2026


   1.  *Advertise delegated-token requirements*: An RS that wants to
       signal that delegated requests are expected to carry actor-
       profile information SHOULD set actor_profile_required: true
       (Protected Resource Metadata (Section 10.2)).  An RS MAY still
       apply actor authorization without advertising it, but clients
       MUST NOT rely on that behavior.

   2.  *Evaluate subject authorization*: Determine whether sub has been
       granted the requested scope or permission, using the same
       mechanisms applied to non-delegated tokens.

   3.  *Evaluate actor authorization*: Determine whether the (sub,
       outermost act.sub) pair is permitted for the requested operation.
       This evaluation MAY be performed against:

       *  a registered delegation policy for the (subject, actor) pair,

       *  the actor's sub_profile (e.g., only AI agents from a trusted
          domain are permitted to act as delegatees),

       *  the token's scope claim.

       For Transaction Tokens, the RS SHOULD evaluate req_wl as
       supporting context.  If the RS relies on both req_wl and act.sub
       to identify the current presenter and cannot reconcile them under
       local policy, it MUST reject the request.

   4.  *Evaluate combined policy*: Apply resource-specific actor
       authorization policies (e.g., requiring both principals to have
       agreed to terms of service).

   5.  If the RS requires actor authorization but cannot complete it, it
       MUST reject the request.

   When a deployment applies multi-principal authorization under local
   policy, the outermost act.sub remains the baseline interoperable
   actor identifier, while nested act objects are additional local-
   policy inputs only.  Failure semantics, ordering, and weighting for
   those nested actors are deployment-specific.  Clients MUST NOT assume
   that nested actors will be used for authorization unless deployment-
   specific agreements say otherwise.










McGuinness               Expires 1 November 2026               [Page 62]

Internet-Draft             OAuth Actor Profile                April 2026


8.2.  JWT Access Token Processing

   Upon receiving a JWT access token on a request path where delegated-
   token processing may apply, a resource server MUST validate and
   process that token according to its local delegated-token policy.
   For RS processing purposes, a JWT access token is evaluated as
   delegated when it carries an act claim conforming to this profile;
   the RS MUST NOT infer delegation from azp, client_id, or other
   client-identity claims alone.  The authorization-policy model for
   delegated tokens is defined in Resource Server Processing
   (Section 8).  Protected resource metadata can advertise delegated-
   token expectations to clients, but the RS's enforcement decision
   remains local to the resource server.

   When the resource server evaluates a JWT access token as a delegated
   token under local policy, it MUST:

   1.  Validate the token's signature, iss, aud, and temporal claims per
       [RFC9068].  If local policy for the request path requires actor-
       profile conformance for delegated requests (including when the
       resource advertises actor_profile_required: true per Protected
       Resource Metadata (Section 10.2)), any token the RS evaluates as
       delegated MUST carry act, and each act object the RS relies on
       MUST include act.iss; if either is missing, the RS MUST reject
       the request with HTTP 401 invalid_token.  The
       actor_profile_required: true signal does not require non-
       delegated tokens for the same resource to carry act.

   2.  If the token carries a top-level cnf.jkt, validate the
       accompanying DPoP proof per [RFC9449], Section 7.  If a DPoP
       proof is present but the token does not carry cnf.jkt, the RS
       MUST treat the token as a bearer token; the RS MUST NOT infer a
       confirmation binding from the DPoP proof key.

   3.  Extract the sub and the outermost act.sub as the two principals
       relevant for authorization policy.

   4.  If the token carries client_id, azp, or both, treat those as
       client-identity inputs only.  The RS SHOULD use act.sub rather
       than client_id or azp as the actor identifier when act is
       present.  When local policy expects both to identify the same
       acting party, the RS SHOULD perform identifier reconciliation; if
       reconciliation cannot be established, the RS MUST either treat
       them as distinct identifiers or reject the request according to
       local policy.  See Client Identity and Delegation (Section 14.7).






McGuinness               Expires 1 November 2026               [Page 63]

Internet-Draft             OAuth Actor Profile                April 2026


   5.  Apply actor authorization per Actor Authorization (Section 8.1)
       when required by local policy or when the token is accepted as
       satisfying a delegated-access requirement for the request path.
       Resource servers that do not require actor authorization SHOULD
       still evaluate the actor as part of authorization, audit, or
       trust decisions.

   6.  The RS MAY traverse inner act objects for audit, policy
       refinement, or trust decisions; such use is deployment-specific.
       Inner act objects are prior-actor context as described in Carry
       Prior-Actor Context (Section 3.6.2.4), and interoperable
       authorization behavior is defined around sub and the outermost
       act.sub.

   7.  If any of the above steps fail, return an appropriate error
       response.  The HTTP authentication scheme used in the WWW-
       Authenticate challenge follows the token's binding mechanism:
       Bearer per [RFC6750], Section 3.1 for bearer or mTLS-bound
       ([RFC8705]) tokens, or DPoP per [RFC9449], Section 7.1 for DPoP-
       bound tokens.

       *  If signature, iss, aud, or temporal validation fails: HTTP 401
          with error="invalid_token".

       *  If DPoP proof validation for cnf.jkt fails: HTTP 401 per
          [RFC9449], Section 7.

       *  If the token is structurally valid but the actor fails an
          authorization evaluation required by local policy, including
          actor authorization when required: HTTP 403 with
          error="actor_unauthorized".  The error attribute supports
          extension values registered in the OAuth Extensions Error
          Registry; actor_unauthorized is registered by this document
          (OAuth Error Registry (Section 16.4)).  The RS MUST NOT use
          error="insufficient_scope" to signal actor authorization
          failures; that error code indicates the token's scope is
          insufficient for the operation and implies the client should
          retry with broader scope, which does not describe an actor
          identity or delegation policy failure.

       *  The RS MUST NOT include actor-specific rejection details in
          error responses exposed to clients outside the trust domain.









McGuinness               Expires 1 November 2026               [Page 64]

Internet-Draft             OAuth Actor Profile                April 2026


8.3.  Transaction Token Processing

   Upon receiving a Transaction Token on a request path where delegated-
   token processing may apply, a resource server MUST validate and
   process that token according to [I-D.ietf-oauth-transaction-tokens],
   any applicable deployment profile, and the actor-profile rules in
   this document.

   When the resource server evaluates a Transaction Token as a delegated
   token under local policy, it MUST:

   1.  Validate the Transaction Token per
       [I-D.ietf-oauth-transaction-tokens] and local deployment profile
       (signature, aud, temporal claims, and issuer identification).
       When the token carries an act claim, the top-level iss claim MUST
       be present and the RS MUST validate it as the Transaction Token
       issuer identifier.  When the token carries no act claim and iss
       is absent, the RS MUST determine the issuer using the trust-
       domain and issuer-identification rules of
       [I-D.ietf-oauth-transaction-tokens] and local deployment
       configuration.  If local policy for the request path requires
       actor-profile conformance for delegated requests (including when
       the resource advertises actor_profile_required: true per
       Protected Resource Metadata (Section 10.2)), any Transaction
       Token the RS evaluates as delegated MUST carry act, and each act
       object the RS relies on MUST include act.iss; if either is
       missing, the RS MUST reject the request.  The
       actor_profile_required: true signal does not require non-
       delegated Transaction Tokens for the same resource to carry act.

   2.  When the token carries a top-level presenter-binding claim such
       as cnf, validate the accompanying proof according to
       [I-D.ietf-oauth-transaction-tokens] and the applicable deployment
       profile.  The top-level presenter binding applies to the current
       presenter only.

   3.  Extract sub and the outermost act.sub as the two principals
       relevant for authorization policy.  If req_wl is present, treat
       it as supporting workload context only.  The RS MUST NOT treat
       req_wl as a substitute for act.sub.  When local policy expects
       req_wl and the outermost act.sub to identify the same party, the
       RS SHOULD perform identifier reconciliation; if reconciliation
       cannot be established, the RS MUST either treat them as distinct
       identifiers or reject the request according to local policy.

   4.  Apply actor authorization per Actor Authorization (Section 8.1)
       when required by local policy or when the token is accepted as
       satisfying a delegated-access requirement for the request path.



McGuinness               Expires 1 November 2026               [Page 65]

Internet-Draft             OAuth Actor Profile                April 2026


       Resource servers that do not require actor authorization SHOULD
       still evaluate the actor as part of authorization, audit, or
       trust decisions.

   5.  Optionally traverse inner act objects to audit the full
       delegation chain.  If the RS relies on inner act objects for
       audit, policy refinement, or trust decisions, it MUST do so only
       under the prior-actor context rules in Carry Prior-Actor Context
       (Section 3.6.2.4).

   6.  If any of the above steps fail, the RS MUST reject the request
       according to the Transaction Token mechanism in use and local
       deployment profile.  Validation or presenter-proof failures are
       token-validation failures; actor-policy failures required by
       local policy are authorization failures.  The RS MUST NOT include
       actor-specific rejection details in error responses exposed
       outside the trust domain.

8.4.  Token Introspection

   When token introspection ([RFC7662]) is used for delegated tokens, an
   AS MUST expose actor-profile information needed for equivalent RS
   processing.  For an active delegated token whose authorization
   context includes actor-profile claims, the introspection response
   MUST include:

   *  active: REQUIRED.  MUST be true for an active token.

   *  sub: REQUIRED.  The subject of the delegated token, as defined in
      [RFC7662].

   *  act: REQUIRED.  The actor object conforming to Actor Object
      Structure (Section 3.4), including act.sub, act.iss, and any
      nested act chain, structured identically to the JWT form defined
      in this document.

   *  sub_profile: REQUIRED when the token's authorization context
      includes a top-level sub_profile; otherwise SHOULD be included
      when the AS can authoritatively classify the subject entity type.

   *  scope: REQUIRED.  The effective scope of the token.

   *  iss: REQUIRED when the AS has a stable issuer identifier.

   *  chain_complete: OPTIONAL.  When absent, the RS SHOULD treat the
      chain as complete unless local policy or deployment context
      indicates otherwise.




McGuinness               Expires 1 November 2026               [Page 66]

Internet-Draft             OAuth Actor Profile                April 2026


   An AS MUST NOT omit actor-profile claims that are part of the
   delegated token's authorization context, because doing so would
   misrepresent the token's delegation status to the introspecting RS.
   When a delegated token carries a nested act chain, the AS MUST
   include the complete nested act structure unless local privacy policy
   requires omitting specific inner chain entries.

   When local privacy policy requires omitting specific inner chain
   entries, the AS MAY return a filtered act chain but MUST include
   "chain_complete": false.  The AS SHOULD NOT filter inner chain
   entries when it has knowledge (for example, from
   actor_profile_required metadata (Protected Resource Metadata
   (Section 10.2)), deployment configuration, or bilateral agreement)
   that the RS uses one or more inner chain entries as inputs to
   authorization, scope, or other security decisions.  In those cases
   the AS SHOULD either return the full chain or reject the
   introspection request.

   The RS handles chain_complete: false as follows:

   *  *Security-relevant use*: When local policy uses any inner act
      entry as an input to an authorization, scope determination, or
      other security decision, the RS MUST reject the request upon
      receiving chain_complete: false.  The RS cannot safely make that
      security decision on an incomplete chain, and a filtered chain is
      indistinguishable from a chain that was truncated or manipulated
      before reaching the introspection endpoint.

   *  *Audit-only use*: When local policy uses inner act entries solely
      for logging, audit, or informational purposes, and not as inputs
      to any security decision, the RS MAY accept a filtered chain and
      record the partial information, provided it notes the
      incompleteness.  The outermost act.sub and sub, which are
      unaffected by inner-chain filtering, remain available for
      authorization.

   In either case, the RS MUST NOT treat the partial chain as a faithful
   representation of the complete delegation history.  A companion
   profile that defines additional introspection parameters aligned to
   the visible delegation chain MUST define how those parameters behave
   when the visible act chain is filtered, consistent with Companion
   Profiles and Extension Points (Section 11).









McGuinness               Expires 1 November 2026               [Page 67]

Internet-Draft             OAuth Actor Profile                April 2026


   Opaque access tokens are not conformant token formats under this
   profile.  When an AS supports delegated opaque access tokens through
   introspection, it MUST return the equivalent actor-profile fields
   listed above for active delegated tokens.  This compatibility path
   does not make the opaque token itself conformant to this profile, and
   support for it MUST NOT be inferred solely from
   actor_profile_required metadata.

   An introspecting RS MUST apply the same delegated-token processing to
   the introspection response claims that it would apply to equivalent
   locally validated JWT claims, including actor authorization when
   required by local policy.  An RS that relies on introspection rather
   than local JWT validation MUST treat a missing act claim as an
   inconsistency whenever local policy, protected resource metadata, or
   other token context indicates that the token is delegated or that
   actor-profile conformance is required.  In such cases, the RS MUST
   reject the token.  Only when no such requirement or indication exists
   MAY the RS treat an active introspection response without act as
   representing a non-delegated token.

   Introspection endpoints for delegated tokens SHOULD be advertised via
   the introspection_endpoint parameter in AS metadata ([RFC8414]).
   When revocation is integrated, the introspection response for a
   revoked delegated token MUST return "active": false and MUST NOT
   include act or sub_profile claims.

   Resource servers that cache introspection responses for delegated
   tokens SHOULD use short cache lifetimes appropriate to the
   deployment's revocation requirements.  When an introspection response
   carries "chain_complete": false, an RS that uses inner act entries
   for security decisions SHOULD NOT cache the response, because a
   subsequent request relying on the cached partial chain cannot
   distinguish privacy filtering from chain truncation or manipulation.

9.  Error Responses

   When an AS or TTS rejects a request under this profile for reasons
   related to actor-profile processing, it MUST return an OAuth error
   response per [RFC6749], Section 5.2 and [RFC8693], Section 2.2.
   These error codes do not override invalid_client when a request fails
   client authentication per [RFC6749] or [RFC7523].

   The following table summarizes actor-profile error handling by using
   three existing OAuth error codes and defining one new error code,
   actor_unauthorized.  The "AS" and "TTS" columns note context-specific
   triggers where the two server types differ; otherwise the trigger
   condition applies to both.




McGuinness               Expires 1 November 2026               [Page 68]

Internet-Draft             OAuth Actor Profile                April 2026


   +==================+==============+===================+=============+
   |Error Code        |General       |AS-specific detail |TTS-specific |
   |                  |Trigger       |                   |detail       |
   +==================+==============+===================+=============+
   |invalid_request   |act claim     |DPoP-bound JWT     |Delegated    |
   |                  |structure     |assertion grant    |inbound      |
   |                  |syntactically |omits required top-|Transaction  |
   |                  |invalid;      |level cnf.jkt;     |Token omits  |
   |                  |delegation    |delegated          |required top-|
   |                  |chain depth   |Transaction Token  |level iss    |
   |                  |exceeds       |used as            |             |
   |                  |limit;        |subject_token omits|             |
   |                  |required      |required top-level |             |
   |                  |claim         |iss                |             |
   |                  |(act.sub or   |                   |             |
   |                  |act.iss)      |                   |             |
   |                  |absent        |                   |             |
   +------------------+--------------+-------------------+-------------+
   |invalid_grant     |Inbound token |Proof-of-possession|sub identity |
   |                  |or assertion  |check cannot be    |cannot be    |
   |                  |fails         |confirmed          |preserved per|
   |                  |signature or  |                   |step 1 of    |
   |                  |claims        |                   |Transaction  |
   |                  |validation;   |                   |Token Output |
   |                  |issuer not    |                   |Rules        |
   |                  |trusted to    |                   |(Section     |
   |                  |assert the    |                   |7.4); inbound|
   |                  |delegation    |                   |actor        |
   |                  |relationship  |                   |information  |
   |                  |              |                   |fails        |
   |                  |              |                   |validation   |
   |                  |              |                   |per step 4   |
   +------------------+--------------+-------------------+-------------+
   |invalid_scope     |Scope         |Requested scope is |Requested    |
   |                  |reduction     |not available after|transaction  |
   |                  |under         |ordinary Token     |scope is not |
   |                  |[RFC8693] or  |Exchange scope     |available    |
   |                  |local policy  |reduction          |under TTS    |
   |                  |leaves no     |                   |policy       |
   |                  |effective     |                   |             |
   |                  |scope for     |                   |             |
   |                  |reasons       |                   |             |
   |                  |unrelated to  |                   |             |
   |                  |actor         |                   |             |
   |                  |authorization |                   |             |
   +------------------+--------------+-------------------+-------------+
   |actor_unauthorized|Actor-policy  |Includes policy    |Includes the |
   |                  |failure: the  |failures for a     |newly        |



McGuinness               Expires 1 November 2026               [Page 69]

Internet-Draft             OAuth Actor Profile                April 2026


   |                  |(sub,         |newly introduced   |authenticated|
   |                  |act.sub) pair |actor or a         |presenter the|
   |                  |fails a       |preserved          |TTS would    |
   |                  |policy check, |delegation chain   |install as   |
   |                  |the actor's   |evaluated by the AS|the new      |
   |                  |sub_profile   |                   |outermost    |
   |                  |is not in the |                   |actor        |
   |                  |accepted set, |                   |             |
   |                  |the required  |                   |             |
   |                  |delegation    |                   |             |
   |                  |relationship  |                   |             |
   |                  |cannot be     |                   |             |
   |                  |confirmed     |                   |             |
   |                  |from current  |                   |             |
   |                  |inputs, or    |                   |             |
   |                  |local policy  |                   |             |
   |                  |prohibits the |                   |             |
   |                  |actor         |                   |             |
   |                  |relationship  |                   |             |
   +------------------+--------------+-------------------+-------------+

                                  Table 3

   The error_description field SHOULD be included and SHOULD describe
   which aspect of actor-profile processing failed, to the extent
   permitted by the server's security and privacy policy.  Some
   actor_unauthorized failures are recoverable by using a different
   actor credential, actor type, or delegation grant; others are
   definitive local-policy prohibitions.

   When actor_unauthorized is returned from a token endpoint (AS or
   TTS), the client SHOULD consult entity_profiles_supported.actor in AS
   metadata (Authorization Server Metadata (Section 10.1)) to determine
   whether the actor's sub_profile is accepted, then inspect
   error_description for missing-grant indications.  If neither resolves
   the failure, deployment documentation governs whether any remediation
   path exists.  When returned from a resource server, the token has
   already been issued; the client SHOULD obtain a new token via a
   different actor credential or grant path.

   Example:

   {
     "error": "actor_unauthorized",
     "error_description": "act.sub_profile not accepted for payments:create"
   }





McGuinness               Expires 1 November 2026               [Page 70]

Internet-Draft             OAuth Actor Profile                April 2026


10.  Metadata and Discovery

   This section defines a minimal set of metadata parameters that,
   together with the entity_profiles_supported.actor array defined in
   [I-D.mora-oauth-entity-profiles] and the
   authorization_grant_profiles_supported parameter defined by
   [I-D.ietf-oauth-identity-assertion-authz-grant], allow authorization
   servers and resource servers to advertise actor-profile support with
   reduced out-of-band coordination.  Authorization grant profile
   support uses authorization_grant_profiles_supported; Token Exchange
   role-specific capabilities are grouped under
   actor_profile_token_exchange; entity type enumeration uses
   [I-D.mora-oauth-entity-profiles] metadata.

   These parameters are coarse-grained capability indicators only; they
   do not provide a complete description of every supported grant path
   or guarantee successful token issuance.  Deployment documentation,
   prior agreement, or companion profiles can still be needed for
   details outside the parameters defined here.  Companion profiles MAY
   define additional metadata, consistent with Companion Profiles and
   Extension Points (Section 11).

10.1.  Authorization Server Metadata

   The following parameters are defined for use in the AS metadata
   document ([RFC8414]):

   authorization_grant_profiles_supported:  OPTIONAL.  A JSON array of
      authorization grant profile identifiers, as defined by
      [I-D.ietf-oauth-identity-assertion-authz-grant].  An AS that
      supports processing JWT authorization grants carrying actor-
      profile claims under this document SHOULD include
      urn:ietf:params:oauth:grant-profile:actor-profile in this array.
      This value covers all JWT authorization-grant paths defined by
      this document (JWT Assertion Grants (Section 4)), not a single
      specific grant type variant; it signals that the AS implements the
      actor-profile JWT authorization-grant processing rules as a whole.
      It does not indicate that any particular issuer, subject, actor,
      client, audience, resource, scope, or authorization request will
      be accepted.  An AS that includes urn:ietf:params:oauth:grant-
      profile:actor-profile in authorization_grant_profiles_supported
      MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer in
      grant_types_supported.

   actor_profile_token_exchange:  OPTIONAL.  A JSON object advertising
      coarse Token Exchange capabilities for requests in which actor-
      profile processing can apply.  When absent, the AS makes no claim
      about Token Exchange support for this actor profile.  This



McGuinness               Expires 1 November 2026               [Page 71]

Internet-Draft             OAuth Actor Profile                April 2026


      parameter applies only to Token Exchange; it does not describe
      authorization code grants or JWT bearer authorization grants.  The
      object members defined by this document are:

      *  subject_token_types_supported: OPTIONAL.  A JSON array of
         token-type URI strings indicating the subject_token_type values
         the AS accepts for Token Exchange requests in which actor-
         profile processing can apply.  Values defined by this document
         are:

         -  urn:ietf:params:oauth:token-type:jwt: JWT assertion grants
            (JWT Assertion Grants (Section 4))

         -  urn:ietf:params:oauth:token-type:access_token: JWT access
            tokens (JWT Access Tokens (Section 5))

         -  urn:ietf:params:oauth:token-type:id_token: OpenID Connect ID
            tokens (OpenID Connect ID Token (Section 6.2.2.1))

         -  urn:ietf:params:oauth:token-type:refresh_token: refresh
            tokens (Refresh Token (Section 6.2.2.2))

         -  urn:ietf:params:oauth:token-type:txn_token: Transaction
            Tokens (Transaction Tokens (Section 7.1))

      *  actor_token_types_supported: OPTIONAL.  A JSON array of token-
         type URI strings indicating the actor_token_type values the AS
         accepts for Token Exchange requests in which actor-profile
         processing can apply.  Values defined by this document are:

         -  urn:ietf:params:oauth:token-type:jwt: JWT client assertions
            (JWT Client Assertion (Section 6.3.1)) and workload identity
            credentials (Workload Credential Processing
            (Section 6.3.2.2))

         -  urn:ietf:params:oauth:token-type:access_token: JWT access
            tokens (JWT Access Token as actor_token (Section 6.3.3))

      *  requested_token_types_supported: OPTIONAL.  A JSON array of
         token-type URI strings indicating the requested_token_type
         values the AS accepts for Token Exchange requests in which
         actor-profile processing can apply.  Values defined by this
         document are:

         -  urn:ietf:params:oauth:token-type:access_token: JWT access
            tokens (JWT Access Tokens (Section 5))





McGuinness               Expires 1 November 2026               [Page 72]

Internet-Draft             OAuth Actor Profile                April 2026


         -  urn:ietf:params:oauth:token-type:jwt: JWT assertion grants
            (JWT Assertion Grants (Section 4))

         -  urn:ietf:params:oauth:token-type:txn_token: Transaction
            Tokens (Transaction Tokens (Section 7.1))

      Each member of actor_profile_token_exchange is a coarse capability
      signal only.  The presence of a token type in one member does not
      guarantee that it can be combined with every token type in another
      member, every resource, every scope, every presenter-binding
      mechanism, or every profile-specific JWT variant.  For example,
      this document uses urn:ietf:params:oauth:token-type:jwt for both
      RFC 7523 client assertions and workload identity credentials as
      actor_token inputs, with profile disambiguation performed during
      request processing (Token Exchange Processing (Section 6)).

   The entity profile types the AS accepts for actors are advertised via
   the entity_profiles_supported.actor array defined in
   [I-D.mora-oauth-entity-profiles], not via a separate metadata
   parameter.  DPoP support is advertised via
   dpop_signing_alg_values_supported per [RFC9449].

   Example AS metadata fragment:




























McGuinness               Expires 1 November 2026               [Page 73]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "issuer": "https://as.enterprise.example",
     "token_endpoint": "https://as.enterprise.example/token",
     "grant_types_supported": [
       "urn:ietf:params:oauth:grant-type:token-exchange",
       "urn:ietf:params:oauth:grant-type:jwt-bearer"
     ],
     "dpop_signing_alg_values_supported": ["ES256", "RS256"],
     "authorization_grant_profiles_supported": [
       "urn:ietf:params:oauth:grant-profile:actor-profile"
     ],
     "actor_profile_token_exchange": {
       "subject_token_types_supported": [
         "urn:ietf:params:oauth:token-type:id_token",
         "urn:ietf:params:oauth:token-type:jwt",
         "urn:ietf:params:oauth:token-type:access_token",
         "urn:ietf:params:oauth:token-type:txn_token"
       ],
       "actor_token_types_supported": [
         "urn:ietf:params:oauth:token-type:jwt",
         "urn:ietf:params:oauth:token-type:access_token"
       ],
       "requested_token_types_supported": [
         "urn:ietf:params:oauth:token-type:access_token",
         "urn:ietf:params:oauth:token-type:jwt",
         "urn:ietf:params:oauth:token-type:txn_token"
       ]
     },
     "entity_profiles_supported": {
       "client": ["service", "ai_agent"],
       "subject": ["user", "service", "ai_agent"],
       "actor":   ["user", "service", "ai_agent"]
     }
   }

10.2.  Protected Resource Metadata

   One new parameter is defined for use in Protected Resource Metadata
   ([RFC9728]):

   actor_profile_required:  OPTIONAL.  A boolean.  When true, the RS
      indicates that requests intending to exercise delegated authority
      for this resource are expected to provide actor-profile
      information conforming to this document's semantics.  For JWT
      access tokens and Transaction Tokens, this ordinarily means a
      delegated token carrying an act claim conforming to this profile.
      In deployments that use opaque access tokens, equivalent actor-
      profile information MAY instead be conveyed to the RS via the



McGuinness               Expires 1 November 2026               [Page 74]

Internet-Draft             OAuth Actor Profile                April 2026


      introspection compatibility path in Token Introspection
      (Section 8.4), but the opaque token itself is not conformant to
      this profile.  When false or absent, actor-profile conformance is
      not advertised by metadata.

      Clients SHOULD treat actor_profile_required: true as a strong
      indication that delegated access will require either a conforming
      act claim in the token or an explicitly documented opaque-token/
      introspection path providing equivalent claims.

      When an AS has obtained and processed Protected Resource Metadata
      for the target RS and that metadata includes
      actor_profile_required: true, the AS MUST reject any token request
      that would produce a token non-conformant with this profile for
      use at that resource unless an explicitly supported introspection
      compatibility path will provide equivalent actor-profile
      information to the RS.  An RS that enforces this policy for a
      given request path MUST reject a request it determines is
      attempting delegated access if neither a conforming act claim nor
      equivalent introspection-derived actor-profile information is
      available to the RS.  This parameter does not require otherwise
      acceptable non-delegated requests for the same resource to carry
      act, and it does not by itself describe the RS's full actor
      authorization logic.

      This parameter is resource-scoped, not path-scoped; [RFC9728] does
      not define sub-resource granularity for Protected Resource
      Metadata.  An RS that requires actor-profile conformance only on
      specific request paths (e.g., /payments but not /profile) MUST
      apply enforcement at the request layer.  Such an RS MAY set this
      parameter to true as a conservative resource-wide signal, but
      clients and deployment documentation SHOULD recognize that path-
      specific enforcement can be stricter than resource metadata alone
      expresses.

   Clients discover which actor entity profile values the RS's AS will
   accept by consulting entity_profiles_supported.actor in the AS
   metadata for one of the authorization servers listed in the
   resource's authorization_servers array ([RFC9728]).  When
   authorization_servers lists multiple entries, the client SHOULD
   select the AS that issued or will issue the token being presented.

   Example Protected Resource Metadata fragment:








McGuinness               Expires 1 November 2026               [Page 75]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "resource": "https://api.travel-provider.example",
     "authorization_servers": [
       "https://as.travel-provider.example"
     ],
     "actor_profile_required": true
   }

10.3.  Transaction Token Capability Signaling

   Transaction Token support under this profile for Token Exchange paths
   is advertised through
   actor_profile_token_exchange.requested_token_types_supported.  When
   an AS or TTS can issue Transaction Tokens as delegated Token Exchange
   outputs under this profile, it MUST list urn:ietf:params:oauth:token-
   type:txn_token in
   actor_profile_token_exchange.requested_token_types_supported.  This
   document does not define any separate Transaction Token discovery
   parameter.

10.4.  Capability Signaling Usage

   Clients use Protected Resource Metadata ([RFC9728]) to determine
   whether a resource advertises actor-profile conformance
   (actor_profile_required), and the associated AS metadata ([RFC8414])
   to assess JWT authorization-grant support
   (authorization_grant_profiles_supported), Token Exchange
   compatibility (actor_profile_token_exchange), and accepted actor
   entity profiles (entity_profiles_supported.actor).  When this profile
   is combined with Identity Chaining
   ([I-D.ietf-oauth-identity-chaining]), clients SHOULD additionally
   consult identity_chaining_requested_token_types_supported; the two
   parameter sets are independent.

   The metadata in this document does not advertise authorization-code
   actor-selection mechanisms or per-scope/per-path actor type
   restrictions.  Deployments that need either capability rely on
   deployment documentation, bilateral agreement, or a companion
   profile.  When a delegated request carries act.sub_profile, its value
   SHOULD be drawn from entity_profiles_supported.actor when that
   metadata is available.










McGuinness               Expires 1 November 2026               [Page 76]

Internet-Draft             OAuth Actor Profile                April 2026


   Example client preflight failure: if the RS metadata advertises
   "actor_profile_required": true but the target AS metadata advertises
   "entity_profiles_supported": { "actor": ["service"] } and the
   client's acting entity profile is ai_agent, the client would
   ordinarily stop before making the token request because the AS does
   not advertise support for the actor type the client would need to
   represent.

11.  Companion Profiles and Extension Points

   This document defines current-token delegated identity while leaving
   room for companion profiles to define supplementary behavior such as
   provenance, transparency, or deployment-specific audit material.

   A companion profile layered on top of this one:

   *  MAY define additional top-level JWT claims, OAuth metadata
      parameters, or introspection response parameters that apply only
      when a token already conforms to this profile;

   *  MUST preserve the meanings of the token's top-level sub, the
      outermost act.sub, the (act.iss, act.sub) actor identifier pair,
      the nested act chain ordering, and the top-level cnf claim for the
      current presenter;

   *  MUST NOT reinterpret act.iss, nested act objects, or the top-level
      cnf claim as independently trusted prior-hop provenance artifacts;

   *  SHOULD define any supplementary provenance, receipt, or chain-wide
      state in separate top-level claims or equivalent companion
      mechanisms rather than by overloading members inside inherited act
      objects;

   *  if it defines data that aligns to the visible act chain, MUST
      specify the alignment rules, the behavior when coverage is
      partial, and the behavior when introspection or privacy filtering
      suppresses part of the visible chain.

   An implementation that conforms only to this core profile MUST ignore
   unrecognized companion-profile claims, metadata parameters, and
   introspection response parameters unless another specification or
   local policy defines their meaning.  A deployment that requires
   support for a companion profile MUST express that requirement through
   the companion profile's own metadata, through out-of-band agreement,
   or through another explicit local-policy mechanism.






McGuinness               Expires 1 November 2026               [Page 77]

Internet-Draft             OAuth Actor Profile                April 2026


12.  Deployment Considerations

   This section provides deployment and migration guidance for adopting
   the OAuth Actor Profile in systems that currently rely on implicit
   delegation or older act semantics.

12.1.  Migration and Adoption

12.1.1.  RFC 8693 Backwards Compatibility

   This profile defines a conformant act object structure that requires
   iss in addition to the sub required by [RFC8693], and adds
   sub_profile for entity-type classification.  This is a profile
   requirement: [RFC8693] act objects that include only sub remain valid
   under that specification, but they do not conform to this profile.
   Deployments that receive an act object that conforms only to
   [RFC8693] but omits this profile's required members MUST treat that
   actor object as not conforming to this profile.

   When a token or assertion is required by local policy or advertised
   metadata to conform to this profile, such non-conforming act objects
   MUST be rejected.  When profile conformance is not required,
   implementations MAY continue to process a base [RFC8693] act object
   according to local policy, but they MUST NOT infer profile-defined
   semantics for claims that are absent.

   The migration path for deployments currently using RFC 8693 act
   objects is:

   1.  ASes that issue tokens carrying act claims MUST begin emitting
       act.iss in all newly issued tokens once support for this profile
       is enabled.  Existing consumers that do not recognize act.iss
       will ignore it.

   2.  Update consumers to validate act.iss per Actor Object Structure
       (Section 3.4) once issuers have deployed step 1.

   3.  Once all token issuers and consumers on a given path have been
       updated, resource servers can enforce profile conformance by
       setting actor_profile_required: true in their Protected Resource
       Metadata.  ASes that wish to accept only profile-conformant
       inbound assertions can do so via local policy once issuers on
       inbound paths have deployed step 1.

   Steps 2 and 3 are RECOMMENDED; step 1 is REQUIRED for any AS that
   issues actor-profile tokens.  This graduated approach avoids a flag-
   day cutover and allows incremental rollout across trust domains.




McGuinness               Expires 1 November 2026               [Page 78]

Internet-Draft             OAuth Actor Profile                April 2026


   When an AS receives an inbound token or assertion whose act object
   omits act.iss (that is, the object conforms only to [RFC8693] and not
   to this profile):

   *  If local policy or advertised metadata requires actor-profile
      conformance for the request path, the AS MUST reject the request.
      It MUST return invalid_request consistent with Error Responses
      (Section 9).

   *  If actor-profile conformance is not required, the AS MAY process
      the inbound act object under local policy for non-profile
      behavior, subject to the following constraints:

      -  The AS MUST NOT rewrite an inherited actor entry to add
         act.iss; inherited entries are immutable.

      -  The AS MUST reject any request that would carry the non-
         conforming chain into a profile-conforming output token.

      -  When the AS issues a non-profile-conforming output token under
         local policy, it MUST NOT silently drop the inbound act claim.

   Implementations that previously treated confirmation members inside
   act as active sender-constraining mechanisms should note that this
   document defines proof-of-possession only through the top-level cnf
   claim and the immediate presenter.  Deployments that relied on per-
   hop actor-key verification for multi-hop security properties will
   need a separate provenance mechanism or profile rather than the core
   actor profile defined here.

12.1.2.  Migrating from Implicit to Explicit Delegation

   Migration from implicit delegation is the process of making actor
   identity explicit in tokens where the acting party was previously
   inferred from client_id, azp, or token-request context.  The
   normative client-identity rules are defined in Client Identity and
   Delegation (Section 14.7).

   Deployments that currently rely on implicit delegation can migrate
   incrementally.  A common transition pattern is to emit both legacy
   client-oriented identifiers and explicit actor claims during rollout,
   measure and reconcile mismatches, and then require act where explicit
   delegation is needed.

   A deployment that chooses explicit delegation only can reject non-act
   delegated requests entirely and omit legacy client-identity
   reconciliation.




McGuinness               Expires 1 November 2026               [Page 79]

Internet-Draft             OAuth Actor Profile                April 2026


   One safe migration pattern is:

   *  Clients that can obtain explicit-delegation tokens under this
      profile SHOULD prefer those tokens over relying on legacy implicit
      client-identity interpretation.

   *  If act is absent, deployments MAY continue to apply legacy
      implicit client-based policy according to local policy, and
      existing client-based authorization logic MAY remain in place
      during migration.

   *  If both explicit and implicit signals are present, apply the
      reconciliation rules in Client Identity and Delegation
      (Section 14.7) and record mismatches during rollout.

   *  An RS that enforces explicit delegation under this profile for a
      given request path MUST NOT treat the successful presentation of a
      non-act token as an acceptable substitute for a delegated token
      merely because legacy client-based policy would otherwise allow
      the request.

   During transition, issuers SHOULD emit both legacy client-oriented
   identifiers and explicit actor claims whenever doing so is feasible
   for the deployment.

   The legacy form carries only client_id (and optionally azp) to
   identify the acting party.  The explicit form adds an act block:

   {
     "iss": "https://as.example.com",
     "sub": "https://idp.example.com/users/alice",
     "client_id": "travel-assistant-client-id",
     "azp": "travel-assistant-client-id",
     "act": {
       "sub": "https://agents.example.com/travel-assistant",
       "iss": "https://as.example.com",
       "sub_profile": "ai_agent"
     },
     "scope": "booking:create"
   }

   In this example, client_id and azp remain as auxiliary client-
   identity inputs while act.sub carries the explicit actor identity.
   See Client Identity and Delegation (Section 14.7) for the normative
   treatment of these claims when both are present.

   Mismatch example, where the client and actor identify different
   parties:



McGuinness               Expires 1 November 2026               [Page 80]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.example.com",
     "sub": "https://idp.example.com/users/alice",
     "client_id": "travel-assistant-client-id",
     "act": {
       "sub": "https://agents.other-provider.example/concierge-bot",
       "iss": "https://as.other-provider.example",
       "sub_profile": "ai_agent"
     },
     "scope": "booking:create"
   }

   This example illustrates the mismatch case covered by Client Identity
   and Delegation (Section 14.7): the OAuth client identifier and the
   explicit actor identifier name different parties unless trusted local
   mapping rules bind them.

12.2.  Trusting Actor Identifier Pairs

   This section gives non-normative examples for the trust decision
   required by Validate Outermost Actor (Section 3.6.2.2).  Actor
   resolution under this profile starts from the (act.iss, act.sub)
   pair; the token's top-level iss identifies the token issuer and is
   the actor identifier context only when the two happen to be the same
   entity.  As described in Representation and Policy (Section 3.3.1),
   this profile does not define a universal trust framework or proof
   algorithm for establishing that act.iss is authoritative for act.sub.

   Examples of local validation approaches include:

   *  federation metadata or trust-framework configuration that
      authorizes the token issuer to assert actor identifiers in the
      act.iss context (for example, [OpenID.Federation]);

   *  pre-registration entries that explicitly authorize the token
      issuer to assert a specific (act.iss, act.sub) pair or identifiers
      of that form; and

   *  bilateral or deployment-local policy rules that authorize the
      token issuer to carry the specific class of actor identifier used
      in act.sub.

   For HTTPS URI identifiers, one possible local rule is URL namespace
   containment.  Under that style of rule, deployments might accept a
   token issuer's assertion of an actor identifier pair when the scheme,
   host, and port of act.iss and act.sub match, or when act.sub falls
   within a path prefix of act.iss that has been explicitly configured
   for that issuer.  In those deployments, scheme and host comparison



McGuinness               Expires 1 November 2026               [Page 81]

Internet-Draft             OAuth Actor Profile                April 2026


   typically follows the case-insensitive rules in [RFC3986],
   Section 3.2.2, while path-prefix matching is usually case-sensitive
   and boundary-aware.  Subdomain relationships alone are often
   insufficient to establish trust without explicit configuration.

   Examples:

   *  A token issued by https://as.enterprise.example with act.iss =
      https://as.enterprise.example and act.sub =
      https://as.enterprise.example/agents/travel-assistant would
      commonly satisfy a same-host local trust rule.

   *  A token issued by https://as.enterprise.example with act.iss =
      https://as.enterprise.example and act.sub =
      https://idp.enterprise.example/users/alice would not ordinarily
      satisfy URL containment alone, because the host differs.

   *  For non-HTTPS identifier schemes such as workload-identity URNs,
      deployments typically rely on registry, federation, or other
      explicit local trust configuration rather than URL-based rules.

12.3.  Token Lifetime for Delegation Chains

   Delegated tokens carry the combined exposure surface of all
   principals in the delegation chain.  A single issued token may
   authorize actions by an actor whose delegation grant has since been
   revoked; the token remains valid until its exp time.  Because
   revocation cannot retroactively invalidate already-issued tokens,
   lifetime is the primary control.

   Deployments SHOULD use shorter token lifetimes for delegated tokens
   than for non-delegated tokens of equivalent scope.  In cross-domain
   flows, the upstream delegation artifact (e.g., an ID-JAG or delegated
   access token) limits how long the downstream actor can continue to
   request tokens without re-authenticating the delegation chain.
   Transaction Tokens are already expected to be short-lived; JWT access
   tokens and JWT assertion grants in multi-hop chains SHOULD be issued
   with lifetimes no longer than necessary to complete the task they
   authorize.

   Deployments with deep chains (three or more nested act objects)
   SHOULD account for the fact that any revocation event at any hop in
   the chain cannot propagate to already-issued downstream tokens.  In
   environments with significant revocation risk (for example, AI agent
   delegation chains where user consent can be withdrawn at any time),
   deployments SHOULD combine short-lived tokens with active
   introspection at sensitive resource servers rather than relying
   solely on exp.



McGuinness               Expires 1 November 2026               [Page 82]

Internet-Draft             OAuth Actor Profile                April 2026


   General guidance on access token lifetime and security tradeoffs is
   provided in [RFC9700].

13.  Conformance

   This section enumerates per-role requirements for claiming
   conformance to this profile.  Profile scope (representation versus
   policy, supported token formats, and supported request semantics) is
   defined in Profile Scope (Section 3.3).  An implementation claiming
   conformance MUST satisfy the requirements listed for each role it
   performs.

13.1.  Issuing Authorization Server

   An issuing AS that claims conformance to this profile MUST:

   *  emit act.iss in every newly issued token carrying act (Actor
      Object Structure (Section 3.4));

   *  apply the chain validation and construction algorithm in
      Delegation Chain Validation and Construction (Section 3.6);

   *  define and enforce a local maximum delegation depth (Delegation
      Chains (Section 3.5));

   *  preserve sub across token issuance, translating only under a
      trusted local mapping (JWT Access Token Output (Section 6.5.2));

   *  apply the presenter-transition model in Presenter Transition Model
      (Section 6.1) when performing Token Exchange;

   *  reject any actor_token carrying act (Actor Tokens (Section 6.3));

   *  return the error codes specified in Error Responses (Section 9)
      for the listed failure conditions;

   *  preserve act and top-level sub_profile in introspection responses
      for active delegated tokens, when introspection is supported
      (Token Introspection (Section 8.4)).

13.2.  Transaction Token Service

   A TTS that claims conformance to this profile MUST:

   *  satisfy the issuing-AS requirements above for Transaction Token
      output;





McGuinness               Expires 1 November 2026               [Page 83]

Internet-Draft             OAuth Actor Profile                April 2026


   *  set top-level iss on every Transaction Token carrying act
      (Transaction Tokens (Section 7.1));

   *  apply the TTS presenter-authentication and output rules in
      Transaction Token Output Rules (Section 7.4);

   *  treat req_wl as supporting workload context, not as a substitute
      for the outermost act.sub (Actor Claim in Transaction Tokens
      (Section 7.1.1)).

13.3.  Resource Server

   An RS that claims conformance to this profile MUST:

   *  validate act only when the outer token issuer is trusted to convey
      it (Delegation Chain Integrity and Trust (Section 14.1));

   *  treat client_id and azp as client-identity inputs only, not as
      actor identifiers, when act is present (Client Identity and
      Delegation (Section 14.7));

   *  evaluate proof of possession against the top-level cnf only
      (Sender Constraint and Proof-of-Possession Validation
      (Section 3.7));

   *  use the WWW-Authenticate challenge scheme appropriate to the
      token's binding mechanism (JWT Access Token Processing
      (Section 8.2)).

   An RS that enforces actor authorization additionally MUST evaluate
   the (sub, outermost act.sub) pair per Actor Authorization
   (Section 8.1).

13.4.  Client

   A client that claims conformance to this profile SHOULD treat
   actor_profile_required: true as an indication that delegated access
   for the resource requires act-carrying tokens (Protected Resource
   Metadata (Section 10.2)), and adjust its grant selection or token
   request accordingly.











McGuinness               Expires 1 November 2026               [Page 84]

Internet-Draft             OAuth Actor Profile                April 2026


14.  Security Considerations

   As described in Representation and Policy (Section 3.3.1), this
   document does not define a trust framework for proving that an actor
   identifier context is authoritative for an actor identifier, proving
   delegation approval, or validating subject-identifier translation.
   Security for those decisions depends on deployment-specific policy
   and external agreements.

14.1.  Delegation Chain Integrity and Trust

   An attacker who can inject or forge act claims can impersonate an
   arbitrary actor and exercise a subject's permissions without
   authorization.  The primary mitigation is to accept act claims only
   in tokens whose issuer is trusted to assert the delegated actor
   relationship.  RS implementations MUST validate the token signature
   before extracting actor claims, and MUST verify that the token issuer
   is trusted to convey the claims it carries.

   Because inner act objects are set by upstream ASes and not re-signed
   at each hop, the integrity of the entire delegation chain rests on
   the outermost token's signature.  Implementations SHOULD use short
   token lifetimes and MUST reject tokens whose exp has passed,
   regardless of chain depth.

   Inner act objects are prior-actor context under Carry Prior-Actor
   Context (Section 3.6.2.4).  Security policies that rely on inner
   actor identities for access control are deployment-specific and
   generally lower-assurance than policies based on sub and the
   outermost act.sub.

   When a token crosses organizational boundaries, the receiving AS or
   RS MUST apply appropriate trust evaluation.  ASes performing Token
   Exchange MUST evaluate cross-domain delegation grants explicitly and
   SHOULD NOT grant cross-domain actors the same rights as same-domain
   actors absent an explicit trust decision that makes them equivalent.

14.2.  Self-Issued Authorization Grants

   This section addresses self-issued JWT _authorization grants_ (JWT
   Assertion Grants (Section 4)); it does not apply to RFC 7523 client
   assertions used as actor_token (JWT Client Assertion
   (Section 6.3.1)), where iss = sub = client_id is the conformant
   pattern defined by [RFC7523].

   In a self-issued assertion grant, the acting entity is itself the JWT
   iss and directly asserts delegation to itself without any upstream AS
   having authenticated the actor or pre-validated the delegation



McGuinness               Expires 1 November 2026               [Page 85]

Internet-Draft             OAuth Actor Profile                April 2026


   relationship.  Self-issued authorization grants are outside the
   interoperable scope of this document and MUST be rejected by default
   (JWT Assertion Grant Structure (Section 4.1)).  This section
   specifies the security controls that a deployment MUST independently
   establish when another specification or local policy explicitly
   enables self-issued authorization grant acceptance.

   Because no upstream AS vouches for the actor's identity or the
   delegation relationship, the receiving AS MUST NOT treat the self-
   asserted delegation claim alone as a sufficient authorization basis.
   When a deployment enables self-issued authorization grants, the
   receiving AS MUST at minimum:

   *  Validate the JWT signature using the key identified in the JWT
      header, obtained from a pre-registered or otherwise independently
      trusted source for the self-issuing party.

   *  Verify the exp, iat, and nbf claims per [RFC7519].

   *  Reject assertions whose jti has already been accepted within the
      assertion's validity window to prevent replay.

   *  Verify proof of possession per the token-endpoint mechanism in use
      (DPoP per [RFC9449] or mTLS per [RFC8705]).

   *  Apply the actor-profile validation and proof-of-possession
      requirements in Authorization Grant Processing (Section 4.2).

   *  Establish the delegation relationship from an independent
      authorization basis such as a pre-registered grant, explicit
      consent record, or equivalent deployment-specific artifact.

   In the absence of these controls, an attacker can self-assert an
   arbitrary (sub, act.sub) pair and bypass actor-profile authorization
   enforcement.  Deployments MUST confine self-issued authorization
   grants to within a single trust domain and MUST NOT propagate them
   across organizational boundaries.  This document defines no discovery
   or negotiation mechanism for self-issued authorization grant
   acceptance; any such mechanism is the responsibility of the enabling
   specification or local policy.











McGuinness               Expires 1 November 2026               [Page 86]

Internet-Draft             OAuth Actor Profile                April 2026


14.3.  Assertion Replay Prevention

   JWT assertion grants carrying act are higher-value replay targets
   than plain JWT assertions because a successful replay can establish
   an unauthorized delegation chain.  [RFC7523] recommends jti replay
   prevention as a SHOULD; this profile strengthens that requirement for
   non-sender-constrained grants as described in Authorization Grant
   Processing (Section 4.2).  Deployments that do not apply sender
   constraint MUST maintain a jti replay cache for the duration of each
   assertion's validity window.  Short assertion lifetimes (on the order
   of minutes) bound the required cache retention period.  Deployments
   using DPoP or mTLS sender constraint benefit from proof-of-possession
   as primary replay resistance; jti replay prevention remains
   RECOMMENDED as defense-in-depth for those paths.

14.4.  Token Substitution

   An attacker who can present a token with a crafted sub_profile or
   delegation chain could attempt to escalate privileges.  ASes MUST
   validate inbound sub_profile values against the syntax requirements
   of this document, the applicable registry or deployment-specific
   allowed set where such checks are part of local policy, and the local
   policy applicable to the token they are issuing.  They MUST preserve
   unrecognized but syntactically valid values as required by Actor
   Object Structure (Section 3.4), and they MUST reject values that are
   malformed or disallowed by local policy.

14.5.  Confused Deputy

   A resource server that evaluates only the subject principal when an
   act claim is present is susceptible to a confused deputy attack: a
   malicious actor exploits a subject's pre-existing permissions without
   the subject's ongoing consent simply by presenting a token that names
   the subject in sub.  The mitigation is authorization of the (sub,
   outermost act.sub) pair before granting access.  Resource servers
   SHOULD implement such evaluation for delegated tokens under this
   document.

14.6.  Actor-Authorization Bypass

   A resource server that accepts delegated tokens but fails to enforce
   the (sub, outermost act.sub) relationship required by its local
   policy allows an attacker to bypass that policy by exploiting gaps in
   enforcement logic.  Resource servers that require actor authorization
   SHOULD apply that evaluation on every request path where delegated
   access is accepted, including introspection-based validation paths
   when used.  Deployments that signal delegated-token requirements with
   actor_profile_required: true SHOULD ensure that the documented



McGuinness               Expires 1 November 2026               [Page 87]

Internet-Draft             OAuth Actor Profile                April 2026


   request paths requiring delegated access are aligned with their
   actual enforcement behavior so that clients do not over-read the
   signal.

14.7.  Client Identity and Delegation

   Client identity, such as client_id, azp, or authenticated client
   context, is widely used in deployed systems as an authorization
   input.  Under this document, those values remain auxiliary client-
   identity signals, while the outermost act.sub is the explicit
   delegated-actor signal when present.  The following normative rules
   apply:

   *  When act is present, interoperable processing SHOULD use it as the
      explicit delegated-actor signal rather than substituting
      client_id, azp, or other client-identity signals.  Deployments
      that rely on such substitution are outside the interoperable scope
      of this profile.

   *  When a single client_id registration fronts multiple distinct
      acting entities (for example, an agent orchestration platform
      executing requests on behalf of different agent instances),
      client_id alone does not identify the runtime actor.  Each such
      request SHOULD carry act.sub identifying the specific acting
      principal.

   *  During token issuance, client_id and azp MUST NOT be rewritten to
      represent delegation state that belongs in act; see JWT Access
      Token Output (Section 6.5.2) for propagation rules.

   *  When both explicit (act.sub) and implicit (client_id, azp) signals
      are present and local policy expects them to identify the same
      party, implementations SHOULD apply trusted local mapping rules
      and either reconcile the identifiers or treat them as distinct
      according to local policy.

   *  When a protected resource or authorization path enforces explicit
      delegation under this profile, implementations MUST NOT downgrade
      to non-act processing solely because another token-acquisition
      path or legacy policy input remains available.

   The detailed migration rules and transition patterns are defined in
   Migrating from Implicit to Explicit Delegation (Section 12.1.2).








McGuinness               Expires 1 November 2026               [Page 88]

Internet-Draft             OAuth Actor Profile                April 2026


14.8.  sub_profile Trust

   The sub_profile claim is asserted by the token issuer and is only as
   trustworthy as that issuer.  Resource servers MUST NOT trust
   sub_profile values in tokens issued by untrusted parties.  Resource
   server operators SHOULD configure a list of accepted entity-type
   profiles per trust domain.

14.9.  Subject Namespace Translation

   Federated deployments sometimes need to re-express sub when a token
   crosses a trust-domain boundary and the issuer uses a different
   subject-identifier namespace.  This document therefore permits an AS
   or TTS to translate sub only to re-express the same underlying
   subject in a different namespace, as described in JWT Access Token
   Output (Section 6.5.2) and Transaction Token Output Rules
   (Section 7.4).

   This document does not define an interoperable mechanism for proving,
   conveying, or independently verifying subject equivalence across
   namespaces.  A translated sub is therefore authoritative only within
   the trust context of the issuer that performed the translation.  It
   does not, by itself, create portable proof that the original and
   translated identifiers are equivalent, and it does not define a
   general cross-token correlation mechanism across trust domains.

   Subject-namespace translation is a high-assurance operation.  An
   issuer MUST NOT translate sub unless local policy establishes that
   the original and translated identifiers refer to the same underlying
   subject.  Trust to perform that mapping is separate from trust to
   sign tokens and SHOULD be established explicitly.

   A receiving AS or RS that relies only on the issued token MAY
   evaluate the translated sub as the subject in the issuer's namespace.
   A receiving AS or RS that needs proof that the translated subject is
   equivalent to an upstream subject MUST obtain additional evidence
   outside this profile, such as another specification, an identity-
   chain mechanism, or an explicit trust agreement.  If such proof is
   required and cannot be established, the AS or RS SHOULD reject the
   token rather than treat the translated sub as advisory.

   Deployments that need portable proof of subject equivalence across
   namespaces, or independently verifiable subject-mapping evidence,
   require another specification or companion profile; such a mechanism
   is outside the scope of this document.






McGuinness               Expires 1 November 2026               [Page 89]

Internet-Draft             OAuth Actor Profile                April 2026


14.10.  Presenter Binding

   Without top-level presenter proof of possession, a leaked token can
   be replayed by any party.

   *  The RS SHOULD require the presenter-proof mechanism appropriate to
      the token type and deployment for the top-level cnf.jkt or other
      top-level confirmation information.  For example, JWT access
      tokens commonly use DPoP or mTLS, while Transaction Tokens can use
      the workload proof mechanism defined by their deployment profile.

   *  Deployments that use sender-constrained tokens for delegated
      access SHOULD apply that protection to the current presenter to
      reduce delegation-token theft risk.

   This document does not define per-hop actor-key provenance within the
   delegation chain.  Deployments that need stronger assurance for
   prior-hop provenance MUST use an additional mechanism outside the
   scope of this document, such as signed hop receipts, transparency-
   log-based recording, or another future extension; they MUST NOT
   overload act.iss or redefine nested act semantics to carry that
   provenance.  Companion profiles that supply such mechanisms MUST
   follow Companion Profiles and Extension Points (Section 11).

14.11.  Delegation Depth Limits

   Unbounded delegation chains increase attack surface and complicate
   policy evaluation.  Depth support and interoperability requirements
   are defined in Delegation Chains (Section 3.5).  Implementations that
   encounter chains exceeding their configured local maximum MUST reject
   the token to prevent denial-of-service through chain parsing.

14.12.  Actor Identity Rotation

   The canonical actor identifier under this profile is the (act.iss,
   act.sub) pair.  Deployments SHOULD choose act.sub to be a durable,
   stable identifier independent of ephemeral key material.  In
   particular, deployments SHOULD NOT use a JWK thumbprint or other key-
   derived value as act.sub; doing so silently changes the actor
   identity on every key rotation, which can break delegation grants and
   policy bindings that reference the prior identifier.  Key rotation
   (replacing the DPoP key or mTLS certificate bound to an actor) does
   not require changing act.sub when the identifier is key-independent.

   When act.sub itself must change (for example, because an agent
   instance is replaced, a workload is renamed, or an actor identifier
   namespace migrates), existing delegation grants and issued tokens
   continue to reference the old identifier.  Deployments MUST



McGuinness               Expires 1 November 2026               [Page 90]

Internet-Draft             OAuth Actor Profile                April 2026


   explicitly re-establish delegation grants for the new identity; the
   old grants do not automatically transfer.  Outstanding tokens issued
   under the old identity remain valid until their exp time; short token
   lifetimes bound the exposure window during the transition.

14.13.  Delegation Revocation

   The revocation-related requirements in this section are limited to
   how this profile interacts with already-issued tokens and refresh
   behavior.

   Token revocation ([RFC7009]) applies to individual tokens but does
   not revoke an underlying delegation relationship or invalidate
   already-issued downstream tokens in a delegation chain.  When Alice
   revokes her delegation to an agent, access tokens already issued to
   downstream actors remain valid until their exp time.  Short token
   lifetimes are the primary mitigation; see [RFC9700] for general
   access token lifetime guidance.

   The AS SHOULD refuse to issue new tokens for a (subject, actor) pair
   when it has authoritative knowledge that the delegation relationship
   has been revoked.  Implementations MUST NOT use delegation chain
   depth as a rationale for skipping revocation checks.

   When a deployment uses long-lived delegated refresh behavior,
   revocation of the delegation relationship may take effect later than
   it would in a model that requires re-presentation of a current
   upstream delegation artifact at each token request.  This document
   does not standardize refresh-token revocation or revalidation policy;
   deployments should account for that tradeoff explicitly.

   The internal mechanism by which an AS tracks delegation state
   (whether a formal registry, a consent store, a policy engine, or
   another form) is a deployment and product decision outside the scope
   of this document.  Resource servers in security-sensitive deployments
   may use token introspection ([RFC7662], Token Introspection
   (Section 8.4)) when request-time revocation state is needed, or may
   rely on short token lifetimes; the choice of revocation strategy is
   deployment-specific.

15.  Privacy Considerations

   Delegation chains can reveal sensitive information about user
   behavior, enterprise topology, software suppliers, and internal tool
   composition.  Issuers therefore SHOULD disclose only the actor
   information needed by the relying party for authorization, audit, or
   policy enforcement.




McGuinness               Expires 1 November 2026               [Page 91]

Internet-Draft             OAuth Actor Profile                April 2026


   Cross-domain deployments SHOULD prefer stable but non-reassigned
   identifiers and SHOULD consider pairwise identifiers for human
   subjects when a globally correlatable identifier is not required by
   the use case.

   When the same logical entity can appear in different identifier
   namespaces, such as azp, req_wl, and act.sub, issuers and relying
   parties SHOULD use explicit issuer scoping and locally trusted
   mapping rules rather than string equality alone to determine whether
   those identifiers refer to the same entity.

   Issuers SHOULD minimize disclosure of prior actors by audience and
   token-design decisions made before issuance.  Once an issuer chooses
   to preserve a delegation chain in a token under this profile, it
   SHOULD preserve the validated chain intact for that token.  If local
   privacy requirements would require omitting a chain element that
   would otherwise be security-relevant to the recipient's evaluation,
   the issuer SHOULD reject the request rather than silently truncating
   the chain.

   The txn claim in Transaction Tokens
   ([I-D.ietf-oauth-transaction-tokens]) is a stable, globally unique
   identifier shared across all tokens in a single business transaction.
   When Transaction Tokens cross organizational boundaries, txn enables
   cross-domain correlation of all service calls within a transaction by
   any party that observes multiple tokens.  Cross-domain propagation
   and lifetime rules for txn are governed by
   [I-D.ietf-oauth-transaction-tokens]; deployments SHOULD consult that
   specification's privacy guidance when propagating Transaction Tokens
   across trust-domain boundaries.  This document notes that txn values,
   like other stable identifiers, should be treated as sensitive in
   contexts where cross-domain correlation of user activity is not
   required or authorized.

   The act.sub_profile claim discloses the entity type of the actor,
   including values such as ai_agent that reveal that a request is being
   made by an automated agent on behalf of the subject.  In some
   jurisdictions or deployment contexts, this disclosure may be legally
   significant or may reveal sensitive information about user behavior
   and tool composition that should not flow across trust-domain
   boundaries.  Issuers SHOULD consider audience-specific disclosure
   constraints when including act.sub_profile in cross-domain tokens,
   and SHOULD omit or suppress actor entity-type values when the
   recipient does not require them for authorization, audit, or policy
   enforcement.






McGuinness               Expires 1 November 2026               [Page 92]

Internet-Draft             OAuth Actor Profile                April 2026


   The req_wl claim in Transaction Tokens can also expose sensitive
   information about internal workload topology and service composition.
   Transaction Token Services SHOULD disclose req_wl only to relying
   parties that need that information for authorization, audit, or
   policy enforcement, and SHOULD avoid propagating internal-only
   workload identifiers across trust-domain boundaries unless such
   disclosure is explicitly required by the deployment.

16.  IANA Considerations

16.1.  OAuth URI Registration

   This document requests IANA to register the following value in the
   "OAuth URI" registry:

   *  URN: urn:ietf:params:oauth:grant-profile:actor-profile

   *  Common Name: OAuth Actor Profile for Delegation

   *  Change Controller: IETF

   *  Reference: Authorization Server Metadata (Section 10.1) of this
      document

16.2.  OAuth Authorization Server Metadata Registry

   This document requests IANA to register the following values in the
   "OAuth Authorization Server Metadata" registry ([RFC8414]):

   *  Metadata Name: actor_profile_token_exchange

   *  Metadata Description: JSON object advertising coarse Token
      Exchange capabilities for requests in which actor-profile
      processing can apply

   *  Change Controller: IETF

   *  Reference: Authorization Server Metadata (Section 10.1) of this
      document

16.3.  OAuth Protected Resource Metadata Registry

   This document requests IANA to register the following values in the
   "OAuth Protected Resource Metadata" registry ([RFC9728]):

   *  Metadata Name: actor_profile_required





McGuinness               Expires 1 November 2026               [Page 93]

Internet-Draft             OAuth Actor Profile                April 2026


   *  Metadata Description: Boolean indicating whether the RS advertises
      that delegated requests for this resource are expected to provide
      actor-profile information conforming to this document's semantics

   *  Change Controller: IETF

   *  Reference: Protected Resource Metadata (Section 10.2) of this
      document

16.4.  OAuth Error Registry

   This document requests IANA to register the following value in the
   "OAuth Extensions Error Registry" ([RFC6749], Section 11.4):

   *  Error Name: actor_unauthorized

   *  Error Usage Location: Token endpoint response, resource server
      response

   *  Related Protocol Extension: OAuth Actor Profile for Delegation

   *  Change Controller: IETF

   *  Reference: Error Responses (Section 9) of this document

16.5.  OAuth Token Introspection Response Registry

   This document requests IANA to register the following value in the
   "OAuth Token Introspection Response" registry ([RFC7662],
   Section 3.3):

   *  Claim Name: chain_complete

   *  Claim Description: Boolean indicating whether the act delegation
      chain in the introspection response is complete.  When false, one
      or more inner act chain entries have been omitted from the
      response for privacy reasons.  When absent, the chain SHOULD be
      treated as complete unless local policy or deployment context
      indicates otherwise.

   *  Change Controller: IETF

   *  Reference: Token Introspection (Section 8.4) of this document








McGuinness               Expires 1 November 2026               [Page 94]

Internet-Draft             OAuth Actor Profile                April 2026


16.6.  JWT Claims Registry

   This document does not request independent JWT Claims Registry
   entries for the act object sub-claims (iss, sub_profile, and any
   extension claims) it defines or profiles.  These values appear only
   within the JSON object value of the act claim, which is already
   registered in the JWT Claims Registry by [RFC8693].  Sub-object keys
   within a registered claim are scoped to that claim's JSON object and
   do not require separate top-level registry entries.

16.7.  OAuth Token Type Registry

   This document makes no independent requests to the "OAuth Token Type"
   registry for urn:ietf:params:oauth:token-type:txn_token.  That URI is
   defined and registered by [I-D.ietf-oauth-transaction-tokens].  Its
   inclusion as a defined value for
   actor_profile_token_exchange.requested_token_types_supported in
   Authorization Server Metadata (Section 10.1) is contingent on the
   progression of [I-D.ietf-oauth-transaction-tokens].

16.8.  OAuth Entity Profiles Registry

   This document makes no independent requests to the "OAuth Entity
   Profiles" registry.  It normatively depends on the "Actor Profile"
   usage location, the actor array in entity_profiles_supported, and the
   registration of user, service, and ai_agent with that usage location,
   all of which are defined and requested by
   [I-D.mora-oauth-entity-profiles].  The IANA actions for those entries
   are contingent on the progression of
   [I-D.mora-oauth-entity-profiles].

17.  References

17.1.  Normative References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.



McGuinness               Expires 1 November 2026               [Page 95]

Internet-Draft             OAuth Actor Profile                April 2026


   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7521]  Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0 Client Authentication
              and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
              May 2015, <https://www.rfc-editor.org/info/rfc7521>.

   [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
              2015, <https://www.rfc-editor.org/info/rfc7523>.

   [RFC8705]  Campbell, B., Bradley, J., Sakimura, N., and T.
              Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
              and Certificate-Bound Access Tokens", RFC 8705,
              DOI 10.17487/RFC8705, February 2020,
              <https://www.rfc-editor.org/info/rfc8705>.

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/info/rfc7662>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/info/rfc7800>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

   [RFC9728]  Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
              Protected Resource Metadata", RFC 9728,
              DOI 10.17487/RFC9728, April 2025,
              <https://www.rfc-editor.org/info/rfc9728>.




McGuinness               Expires 1 November 2026               [Page 96]

Internet-Draft             OAuth Actor Profile                April 2026


   [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,
              <https://www.rfc-editor.org/info/rfc8693>.

   [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
              Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
              2021, <https://www.rfc-editor.org/info/rfc9068>.

   [RFC8707]  Campbell, B., Bradley, J., and H. Tschofenig, "Resource
              Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
              February 2020, <https://www.rfc-editor.org/info/rfc8707>.

   [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, <https://www.rfc-editor.org/info/rfc9449>.

   [I-D.ietf-oauth-transaction-tokens]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-ietf-oauth-transaction-tokens-08, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              transaction-tokens-08>.

   [I-D.ietf-wimse-workload-creds]
              Campbell, B., Salowey, J. A., Schwenkschuster, A.,
              Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
              Credentials", Work in Progress, Internet-Draft, draft-
              ietf-wimse-workload-creds-00, 3 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              workload-creds-00>.

   [I-D.ietf-wimse-wpt]
              Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
              Token", Work in Progress, Internet-Draft, draft-ietf-
              wimse-wpt-01, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              wpt-01>.

   [I-D.mora-oauth-entity-profiles]
              Mora, S. C., Dingle, P., and K. McGuinness, "OAuth Entity
              Profiles", 17 April 2026,
              <https://www.ietf.org/archive/id/draft-mora-oauth-entity-
              profiles-01.txt>.






McGuinness               Expires 1 November 2026               [Page 97]

Internet-Draft             OAuth Actor Profile                April 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

17.2.  Informative References

   [RFC9493]  Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject
              Identifiers for Security Event Tokens", RFC 9493,
              DOI 10.17487/RFC9493, December 2023,
              <https://www.rfc-editor.org/info/rfc9493>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC9700]  Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
              "Best Current Practice for OAuth 2.0 Security", BCP 240,
              RFC 9700, DOI 10.17487/RFC9700, January 2025,
              <https://www.rfc-editor.org/info/rfc9700>.

   [I-D.parecki-oauth-jwt-dpop-grant]
              Parecki, A., "JWT Authorization Grants with DPoP", 30
              January 2026, <https://datatracker.ietf.org/doc/html/
              draft-parecki-oauth-jwt-dpop-grant-01>.

   [I-D.ietf-oauth-identity-chaining]
              Schwenkschuster, A., Kasselmann, P., Burgin, K., Jenkins,
              M., Campbell, B., and A. Parecki, "OAuth Identity and
              Authorization Chaining Across Domains", Work in Progress,
              Internet-Draft, draft-ietf-oauth-identity-chaining-10, 24
              April 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-oauth-identity-chaining-10>.

   [I-D.ietf-oauth-identity-assertion-authz-grant]
              Parecki, A., McGuinness, K., and B. Campbell, "Identity
              Assertion JWT Authorization Grant", 22 April 2026,
              <https://www.ietf.org/archive/id/draft-ietf-oauth-
              identity-assertion-authz-grant-03.txt>.

   [OpenID.Core]
              OpenID Foundation, "OpenID Connect Core 1.0", 8 November
              2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.



McGuinness               Expires 1 November 2026               [Page 98]

Internet-Draft             OAuth Actor Profile                April 2026


   [OpenID.Federation]
              OpenID Foundation, "OpenID Federation 1.0", 1 May 2024,
              <https://openid.net/specs/openid-federation-1_0.html>.

Appendix A.  Service-to-Service Delegation Example

   This appendix gives a non-AI example of the actor profile in a same-
   domain service-to-service delegation flow.  A payroll batch processor
   acts on behalf of a human payroll administrator to call a payroll
   API; the payroll API then exchanges that access token for an internal
   Transaction Token used to write an audit record.

A.1.  Scenario

      +=========================+===================================+
      | Party                   | Identifier                        |
      +=========================+===================================+
      | Payroll Administrator   | https://idp.example.com/users/pat |
      +-------------------------+-----------------------------------+
      | Enterprise AS           | https://as.example.com            |
      +-------------------------+-----------------------------------+
      | Payroll Batch Processor | https://services.example.com/     |
      |                         | payroll-batch                     |
      +-------------------------+-----------------------------------+
      | Payroll API             | https://services.example.com/     |
      |                         | payroll-api                       |
      +-------------------------+-----------------------------------+
      | Audit TTS               | https://tts.example.com           |
      +-------------------------+-----------------------------------+
      | Audit Service           | https://internal.example.com/     |
      |                         | audit                             |
      +-------------------------+-----------------------------------+

                                  Table 4

   The batch processor is an OAuth client and also the acting service.
   The client registration remains identified by client_id; the acting
   service is represented explicitly in act.sub.

A.2.  Access Token

   The Enterprise AS issues a JWT access token for the Payroll API:









McGuinness               Expires 1 November 2026               [Page 99]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.example.com",
     "sub": "https://idp.example.com/users/pat",
     "sub_profile": "user",
     "client_id": "payroll-batch-client",
     "aud": "https://services.example.com/payroll-api",
     "scope": "payroll:run",
     "cnf": { "jkt": "SvcJKT-123" },
     "act": {
       "sub": "https://services.example.com/payroll-batch",
       "iss": "https://as.example.com",
       "sub_profile": "service"
     }
   }

   This is a single-hop actor object: act is present, but it contains no
   nested act.  sub identifies the payroll administrator, while act.sub
   identifies the service exercising that administrator's authorization.

A.3.  Transaction Token

   After processing the payroll request, the Payroll API exchanges the
   inbound access token at the Audit TTS to call the internal Audit
   Service.  The Payroll API is the requesting workload (req_wl).  The
   TTS validates the inbound delegation chain, preserves it as an inner
   act, and adds a new outermost actor for the Payroll API:

   {
     "iss": "https://tts.example.com",
     "sub": "https://idp.example.com/users/pat",
     "sub_profile": "user",
     "req_wl": "https://services.example.com/payroll-api",
     "aud": "https://internal.example.com/audit",
     "scope": "audit:create",
     "txn": "550e8400-e29b-41d4-a716-446655440099",
     "cnf": { "jkt": "ApiJKT-456" },
     "act": {
       "sub": "https://services.example.com/payroll-api",
       "iss": "https://as.example.com",
       "sub_profile": "service",
       "act": {
         "sub": "https://services.example.com/payroll-batch",
         "iss": "https://as.example.com",
         "sub_profile": "service"
       }
     }
   }




McGuinness               Expires 1 November 2026              [Page 100]

Internet-Draft             OAuth Actor Profile                April 2026


   The subject remains the payroll administrator.  The new outermost
   actor is the Payroll API (the workload presenting the exchange
   request), and the preserved inner actor is the payroll batch
   processor.  This example demonstrates that the profile applies
   equally to non-AI service delegation and to transformations from a
   single-hop actor object into a multi-hop delegation chain.

Appendix B.  Cross-Domain AI Agent Flow: ID Token to Transaction Token

   This appendix traces a single user request across two trust domains,
   highlighting the actor-profile claim structures and processing
   requirements specific to this document.  Standard validation steps
   (JWT signature verification, sender-constrained access token proof,
   Transaction Token presenter proof, and Token Exchange mechanics) are
   delegated to the underlying token specifications and deployment
   profile.

   All claim values, JKT thumbprints, and domain names are synthetic.

B.1.  Scenario and Parties

   Alice's travel-assistant agent authenticates to the Enterprise IdP AS
   to obtain an ID Token.  The agent then performs a Token Exchange at
   the same AS to obtain the ID-JAG.  The ID-JAG is then presented to
   the Travel Provider AS using the JWT bearer grant, as described in
   Authorization Grant Processing (Section 4.2).  The agent exchanges
   the ID-JAG for an access token at the Travel Provider AS and calls
   the Booking Tool API.  The Booking Tool exchanges the access token
   for a Transaction Token to call an internal inventory service.






















McGuinness               Expires 1 November 2026              [Page 101]

Internet-Draft             OAuth Actor Profile                April 2026


Enterprise domain                 Travel Provider domain
────────────────────────────      ──────────────────────────────────────
Alice
  │ (1) authenticates
  ▼
Enterprise IdP AS ─► ID Token
  │ (2) Token Exchange (ID Token → ID-JAG)
  ▼
Enterprise IdP AS ─► ID-JAG
                       │ (3) JWT Bearer Grant (ID-JAG → AT)
                       └─────────────────► Travel Provider AS ─► AT
                                                                   │
                                            Travel Assistant ◄─────┘
                                                 │ (4) Access Token + DPoP
                                                 ▼
                                            Booking Tool API (RS)
                                                 │ (5) Token Exchange (AT → Transaction Token)
                                                 ▼
                                            Travel Provider TTS ─► Transaction Token
                                                 │ (6) Transaction Token + WIMSE proof
                                                 ▼
                                            Inventory Service (RS)





























McGuinness               Expires 1 November 2026              [Page 102]

Internet-Draft             OAuth Actor Profile                April 2026


   +==============+=======================================+============+
   | Party        | Identifier                            | Trust      |
   |              |                                       | Domain     |
   +==============+=======================================+============+
   | Alice        | https://idp.enterprise.example/users/ | Enterprise |
   |              | alice                                 |            |
   +--------------+---------------------------------------+------------+
   | Enterprise   | https://as.enterprise.example         | Enterprise |
   | IdP AS       |                                       |            |
   +--------------+---------------------------------------+------------+
   | Travel       | https://agents.enterprise.example/    | Enterprise |
   | Assistant    | travel-assistant                      |            |
   +--------------+---------------------------------------+------------+
   | Travel       | https://as.travel-provider.example    | Travel     |
   | Provider AS  |                                       | Provider   |
   +--------------+---------------------------------------+------------+
   | Travel       | https://tts.travel-provider.example   | Travel     |
   | Provider     |                                       | Provider   |
   | TTS          |                                       |            |
   +--------------+---------------------------------------+------------+
   | Booking      | https://tools.travel-                 | Travel     |
   | Tool         | provider.example/booking-tool         | Provider   |
   +--------------+---------------------------------------+------------+
   | Inventory    | https://internal.travel-              | Travel     |
   | Service      | provider.example/inventory            | Provider   |
   +--------------+---------------------------------------+------------+

                                  Table 5

   Presenter key bindings:

             +==================+===========================+
             | Principal        | JWK Thumbprint (jkt)      |
             +==================+===========================+
             | Travel Assistant | AgentJKT-NzbLsXh8uDCcd7MN |
             +------------------+---------------------------+
             | Booking Tool     | ToolJKT-0ZcOCORZNYy9ZhHi  |
             +------------------+---------------------------+

                                 Table 6

B.2.  Capability Discovery (Preflight)

   The agent consults the Travel Provider AS metadata (Metadata and
   Discovery (Section 10)) as an advisory compatibility check before
   initiating the flow:





McGuinness               Expires 1 November 2026              [Page 103]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "issuer": "https://as.travel-provider.example",
     "grant_types_supported": [
       "urn:ietf:params:oauth:grant-type:jwt-bearer",
       "urn:ietf:params:oauth:grant-type:token-exchange"
     ],
     "authorization_grant_profiles_supported": [
       "urn:ietf:params:oauth:grant-profile:id-jag",
       "urn:ietf:params:oauth:grant-profile:actor-profile"
     ],
     "actor_profile_token_exchange": {
       "subject_token_types_supported": [
         "urn:ietf:params:oauth:token-type:jwt"
       ],
       "actor_token_types_supported": [
         "urn:ietf:params:oauth:token-type:jwt"
       ],
       "requested_token_types_supported": [
         "urn:ietf:params:oauth:token-type:access_token",
         "urn:ietf:params:oauth:token-type:txn_token"
       ]
     },
     "entity_profiles_supported": {
       "subject": ["user", "ai_agent"],
       "actor":   ["user", "ai_agent", "service"]
     }
   }

   The agent confirms that its sub_profile (ai_agent) is in
   entity_profiles_supported.actor, that ID-JAG and actor-profile grants
   are advertised in authorization_grant_profiles_supported, and that
   the planned input/output token types appear in
   actor_profile_token_exchange.  These signals are coarse compatibility
   indicators only; the agent proceeds because the advertised
   capabilities cover its planned path.

B.3.  Step 1: User Authentication (ID Token)

   Alice authenticates to the Enterprise IdP AS, which issues an ID
   Token.  An ID Token implicitly identifies a user; the entity type is
   not carried in a sub_profile claim and is established by the AS in
   subsequent issued tokens (Step 2):









McGuinness               Expires 1 November 2026              [Page 104]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.enterprise.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "aud": "https://agents.enterprise.example/travel-assistant",
     "exp": 1743379200,
     "iat": 1743375600
   }

B.4.  Step 2: Enterprise Token Exchange (ID Token to ID-JAG)

   The agent presents Alice's ID Token as subject_token in a Token
   Exchange request to the Enterprise IdP AS, requesting an ID-JAG
   ([I-D.ietf-oauth-identity-assertion-authz-grant]).  The agent's RFC
   7523 client assertion serves as both client_assertion (for client
   authentication) and actor_token (for actor identity), per JWT Client
   Assertion (Section 6.3.1).  The Enterprise IdP AS authenticates the
   client, verifies the ID Token audience matches that client, and uses
   local delegation policy to construct the issued ID-JAG:

POST /token HTTP/1.1
Host: as.enterprise.example
Content-Type: application/x-www-form-urlencoded
DPoP: <AgentJKT-proof>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=<alice-id-token>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid-jag
&audience=https%3A%2F%2Fas.travel-provider.example%2F
&resource=https%3A%2F%2Fas.travel-provider.example
&scope=booking%3Acreate
&client_id=https%3A%2F%2Fagents.enterprise.example%2Ftravel-assistant
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=<travel-assistant-client-assertion>
&actor_token=<travel-assistant-client-assertion>
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

   The Enterprise IdP AS applies scope reduction and validates the
   client-bound proof-of-possession according to RFC 9449.  In this
   example, it binds the issued ID-JAG to the key demonstrated in the
   DPoP proof, validates the shared JWT under both the client-
   authentication and actor_token rules for RFC 7523 client assertions,
   determines from local policy that the authenticated client is the
   delegated actor for Alice in this flow, and issues the ID-JAG as a
   JWT output of Token Exchange with the delegation chain established
   per Actor Profile for Delegation (Section 3):





McGuinness               Expires 1 November 2026              [Page 105]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://as.enterprise.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "sub_profile": "user",
     "client_id": "https://agents.enterprise.example/travel-assistant",
     "azp": "https://agents.enterprise.example/travel-assistant",
     "aud": "https://as.travel-provider.example/token",
     "jti": "ent-idj-20260401-001",
     "exp": 1743379200,
     "iat": 1743375600,
     "scope": "booking:create",
     "cnf": { "jkt": "AgentJKT-NzbLsXh8uDCcd7MN" },
     "act": {
       "sub": "https://agents.enterprise.example/travel-assistant",
       "iss": "https://as.enterprise.example",
       "sub_profile": "ai_agent"
     }
   }

   The act object records the agent as the authorized actor.  The
   client_id and azp values identify the OAuth client used in the
   exchange, while act.sub identifies the delegated actor.  In this
   example those identifiers are the same URI, so the shared RFC 7523
   client assertion and actor_token remain conformant with [RFC7523]
   while still making the actor explicit in the issued token.  The top-
   level cnf.jkt is set to AgentJKT because the agent is the current
   presenter at this stage.

B.5.  Step 3: Agent Exchanges ID-JAG for Access Token at Travel Provider
      AS

   The agent presents the ID-JAG as a JWT Bearer authorization grant
   ([RFC7523]) to the Travel Provider AS, which processes it as an ID-
   JAG per [I-D.ietf-oauth-identity-assertion-authz-grant] with the
   actor-profile rules in Authorization Grant Processing (Section 4.2):

   POST /token HTTP/1.1
   Host: as.travel-provider.example
   Content-Type: application/x-www-form-urlencoded
   DPoP: <AgentJKT-proof>

   grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
   &assertion=<id-jag>
   &scope=booking%3Acreate

   The Travel Provider AS performs actor-profile processing per
   Authorization Grant Processing (Section 4.2): it verifies the
   request's DPoP proof against the top-level cnf.jkt in the inbound ID-



McGuinness               Expires 1 November 2026              [Page 106]

Internet-Draft             OAuth Actor Profile                April 2026


   JAG and checks that act.sub_profile (ai_agent) is permitted as an
   actor for the requested scope under local policy.  It issues an
   access token preserving the delegation chain:

   {
     "iss": "https://as.travel-provider.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "sub_profile": "user",
     "client_id": "https://agents.enterprise.example/travel-assistant",
     "azp": "https://agents.enterprise.example/travel-assistant",
     "aud": "https://api.travel-provider.example",
     "jti": "tp-at-20260401-001",
     "exp": 1743379200,
     "iat": 1743375600,
     "scope": "booking:create",
     "cnf": { "jkt": "AgentJKT-NzbLsXh8uDCcd7MN" },
     "act": {
       "sub": "https://agents.enterprise.example/travel-assistant",
       "iss": "https://as.enterprise.example",
       "sub_profile": "ai_agent"
     }
   }

   Alice's sub and sub_profile are preserved verbatim from the ID-JAG
   (JWT Access Token Output (Section 6.5.2)).  The Travel Provider AS
   does not translate or substitute the enterprise subject identifier.
   The client_id and azp values reflect the OAuth client identity from
   the request context (the same agent URI appears in both the inbound
   ID-JAG and the outbound access token because the agent is both the
   asserting client and the actor in this flow), but they do not replace
   act.sub as the authoritative delegated-actor identifier.

B.6.  Step 4: Agent Calls Booking Tool API

   The agent presents the access token with a DPoP proof:

   POST /bookings HTTP/1.1
   Host: api.travel-provider.example
   Authorization: DPoP <tp-access-token>
   DPoP: <AgentJKT-proof>
   Content-Type: application/json

   {"origin": "SFO", "destination": "NYC", "depart": "2026-04-15"}

   The Booking Tool RS applies authorization of the (sub, outermost
   act.sub) pair (Resource Server Processing (Section 8)): it evaluates
   Alice (sub, sub_profile: user) together with the Travel Assistant
   (act.sub, sub_profile: ai_agent) for the requested operation.  The



McGuinness               Expires 1 November 2026              [Page 107]

Internet-Draft             OAuth Actor Profile                April 2026


   act.sub_profile value is checked against
   entity_profiles_supported.actor per Authorization Server Metadata
   (Section 10.1).

B.7.  Step 5: Booking Tool Exchanges Access Token for Transaction Token

   The Booking Tool cannot reuse the received access token for internal
   calls: it is sender-constrained to AgentJKT, which the Booking Tool
   does not possess.  It requests a Transaction Token from the TTS.  In
   this example, the TTS receives the Booking Tool's WIMSE Workload
   Identity Token (WIT) as the Token Exchange actor_token and validates
   a Workload Proof Token (WPT).  The WIT identifies the Booking Tool
   and carries its confirmation key, while the WPT proves possession of
   that key and binds the request to the accompanying access token:

POST /token HTTP/1.1
Host: tts.travel-provider.example
Content-Type: application/x-www-form-urlencoded
Workload-Proof-Token: <tool-wpt-with-wth-and-ath>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=<tp-access-token>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&actor_token=<booking-tool-wit>
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn_token
&audience=https%3A%2F%2Ftravel-provider.example
&scope=inventory%3Acheck
&rctx={"req_ip":"198.51.100.42"}

   The WIT is therefore the JWT actor_token defined by this profile,
   while the WPT provides the accompanying proof of possession required
   by the workload-credential profile.

   The TTS applies actor-profile processing per Transaction Token Output
   Rules (Section 7.4): it preserves sub and sub_profile from the
   subject_token, sets req_wl to the authenticated Booking Tool, and
   creates a new outermost act object for the Booking Tool while nesting
   the subject_token's existing act claim beneath it.  In this WIMSE-
   based deployment, the underlying Transaction Token mechanism also
   binds the issued token to the Booking Tool's presenter key (ToolJKT)
   identified in the WIT confirmation claim:









McGuinness               Expires 1 November 2026              [Page 108]

Internet-Draft             OAuth Actor Profile                April 2026


   {
     "iss": "https://tts.travel-provider.example",
     "sub": "https://idp.enterprise.example/users/alice",
     "sub_profile": "user",
     "scope": "inventory:check",
     "req_wl": "https://tools.travel-provider.example/booking-tool",
     "aud": "https://travel-provider.example",
     "jti": "txn-tok-20260401-001",
     "txn": "550e8400-e29b-41d4-a716-446655440001",
     "exp": 1743375750,
     "iat": 1743375650,
     "tctx": {
       "action": "check-availability",
       "origin": "SFO",
       "destination": "NYC",
       "depart": "2026-04-15"
     },
     "rctx": { "req_ip": "198.51.100.42" },
     "cnf": { "jkt": "ToolJKT-0ZcOCORZNYy9ZhHi" },
     "act": {
       "sub": "https://tools.travel-provider.example/booking-tool",
       "iss": "https://as.travel-provider.example",
       "sub_profile": "service",
       "act": {
         "sub": "https://agents.enterprise.example/travel-assistant",
         "iss": "https://as.enterprise.example",
         "sub_profile": "ai_agent"
       }
     }
   }

   The presenter binding rotates at this step: cnf.jkt is now ToolJKT
   because the Booking Tool is the current presenter.

B.8.  Step 6: Booking Tool Calls Inventory Service

   GET /inventory?origin=SFO&dest=NYC&depart=2026-04-15 HTTP/1.1
   Host: internal.travel-provider.example
   Txn-Token: <txn-token>
   Workload-Identity-Token: <booking-tool-wit>
   Workload-Proof-Token: <tool-wpt-with-wth-and-tth>

   The Inventory Service validates the WIT and WPT per the WIMSE
   specifications, then applies authorization of the (sub, outermost
   act.sub) pair (Resource Server Processing (Section 8)): Alice (sub)
   governs data access policy (e.g., travel tier), and the Booking Tool
   (act.sub) is the authorized internal workload for that request.  The
   req_wl claim provides consistent TTS workload context for the same



McGuinness               Expires 1 November 2026              [Page 109]

Internet-Draft             OAuth Actor Profile                April 2026


   service in this example.  The nested act.act.sub (the Travel
   Assistant) is carried as prior delegation context and is not
   evaluated for access control at this internal tier, consistent with
   the guidance on inner actors in Actor Authorization (Section 8.1).

B.9.  Summary of Token Transformations

    +====+===========+=====+=======+===========+=============+========+
    |Step|Token      |sub  |req_wl |act.sub    | act.act.sub |cnf.jkt |
    |    |           |     |       |(outermost)| (nested)    |        |
    +====+===========+=====+=======+===========+=============+========+
    |1   |ID Token   |Alice|       |           |             |        |
    +----+-----------+-----+-------+-----------+-------------+--------+
    |2   |ID-JAG     |Alice|       |Travel     |             |AgentJKT|
    |    |           |     |       |Assistant  |             |        |
    +----+-----------+-----+-------+-----------+-------------+--------+
    |3   |Access     |Alice|       |Travel     |             |AgentJKT|
    |    |Token      |     |       |Assistant  |             |        |
    +----+-----------+-----+-------+-----------+-------------+--------+
    |4   |(API call) |Alice|       |Travel     |             |AgentJKT|
    |    |           |     |       |Assistant  |             |        |
    +----+-----------+-----+-------+-----------+-------------+--------+
    |5   |Transaction|Alice|Booking|Booking    | Travel      |ToolJKT |
    |    |Token      |     |Tool   |Tool       | Assistant   |        |
    +----+-----------+-----+-------+-----------+-------------+--------+
    |6   |(internal  |Alice|Booking|Booking    | Travel      |ToolJKT |
    |    |call)      |     |Tool   |Tool       | Assistant   |        |
    +----+-----------+-----+-------+-----------+-------------+--------+

                                  Table 7

   Key observations:

   *  In this example, sub (Alice) is unchanged across all trust domains
      and token transformations.

   *  The presenter-binding key rotates once, at Step 5 when the TTS re-
      binds the Transaction Token to the Booking Tool's key.

   *  At Step 5 the TTS creates a new outermost act for the Booking Tool
      and nests the prior act chain beneath it.










McGuinness               Expires 1 November 2026              [Page 110]

Internet-Draft             OAuth Actor Profile                April 2026


Acknowledgments

   The author thanks the OAuth Working Group for the foundational work
   on Token Exchange (RFC 8693), JWT-formatted access tokens (RFC 9068),
   DPoP (RFC 9449), and Transaction Tokens, upon which this document
   builds.  The motivating use cases for this work emerged from the
   deployment of AI agent systems that require cross-domain delegation
   with explicit delegation chains and carried-forward delegation state
   within the trust model of the issuing domains.

Author's Address

   Karl McGuinness
   Independent
   Email: public@karlmcguinness.com




































McGuinness               Expires 1 November 2026              [Page 111]
