OAuth Actor Profile for Delegation

OAuth Actor Profile for Delegation Independent

public@karlmcguinness.com

Security Web Authorization Protocol oauth delegation actor token exchange token This document defines a common representation of delegated actors in OAuth JSON Web Token (JWT) assertion grants, JWT access tokens, and Transaction Tokens. It profiles the act claim defined by OAuth 2.0 Token Exchange, requires issuer-scoped actor identifiers, and uses the sub_profile claim to classify actor entity types. It specifies token processing, delegation-chain propagation, sender-constraint handling, and discovery metadata, so that issuers and resource servers in different trust domains interpret delegated actors consistently. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Delegated requests can pass through several services and trust domains. Each recipient needs to distinguish the subject whose authorization is exercised, the actor exercising it, and the OAuth client requesting the token: sub identifies the authorizing principal, act.sub the actor, and client_id the client registration. This profile makes the actor explicit in the token rather than leaving it to be inferred from client registration, without redefining client identity or subject semantics. OAuth 2.0 Token Exchange defines the act claim for the current actor and prior actors, but leaves "the specifics of representing a composite token" to implementations (). It notes that the iss and sub claims together "might be necessary" to identify an actor (), but it does not require an identifier context or classify actors. Its delegation example derives the act claim from the subject of the actor_token (), but it does not specify actor validation and derivation rules for each token type, how act propagates across JWT assertion grants, JWT access tokens, and Transaction Tokens, or how the actor relates to a sender-constrained presenter. Without a common profile, deployments face four interoperability gaps:

No standard entity classification. The sub claim is overloaded across end-users, service accounts, AI agents, and workloads, with no classification that supports deterministic cross-domain policy.
Inconsistent actor representation across token types. Actor context, including actor key material, has no representation that survives transformation among JWT assertion grants, JWT access tokens, and Transaction Tokens.
Implicit delegation via client identity. A client registration alone might not identify the actor, particularly when one registration serves several agents or workloads, when requests pass through intermediaries, or when tokens cross trust domains.
No discovery for actor-profile support. Neither AS metadata nor Protected Resource Metadata defines parameters for advertising actor-profile support.

This document profiles act to close those gaps. It defines:

Issuer-scoped actor identifiers and entity classification using sub_profile.
Rules for validating, extending, and preserving actor information when tokens are exchanged or reissued.
Presenter continuation and rebind rules for sender-constrained tokens, including upgrades from bearer tokens.
Resource server processing based on the (sub, outermost act.sub) pair, and metadata for advertising profile support.
Extension points for companion profiles that provide additional delegation evidence.

This profile applies to human, service, workload, and AI agent delegation. The requirements of the underlying specifications, including , , , and , continue to apply unless this document states otherwise. Profile Scope describes the supported token paths and the boundary between representation and authorization policy.

Illustrative Use Case Alice authorizes an AI travel agent to book a trip. The enterprise AS issues a credential with Alice as sub and the agent as act. The agent presents that credential to a booking provider's AS for an access token, and the provider then issues a Transaction Token for an internal booking tool. Alice remains the subject; the tool becomes the outermost actor, and the agent becomes an inner actor. Each trust domain issues a new token under its own policy, and the outermost actor changes only when a new presenter is established. The cross-domain example shows the complete flow.

Relationship to Related Work

OAuth Token Exchange () defines the act claim and exchange mechanism profiled here.
Identity Chaining () propagates subject identity across domains and can be combined with this profile's actor representation.
Identity Assertion JWT Authorization Grant (ID-JAG, ) defines the issuance and consumption of JWT authorization grants. It permits actor_token inputs but leaves their processing, and whether the issued grant carries the act claim, to future profiles or extensions; this document is one such profile, through its Token Exchange and JWT assertion-grant rules.
OAuth Entity Profiles () defines the classification claims, metadata, and registry used by this profile.
Transaction Tokens () defines the token and service model extended here with actor claims and processing rules.
WIMSE Workload Identity (, ) defines workload credentials and proofs used in the cross-domain example. This profile also supports other presenter-authentication mechanisms.

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 when, and only when, they appear in all capitals, as shown here. This document uses the OAuth terminology defined in and , and the terms Transaction Token and Transaction Token Service (TTS) defined in . AS and RS denote authorization server and resource server, respectively. This document uses the following terms:

Actor:: The party 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:: Delegation in which the subject and actor are governed by different trust domains or identifier namespaces. Deployment policy determines whether a token represents cross-domain delegation, based on issuer context, actor identifiers, and applicable trust agreements. The top-level iss claim alone is not always sufficient.
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.
Delegation Chain:: The sequence of actors representing how authorization has passed from the subject principal (sub) to the first actor (innermost act) and through any intermediate parties to the immediate actor (outermost act.sub). The chain is conveyed by the nested structure of the act claim.
Outermost Actor:: The act object at the top level of the delegation chain (the one not nested inside any other act object). The outermost actor identifies the current presenter of the token.
Local Policy:: Rules or decisions, not defined by this document, that an AS, RS, or organization applies, such as delegation approval, scope reduction, identifier mapping, and entity-profile acceptance.
Identifier Reconciliation:: Applying configured mapping rules to determine whether identifiers from different claims or namespaces refer to the same entity. A recommendation to perform identifier reconciliation means the implementation SHOULD apply those rules. String similarity or shared naming patterns do not establish equivalence. If no applicable mapping exists or reconciliation fails, equivalence is not established: the identifiers MUST be treated as distinct, and an implementation MUST reject a request or token whose processing requires them to identify the same entity.

Examples are illustrative and can omit claims, parameters, or validation steps unrelated to this profile. 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).

Actor Profile for Delegation

Overview When an implementation uses this profile to represent an actor distinct from the subject, it MUST apply the requirements in this section. The absence of an explicit inbound actor credential MUST NOT by itself be interpreted as making the OAuth client the delegated actor.

Profile Invariants

Claim	Meaning
Top-level `sub`	Subject whose authorization is exercised
Outermost (`act.iss`, `act.sub`)	Canonical identifier of the immediate actor
Inner `act` objects	Prior actors, ordered from most recent to earliest
`client_id`, `azp`	OAuth client identity
Top-level `cnf`	Current presenter's key or certificate binding

Inner actors have the trust properties described in Carry Prior-Actor Context. When (act.iss, act.sub) identifies the same entity as the token's (iss, sub), consumers MUST NOT infer a delegation relationship. Comparing act.sub with sub alone is insufficient; the identifier contexts are part of the comparison.

Profile Scope

Representation and Policy This profile standardizes actor representation, propagation, validation, and discovery. Delegation approval, trust frameworks, and identifier mappings remain deployment-specific. Cross-domain deployments require agreements that cover permitted delegation relationships and identifier namespaces. Actor Authorization describes when an RS enforces authorization of the (sub, outermost act.sub) pair; this document does not require it on every request.

Token Format Scope Conforming outputs are JWT assertion grants, JWT access tokens, and Transaction Tokens. Token Introspection defines optional equivalent response members for delegated opaque access tokens; this compatibility path does not make the opaque token itself conformant. Opaque access tokens used as Token Exchange inputs are outside the interoperable scope of this document. An AS MAY translate their introspection results into local inputs under deployment-specific rules.

Supported Token Types and Request Semantics

Role	Supported credentials
Token Exchange `subject_token`	JWT assertion grant, JWT access token, ID Token, refresh token, Transaction Token
Token Exchange `actor_token`	Workload identity credential, JWT client assertion, non-delegated JWT access token
TTS `subject_token`	JWT assertion grant, JWT access token, Transaction Token
Issued token	JWT assertion grant, JWT access token, Transaction Token

Subject to endpoint policy and the underlying grant mechanism, implementations MAY transform supported inputs into outputs for which this document defines issuance rules. They need not support every combination. For each supported path, actor information MUST be validated and preserved according to the output rules in JWT Assertion Grant Output, JWT Access Token Output, or Transaction Token Output Rules. The may_act claim is an optional delegation-authorization input, with the restrictions in may_act. It neither establishes actor identity nor propagates to the output token. The service-to-service example and the cross-domain example show same-domain service delegation and cross-domain delegation, respectively.

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 , a profile-conformant actor object MUST contain an iss claim and SHOULD contain a sub_profile claim when the issuer can authoritatively classify the actor's entity type. An act object that omits the iss claim conforms to but does not conform to this profile; Migration and Adoption specifies the handling of such objects. any ; extension claims } ]]>

sub:: REQUIRED. The subject identifier of the actor, as defined in . It is a StringOrURI as defined in .
iss:: REQUIRED. The issuer or namespace context for act.sub, expressed as a StringOrURI . Together, (act.iss, act.sub) form the canonical actor identifier. For any actor identifier scheme, act.iss MUST identify the context used when assigning or asserting that identifier. Implementations MUST NOT interpret act.iss as the current token issuer, credential issuer, or hop-provenance marker. These entities can coincide but have distinct roles. HTTPS URLs and workload-identity URNs are examples of possible context identifiers. For example, a TTS at https://tts.travel-provider.example can issue a Transaction Token whose booking-tool actor has act.iss set to https://as.travel-provider.example because that AS issued the booking tool's workload credential. The TTS signs the token; the AS supplies the namespace for the tool's identifier.
sub_profile:: RECOMMENDED. A space-delimited list of entity profile values classifying the actor identified by act.sub, as defined in . Values used within act objects MUST be registered with the "Actor Profile" usage location in the OAuth Entity Profiles registry () 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"). defines interoperability requirements and implementation guidance for multi-value strings. 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.

The top-level cnf claim () carries the current presenter's binding; see Sender Constraint and Proof-of-Possession Validation. The client_profile claim defined in 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 object MAY reject the token or ignore the offending member; it MUST NOT treat that member as a valid actor classification. 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 preserves a validated delegation chain copies unrecognized extension members in inherited act objects unchanged, as Preserve Inbound Chain requires.

Delegation Chains Delegation chains MUST use nested act objects as specified in . The outermost object identifies the immediate actor; the innermost object identifies the first actor authorized by the subject. The chain records prior actors under the conveying issuer's trust, without independently proving each hop. This profile defines one linear chain per token; concurrent delegations use separate tokens. This document uses the following terms:

A hop is a single act object in a delegation chain. The number of hops in a chain equals the chain's delegation depth.
A visible hop is a hop that appears in the token's act chain as received by a recipient, after any filtering by an introspection server.
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.

The following example shows a delegation chain of depth 2: In this example, Alice (sub) authorized the travel assistant (inner act), which delegated to the booking tool (outermost act). The booking tool is the current presenter. Delegation depth is the number of act objects in the chain, counting from the outermost. 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 for cross-domain multi-hop use SHOULD support at least depth 4, and should document their maximum. Same-domain deployments can use a shallower maximum when it 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 as an invalid input under the applicable token-processing rules; AS and TTS errors follow Error Responses. When a request would add an actor beyond that limit, the AS MUST reject the request with the invalid_request error code; it MUST NOT silently truncate the chain. 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 subject has authorized the actor to do so. The following conditions establish this:

A validated actor_token identifying a distinct actor was present in the exchange request that produced this token.
An inbound subject_token from a trusted upstream issuer already carried an act chain, or the state of a refresh token presented as subject_token records one, establishing that delegation was present before the current exchange.
The issuing AS has an independent delegation basis such as a pre-registered grant, an explicit consent record, a may_act claim in a validated upstream token (see may_act), 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 for the outside-Token-Exchange case). In Token Exchange, such a basis applies only to an actor established as the next paragraph describes.

In Token Exchange, an independent delegation basis can authorize an actor established under this profile's processing rules but cannot by itself establish a new actor. A new actor is established from a validated actor_token or, at an AS other than a TTS, from the authenticated client on the may_act path without actor_token. Existing delegation is preserved under presenter continuation (Presenter Transition Model). A Token Exchange that establishes no new actor and has no inbound act chain does not represent delegation. When a token represents delegation, the act claim MUST be present and MUST conform to Actor Object Structure. When none of these conditions holds, the token does not represent delegation and the act claim MUST be omitted. The AS MUST NOT include the act claim 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.

Delegation Chain Validation and Construction An AS MUST apply this algorithm on paths that require or claim actor-profile conformance. The invoking grant, Token Exchange, or TTS rules supply token-specific preconditions and delegation-authorization requirements. Nonconforming actor objects, including those missing iss, MUST NOT enter this algorithm; Migration and Adoption defines their handling. Interoperable processing under this profile is defined around sub and the outermost act.sub. Inner actors are prior-actor context: preserved for audit and downstream use, and not inputs to access-control decisions, including scope determination, because prior actors identified by nested act objects are informational only (). Structural rules, such as the depth limit and the actor object requirements, still apply to every actor object.

Validation Steps The AS applies the validation steps in the following order:

Validate the carrier token using Validate Carrier Token.
Validate the outermost actor using Validate Outermost Actor.
Treat inner actors as prior-actor context using Carry Prior-Actor Context.
Enforce the configured maximum chain depth using Enforce Depth Limit.

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.

Validate Outermost Actor For the outermost act object, the AS MUST:

Verify that both act.sub and act.iss are present. If either is absent, reject the input under Error Responses.
Verify that local policy trusts the token issuer to assert (act.iss, act.sub); otherwise, reject the input under Error Responses. Trusting Actor Identifier Pairs gives examples of this deployment-specific trust decision.
Evaluate delegation under local policy:
- When extending the chain, the AS MUST confirm that the new actor is authorized to act for sub, for example through a grant, consent record, or policy rule.
- When preserving a validated chain from a trusted issuer, the AS SHOULD evaluate the preserved relationship. Upstream evaluation suffices for baseline interoperability.
- If a required relationship is prohibited or cannot be confirmed, reject the input with the actor_unauthorized error code.

Authorization Grant Processing adds requirements for JWT assertion grants.

Carry Prior-Actor Context For inner act objects, which are prior-actor context, the AS MAY rely on trust in the outer token issuer established by Validate Carrier Token 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.

Enforce Depth Limit Compute the depth of the resulting chain, including any new outermost actor added by Extend Chain with New Actor. If that depth exceeds the locally configured maximum (Delegation Chains), reject under Error Responses, distinguishing an excessive inbound chain from an extension that would exceed the limit.

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

If a new actor is identified for the issued token, use Extend Chain with New Actor.
Otherwise, if a validated inbound delegation chain is present, use Preserve Inbound Chain.
Otherwise, use Omit act.

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. The AS MUST set the new actor's act.iss and MUST NOT change any inherited actor field. It MUST preserve the entire inbound chain; Enforce Depth Limit rejects a resulting chain that exceeds the local maximum. If the new actor has the same (act.iss, act.sub) pair as the inbound outermost actor, the AS MAY instead apply Preserve Inbound Chain to avoid a duplicate entry. This profile does not standardize 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). An AS MAY apply local policy to such cases; the chain-construction algorithm itself neither requires nor prohibits cycle detection.

Preserve Inbound Chain When no new actor is identified and an inbound chain is present, the AS copies the validated inbound chain unchanged. 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 delegation chain.

Omit act When no delegation is present and no actor information should appear in the issued token, the AS omits act, as required by Delegation Chains. 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.

Sender Constraint and Proof-of-Possession Validation The rules in this section apply to all supported token types, in addition to their type-specific proof-of-possession (PoP) requirements. Presenter Transition Model defines continuation and rebind for Token Exchange. DPoP nonce handling follows unchanged. Per-actor confirmation members and prior-hop key provenance are outside the scope of this document; see Companion Profiles and Extension Points.

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 () is used, the top-level cnf.jkt MUST identify that party's key; when mTLS () 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. A confirmation member such as act.cnf is permitted as extension data under Actor Object Structure and has no proof-of-possession semantics under this profile. It remains unchanged in an inherited actor object under Preserve Inbound Chain. After further delegation, an inherited confirmation value can therefore differ from the current token's top-level cnf claim; this profile imposes no equality check between them.

Token Exchange Continuation Presenter continuation requires either a PoP-capable subject_token with a top-level cnf claim or a bearer subject_token presented by an authenticated requester that corresponds, under Identifier Reconciliation (Conventions and Definitions), to the token's outermost (act.iss, act.sub) pair, or to its sub when the token carries no act claim. For a PoP-capable subject_token, the requester MUST prove possession of its binding using the mechanism applicable to the token type and deployment. A bearer continuation yields a bearer output.

Token Exchange Rebind Presenter rebind requires a validated actor_token whose top-level sub identifies the new presenter, as specified in Actor Tokens, except on the may_act path without an actor_token, where the authenticated client is the new presenter.

The issuer validates the credential per and MUST validate any proof required by its profile or deployment, whether or not the output token is sender-constrained.
When the output token is sender-constrained, the issuer MUST validate proof of possession for the new presenter. A bearer output does not waive validation of the credential or of any proof its profile requires. A sender-constrained subject_token does not, by itself, require proof for its prior presenter during rebind.

Other actors that become presenters therefore need a direct credential: a workload identity credential, a JWT client assertion, or a non-delegated JWT access token.

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 a top-level cnf claim in the subject_token imposes no continuity obligation in this case.

JWT Assertion Grants

Structure These requirements apply to JWT authorization grants under and , including ID-JAG . The grant profile defines issuance and exchange; this document defines actor representation and delegation processing. A JWT authorization grant MAY carry an act claim conforming to Actor Object Structure. Actor claims in JWT client authentication assertions are outside the scope of this document. The act claim represents explicit delegation, even when the issuer derives the actor from authenticated client context, as on the may_act path. The following claims are defined for a JWT assertion grant that carries actor-profile delegation. Claims not listed here follow the requirements of and .

iss (REQUIRED):: Identifies the assertion issuer. MUST be authorized by local policy to assert the relationship between sub and act.sub.
sub (REQUIRED):: Identifies the principal on whose behalf the grant is made.
jti (REQUIRED):: Identifies the assertion for replay prevention (Authorization Grant Processing).
sub_profile (RECOMMENDED):: Classifies the entity type of sub. MUST conform to .
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.
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 when DPoP is used, or cnf.x5t#S256 per when mTLS is used. When the assertion is not sender-constrained, a top-level cnf claim is OPTIONAL unless another profile or local policy requires it.

Before sending JWT assertion grants carrying actor-profile claims, a client needs to confirm that the AS supports the actor-determination model through deployment documentation, prior agreement, or discovery; for ID-JAG, that includes support for 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, which presented its client assertion as actor_token, confirmed the delegation relationship under local policy, and signed the assertion. Here, act.iss equals the assertion's iss because the enterprise AS's issuer identifier is also the actor identifier context for the agent: The top-level sub_profile classifies the assertion's sub; the sub_profile within act classifies the actor. The top-level cnf.jkt binds the assertion to the agent's DPoP key. In this example, the receiving AS trusts the enterprise AS both to issue the grant and to assert the actor identifier pair. This document defines two issuer patterns:

an AS-issued delegated assertion, where the assertion's 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.

For actors registered in the issuing AS's own namespace, act.iss (Actor Object Structure) is often the AS's own issuer URI. 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 interoperable scope of this document. Implementations MUST reject self-issued assertion grants by default; see Self-Issued Authorization Grants for the security controls any such deployment needs to establish independently.

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

The AS MUST validate the assertion per , including its signature and its iss, sub, aud, exp, and jti claims.
- Grants without an enforced grant-level sender constraint: The AS MUST reject with invalid_grant an assertion whose validated (iss, jti) pair it has already accepted, for as long as the assertion remains acceptable, including any allowed clock skew. Such a grant is therefore single-use under this profile, including an ID-JAG that would let a client re-submit. A proof used only for client authentication or to bind the issued token is not a grant-level sender constraint, and neither is a top-level cnf that presenter rebind supersedes (JWT Assertion Grant as subject_token).
- Sender-constrained grants: When the AS validates the request's proof of possession against the assertion's top-level cnf claim as specified in step 6, the AS SHOULD additionally apply replay prevention to the validated (iss, jti) pair as defense in depth. Any permitted reuse requires validation of that binding on each redemption and remains subject to the single-use requirements in Self-Issued Authorization Grants or the applicable grant profile.
The AS MUST verify that the assertion's iss is trusted under local policy to assert delegation on behalf of the actor identified by act.sub.
The AS MUST verify that the assertion's iss is trusted under local policy to assert the (act.iss, act.sub) actor identifier pair.
- If act.iss is absent: when policy or metadata requires profile conformance, reject with invalid_grant; otherwise, apply Migration and Adoption.
- If the assertion's iss is not trusted to assert the actor identifier pair: reject with invalid_grant.
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:
- 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, an explicit consent record, or a 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.
If the inbound assertion's act object contains a nested act object (indicating that the asserted actor is itself a delegatee), the AS MUST handle the inner chain as follows:
- Propagation decision: The AS SHOULD propagate the inner chain by preserving its nested structure, provided the resulting chain depth does not exceed the limit in Delegation Chains. If the AS does not accept pre-chained assertions, it MUST reject the request.
- Prior-actor context: For inner act objects, Carry Prior-Actor Context applies.
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.
- DPoP: When the inbound assertion grant is DPoP-bound, it MUST carry a top-level cnf.jkt; reject with invalid_grant if absent. The AS MUST:
  - Verify that the DPoP proof is valid per with htm="POST" and htu equal to the AS token endpoint URI.
  - Verify that the JWK SHA-256 thumbprint of the public key in the DPoP proof matches the assertion's cnf.jkt (), as in the proof checks of .
  - Use the assertion's cnf.jkt as set by the upstream issuer; MUST NOT substitute a locally registered key.
  - Reject with invalid_grant if the required proof is absent, as specified for ID-JAG in . If a valid proof's key does not match the assertion's cnf.jkt, reject with invalid_grant.
  - Reject with invalid_dpop_proof if a supplied proof is invalid, subject to the nonce challenge rules of .
  - Note: The ath claim is not applicable at the token endpoint and MUST NOT be required. See also 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_grant 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 with invalid_grant if the presented certificate does not match cnf.x5t#S256.
- 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 and Sender Constraint and Proof-of-Possession Validation, not by the contents of nested act objects. In presenter rebind, the AS does not perform this step's match against the grant's top-level cnf claim (JWT Assertion Grant as subject_token).
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.
- The AS SHOULD NOT infer that the client is authorized to act on behalf of the subject solely because the client initiated the request.
- 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 treats the identifiers as distinct and rejects the request when issuance requires them to identify the same entity, as defined for Identifier Reconciliation in Conventions and Definitions.
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. For JWT access tokens, see JWT Access Token Output. For Transaction Tokens, see Transaction Token Output Rules. 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.

JWT Access Tokens

Structure A delegated JWT access token is a JWT access token per that carries an act claim conforming to the actor profile defined in Actor Profile for Delegation. Claims not listed here follow 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.
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 .
act (REQUIRED when the token represents delegation per Delegation Chains):: 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.
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 (REQUIRED):: Identifies the OAuth client that requested the token, per . It does not substitute for act; see Client Identity and Delegation.
azp (OPTIONAL):: An additional client identifier used by some deployments. It does not substitute for act; see Client Identity and Delegation.

If an issuer uses azp and act.sub to identify the same party, Client Identity and Delegation defines their reconciliation, along with the other common rules; Migrating from Implicit to Explicit Delegation describes rollout. The following is an example of a JWT access token with actor-profile claims: The top-level cnf.jkt binds this token to the actor's DPoP key. The client and actor identifiers illustrate different namespaces; any equivalence depends on trusted local mappings.

Delegated Token Issuance When an AS issues, outside Token Exchange, a JWT access token whose delegation rests on an independent delegation basis (Delegation Chains), 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 supply that basis only if it uniquely identifies one acting entity and the AS can derive the actor identifier from the registration alone. A registration shared by several actors does not satisfy this condition. For the authorization code grant, the AS MAY include the act claim when an independent delegation basis, such as authorization state, registration, consent, or local policy, establishes that the OAuth client is acting as a distinct actor for the resource owner. The actor identity MUST derive from that delegation basis. Without such a basis, the AS MUST NOT include act. An AS that issues a refresh token together with a token carrying act MUST record that chain for the grant. For the refresh_token grant (), the AS MUST carry the act chain recorded for the grant into the refreshed token unchanged or reject the request; it MUST NOT issue a refreshed token without that chain. This document defines no actor-selection or actor-proof parameter for the authorization code grant; actor determination there is deployment-specific.

Token Exchange Processing This section defines input processing for Token Exchange and the issuance of JWT assertion grants and JWT access tokens. Transaction Token Service Processing defines Transaction Token issuance. Error Responses applies to all paths in this section. 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). Client assertions per (JWT Client Assertion) and workload identity credentials (Workload Credential Processing) both use actor_token_type=urn:ietf:params:oauth:token-type:jwt. For JWT actor_token inputs, the AS identifies the credential profile as follows:

A JWT also presented as client_assertion with a client_assertion_type of urn:ietf:params:oauth:client-assertion-type:jwt-bearer is a client assertion when its sub equals the authenticating client's client_id.
A JWT actor_token not presented as client_assertion is a client assertion when its iss and sub both equal the authenticated client's client_id ().
If sub differs from client_id, the AS MUST NOT classify the JWT as a client assertion solely because it appears in client_assertion. It MUST apply workload identity credential processing if that profile matches, or reject with invalid_request.
If exactly one supported actor-credential profile cannot be identified, the AS MUST reject with invalid_request.
If client_assertion and actor_token are different JWTs, the AS MUST process each independently. These disambiguation rules apply only to actor_token.

Presenter Transition Model For PoP migration, this profile distinguishes two classes of subject_token input according to whether they carry presenter-continuity information; Input Processing classifies each input type. Identity-only inputs (ID Tokens and refresh tokens) establish sub and MAY establish supporting subject state such as sub_profile or an authorization ceiling. They do not establish presenter continuity. An ID Token establishes no inbound act state; a refresh token establishes it only from an act chain recorded in its state (Refresh Token). Neither input by itself justifies adding a new actor. Token-state inputs (JWT assertion grants, JWT access tokens, and 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 presenter continuation. A Token Exchange is delegated when it establishes a new actor or carries an inbound act chain, including one recorded in the state of a refresh token presented as subject_token (Delegation Chains). A delegated Token Exchange operates in exactly one of two presenter-transition modes:

Presenter continuation: neither a validated actor_token nor the may_act path without actor_token establishes a new presenter. The issued token retains the presenter of a token-state subject_token: the holder of its top-level cnf binding or, for a bearer subject_token, its authenticated outermost actor or subject, as Sender Constraint and Proof-of-Possession Validation requires.
Presenter rebind: a validated actor_token, or the authenticated client on the may_act path without 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.

A delegated request that satisfies neither mode MUST be rejected with invalid_request. A request that supplies an actor_token, or whose subject_token carries act, is processed as delegated; if that processing fails, the AS rejects the request and MUST NOT instead issue a token without act. The AS processes a request that is not delegated under and local policy, and a token issued for it omits act. Local policy can reject such a request with actor_unauthorized, for example when the client or resource requires explicit delegation. When a request that is not delegated presents a subject_token carrying a top-level cnf claim, the requester MUST prove possession of that binding, as in Token Exchange Continuation. Outside the may_act path without actor_token, presenter rebind requires a direct presenter credential: an actor_token whose top-level sub names the new presenter. Other means of establishing a presenter are outside this profile. Identity-only inputs cannot support continuation, and bearer inputs support only bearer continuation. To preserve a delegation chain while changing presenters, deployments SHOULD present the delegated credential as subject_token and a separate direct credential as actor_token. JWT assertion grants are not suitable for use as actor_token, because 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.

Input Processing When a Token Exchange request () presents a subject_token or actor_token of a type defined in this section, the AS MUST apply the following steps, using the input type's row in the tables below and the rules in its subsection. Steps 1 through 4 apply to each input; steps 5 and 6 apply to the issued token.

The AS MUST validate the input per the specification in its table row. If validation fails, the AS MUST reject the request with invalid_request (), unless the input's subsection or Error Responses specifies another error.
Where the table row gives an issuer-trust check, the AS MUST verify that the input's issuer is trusted under local policy as that row states. If not, the AS MUST reject the request with invalid_request.
The AS MUST apply Presenter Transition Model: for a delegated request, the continuation or rebind rules in Sender Constraint and Proof-of-Possession Validation, including any type-specific proof rule in the input's subsection. A token-state subject_token without a top-level presenter binding can still be used for presenter rebind.
The AS establishes inbound state as follows:
- From a validated JWT access token or Transaction Token subject_token, the AS MUST extract sub, sub_profile (if present), and act (if present) as the inbound delegation state for JWT Access Token Output. A validated JWT assertion grant establishes the same inbound state.
- An identity-only subject_token supplies no presenter continuity. A refresh token whose state records an act chain supplies that chain as inbound delegation state (Refresh Token); an ID Token supplies none. The AS establishes a new actor from a validated actor_token or from the authenticated client on the may_act path without actor_token; with neither a new actor nor inbound delegation state, the request is not delegated, and any token issued for it MUST omit act.
- For an actor_token, the AS MUST derive the outermost actor and handle any inbound chain as specified in Actor Tokens.
The AS can reduce scope under local policy. The effective scope of the issued token MUST NOT exceed the scope ceiling, if any, in the subject_token's table row.
The AS MUST then apply the propagation rules in JWT Access Token Output to determine the remaining claims in the issued token.

For subject_token inputs:

Input	Validated per	Issuer trust check	Scope ceiling
JWT assertion grant	Authorization Grant Processing	In validation	See subsection
JWT access token	, `aud` relaxed	Trusted for its delegation chain	Its effective scope
Transaction Token	Transaction Token specification	Trusted issuer	See subsection
ID Token	, local policy	No separate check	None
Refresh token	Token store or trusted back-channel	No separate check	Its authorized scope

For actor_token inputs, each of which establishes the outermost actor:

Input	Validated per	Issuer trust check
JWT client assertion		See subsection
Workload identity credential	Its type specification	Trusted for the workload's identity
JWT access token	, `aud` relaxed	Trusted for the acting party's identity

Subject Tokens SAML assertions are outside the scope of this document.

Token-State Subject Tokens

JWT Assertion Grant A JWT assertion grant presented as subject_token establishes sub and, when present, sub_profile, inbound act chain state, and top-level cnf, and is processed under Input Processing with the following rules. Validation applies the inbound validation rules of Authorization Grant Processing to the grant; assertion-grant output construction from that section does not apply. On this Token Exchange path, a failure that section rejects with the invalid_grant error code is rejected with the invalid_request error code instead (). In presenter continuation, step 6 of Authorization Grant Processing applies. In presenter rebind, the new presenter's binding supersedes the grant's: the AS does not perform step 6's match of the request's proof against the grant's top-level cnf, and it treats the grant as having no enforced grant-level sender constraint, so the (iss, jti) single-use rule in step 1 of Authorization Grant Processing applies. The AS still validates any proof that the new presenter's credential profile or the deployment requires, as the rebind rules specify. The grant's scope ceiling is its scope claim when present (such as the ID-JAG scope claim of ), otherwise the scope the AS would authorize if the grant were redeemed directly under Authorization Grant Processing.

JWT Access Token A JWT access token presented as subject_token (subject_token_type=urn:ietf:params:oauth:token-type:access_token) establishes sub and, when present, sub_profile, inbound act chain state, and top-level cnf, and is processed under Input Processing with the following rules. Validation follows for its typ header, signature, iss, and exp, and for nbf when present; the token carries the sub and jti claims that requires. Because a JWT access token used as subject_token was issued for a resource server, its aud does 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.

Transaction Token A Transaction Token presented as subject_token (subject_token_type=urn:ietf:params:oauth:token-type:txn_token) establishes sub and, when present, sub_profile, inbound act chain state, and a top-level presenter binding. The AS or TTS receiving it MUST apply steps 1 through 4 of Input Processing with the following rules; steps 5 and 6 apply when the output is a JWT access token or a JWT assertion grant, and for a Transaction Token output, Transaction Token Output Rules apply instead. Validation per covers the signature, aud, exp, and issuer identity:

When the Transaction Token carries act, a top-level iss claim MUST be present, and the AS MUST validate it as the token issuer. If iss is missing, the AS MUST reject the request with invalid_request.
When the Transaction Token carries neither act nor iss, the AS MUST determine the issuer through the Transaction Token trust-domain rules and local configuration.
If validation fails or the issuer cannot be established, the AS MUST reject with invalid_request.

In step 3, the AS uses the presenter-proof mechanism defined by the deployment profile; defines none. The req_wl claim identifies the workload that requested the Transaction Token from the TTS. For a JWT access token output, the AS MAY use req_wl for audit or local policy decisions but MUST NOT carry it forward into the issued JWT access token. The scope ceiling is the authority the Transaction Token represents; when the AS cannot determine that authority in the output's scope vocabulary, it MUST reject the request with invalid_scope, as requires of a TTS. Other Transaction Token field semantics remain defined by , , and local policy.

Identity-Only Subject Tokens

OpenID Connect ID Token

Overview An OpenID Connect ID Token presented as subject_token (subject_token_type=urn:ietf:params:oauth:token-type:id_token) establishes subject identity only. It identifies an authenticated user in sub and the relying party in aud (and possibly azp); the acting party comes from actor_token, and aud and azp remain client identifiers.

Processing The AS MUST verify that the ID Token's aud contains a value that identifies the authenticated client under Identifier Reconciliation (Conventions and Definitions), as requires for an ID-JAG. It MUST reject the request with invalid_request when the client is not authenticated or no aud value identifies it. These checks on aud and azp remain OpenID Connect and client-identity checks; they do not by themselves establish the delegated actor under this profile. 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. 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. Because an ID Token carries no OAuth scope ceiling, scope determination comes from the actor_token (if any), , and local policy.

Refresh Token

Overview A refresh token presented as subject_token (subject_token_type=urn:ietf:params:oauth:token-type:refresh_token) establishes sub, an authorized scope, and any act chain recorded for its grant, which the AS obtains from trusted server state rather than by extracting actor claims from the token. A refresh token MAY be used as subject_token when the AS can validate its state directly or through a trusted back-channel to its issuer. It MUST NOT be treated as a portable cross-domain delegation artifact or used as actor_token. Client binding, cross-client presentation, and cross-AS acceptance policies remain deployment-specific.

Processing The AS validates the refresh token through its token store or a trusted back-channel to its issuer; signature validation alone is insufficient, and an expired, revoked, or otherwise invalid token fails validation. For a token issued by another AS, the AS MUST NOT accept it unless that back-channel provides the subject, client binding, authorized scope, revocation state, and any act chain recorded for the grant. 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_request. 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. Whether an AS issues refresh tokens for delegated JWT assertion grant requests, how it revokes them, and whether their later use requires re-presenting upstream delegation artifacts remain deployment-specific. On Token Exchange, a refresh token subject_token establishes no new actor. When the refresh token's state records an act chain, the AS MUST treat that chain as inbound act state: the request is delegated, an identity-only input cannot use presenter continuation, so the request requires presenter rebind (Presenter Transition Model), and the AS MUST NOT issue a token without that chain.

Actor Tokens The following rules apply to every actor_token type in this section:

The credential MUST identify the acting party in its top-level sub. If it carries act, the AS MUST reject with invalid_request.
After validating the credential, the AS MUST use its sub as the new outermost act.sub and set act.iss to that identifier's namespace context: for a JWT client assertion, the issuer identifier of the AS at which the client is registered; for a workload identity credential, its iss, or its trust domain when iss is absent; for a JWT access token, its iss.
If the subject_token carries a chain, the new actor takes precedence over its outermost actor. Different identities are permitted for presenter rebind. Local policy MAY require equivalence on paths that only confirm an existing actor; when such a restriction applies and no trusted mapping establishes equivalence, the AS MUST reject with invalid_request.

Delegation Chain Validation and Construction governs nesting of the subject_token chain. Deployments supporting sub-delegation SHOULD provision each potential presenter with a direct credential naming itself in sub.

JWT Client Assertion

Overview A JWT client assertion per presented as actor_token establishes an OAuth client's own identity as the acting party. Per and , the assertion has iss = sub = client_id and is signed with the client's private key. Two usage patterns arise:

A single client assertion is presented as both client_assertion and actor_token, making the authenticated client explicit in the issued token's act chain.
The client authenticates by another method (for example, client_secret or mTLS) and presents a separate client assertion naming itself as actor_token.

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), whose sub names that distinct principal.

Processing If validation of the client assertion per fails and the actor_token is also used as client_assertion for client authentication in the same request, the AS MUST reject the request with invalid_client; if that validation fails otherwise, the AS MUST reject the request with invalid_request. The AS MUST verify that the client assertion'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_request. 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 after successful client authentication follow Error Responses, including actor_unauthorized for actor-authorization denials.

Workload Identity Credential

Overview A workload identity credential is a JWT whose sub identifies a software workload, such as a service or agent; presented as actor_token, it establishes that workload as the acting party. WIMSE credentials are defined in . 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

Processing For WIMSE workload identity credentials (), validation follows the rules defined in that specification. The issuer is identified by iss or, for a WIMSE credential without iss (), by the trust anchors configured for the trust domain of its sub (). The AS MUST validate any proof the workload-credential profile requires, such as a WIMSE Workload Proof Token (WPT, ) per its specification, whether or not the output token is sender-constrained. When the request uses this credential to establish a sender-constrained output token in presenter-rebind mode, the AS MUST also validate proof for the new presenter binding: the WPT, or a DPoP proof () over the token endpoint URI whose key is the confirmation key in the credential's cnf claim (cnf.jwk for a WIMSE credential). If a required proof is absent or invalid, the AS MUST reject under Error Responses, using the proof mechanism's error when specified and invalid_request otherwise.

JWT Access Token

Overview A non-delegated JWT access token presented as actor_token establishes 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.

Processing Validation per applies the aud relaxation in JWT Access Token as subject_token. A JWT access token without top-level cnf is accepted as actor_token only when its sub corresponds to the authenticated client under Identifier Reconciliation (Conventions and Definitions); otherwise, the AS MUST reject the request with invalid_request. When the credential carries top-level cnf, the AS MUST validate proof for that binding per Sender Constraint and Proof-of-Possession Validation, whether or not the output token is sender-constrained.

may_act The may_act claim () 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 without a separately pre-registered grant. The may_act claim is never itself the source of actor identity, and it MUST NOT be propagated into any output token. Two preconditions apply regardless of how the Token Exchange request is structured:

The subject_token issuer is trusted under local policy to assert may_act on behalf of the subject.
The canonical may_act identifier matches the derived actor identity under Identifier Reconciliation (Conventions and Definitions).

The canonical may_act identifier is (may_act.iss, may_act.sub) when may_act carries iss, and (subject_token.iss, may_act.sub) otherwise. The AS MUST apply configured mapping rules and MUST NOT infer equivalence from naming similarity alone. If may_act.iss is present but is not a valid StringOrURI, the AS MUST NOT use that may_act claim to authorize delegation and MUST NOT fall back to subject_token.iss. Actor identity is established as follows:

With actor_token: the AS derives (act.iss, act.sub) under the credential's type-specific rules and reconciles that pair with the canonical may_act identifier. The may_act claim MUST NOT override the derived actor.
Without actor_token: the requesting client MUST be a confidential client that has authenticated in the request; public clients MUST NOT use this path. The AS reconciles the authenticated client with the canonical may_act identifier and sets act.sub to the client's canonical identifier. The AS MUST set act.iss to the issuer or namespace context that locally registered the client, typically the AS's own issuer URI. The authenticated client is then the new presenter in presenter-rebind mode (Presenter Transition Model), and a sender-constrained output is bound to the key or certificate the client demonstrates in the request.

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

Output Token Rules

JWT Assertion Grant Output When requested_token_type requests a JWT assertion grant, the output MUST satisfy JWT Assertion Grant Structure. Supported type identifiers include urn:ietf:params:oauth:token-type:jwt and compatible profiles of that type, such as urn:ietf:params:oauth:token-type:id-jag . The AS MUST:

Construct the chain per JWT Access Token Output.
Set aud from the request or deployment configuration: for an ID-JAG, to the Resource Authorization Server's issuer identifier (); otherwise, to a value identifying the downstream authorization server that permits, such as its token endpoint URL.
Sign the assertion, per .

Issuing such a grant is subject to AS configuration and, when the grant carries act, to Validate Outermost Actor.

JWT Access Token Output When the output is a JWT access token, the issued token MUST satisfy JWT Access Token Structure. After the applicable grant, subject-token, actor-token, or TTS input processing, the AS MUST apply the rules below. For a sender-constrained output of a delegated Token Exchange request, the AS MUST set the top-level cnf claim according to Presenter Transition Model: retain the presenter's binding in continuation mode, or bind to the new presenter in rebind mode. For any other request, the applicable grant or token specification and its proof mechanism govern that binding, such as for an ID-JAG. 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_request. 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 token in place of the requested delegated output.

The AS includes or omits act as required by Delegation Chains, and does not silently drop inbound actor information (Omit act).
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 describes subject-namespace translation requirements and relying-party consequences.
The AS MUST construct the act claim using the construction decision order in Delegation Chain Validation and Construction: extend with a new actor, preserve an existing chain, or omit act, in that order. An actor derived from actor_token is asserted by the issuing AS; consumers MUST NOT infer that it was present in the subject_token or endorsed by its issuer.
The AS MUST reject the request if actor validation fails or the resulting chain exceeds the depth limit, using Error Responses. It MUST NOT issue a partially preserved chain.
Top-level sub_profile follows Actor Object Structure, which recommends it when the AS can authoritatively classify the token's sub entity type. When the AS carries a trusted inbound top-level sub_profile into the issued token, it MUST preserve its unrecognized but syntactically valid values.
The AS can reduce scope under local policy. If this reduction, before any actor-based restriction, leaves no effective scope, it MUST reject with invalid_scope. If the AS also restricts scope using the (sub, act.sub) pair or act.sub_profile, it MUST return the final effective scope in the token response. If this restriction leaves no scope, the AS MUST reject:
- with actor_unauthorized when the actor is categorically unauthorized for the remaining scope, for example because its entity type is prohibited;
- with invalid_scope for other causes, such as an actor scope ceiling that excludes the requested values.
The AS MAY preserve inbound client identifiers per the output token profile or local policy. Preserved values MUST retain their client-identity meaning; they do not represent delegation state (Client Identity and Delegation). If preserving an optional identifier would create ambiguity about the delegated actor relationship, the AS SHOULD omit it. JWT access tokens still require client_id per .
On a Token Exchange request, the AS MUST issue the token for every requested audience and resource or reject the request with invalid_target (), unless the requested token type's specification permits a subset, as does for an ID-JAG's resources. On other grants, resource indicators follow .

Transaction Token Service Processing

Transaction Tokens 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. A TTS, which is a specialized authorization server, issues them. Transaction Token claims are defined in . This profile modifies or adds the following claims:

iss (OPTIONAL in ; REQUIRED by this profile when the token carries act):: Identifies the Transaction Token issuer. It MUST be present when the token carries act. It MAY be omitted only when the token carries no act and all recipients know the issuer out of band. In that case, recipients MUST identify the issuer using and local configuration.
req_wl:: This claim provides TTS-level workload context and is not a substitute for act.sub; see Actor Claim in Transaction Tokens.
act (REQUIRED when the token represents delegation per Delegation Chains; omitted otherwise):: Represents the current acting party and any prior delegation steps, and conforms to Actor Object Structure. See Actor Claim in Transaction Tokens for delegation semantics and the relationship between act.sub and req_wl.

Actor Claim in Transaction Tokens Under this profile, a Transaction Token represents delegation when a condition in Delegation Chains holds, that is, when an actor_token or an inbound act chain establishes that the workload acts for sub. When no such condition holds, including when a workload acts under its own grant without any delegation basis, the token omits act. The TTS MUST NOT infer delegation solely because sub and req_wl differ. The req_wl claim identifies the workload that requested the token from the TTS. The act.sub claim identifies the immediate acting party in the subject identifier namespace used by this profile. The outermost act.sub is the authoritative actor identifier for authorization decisions under this document; req_wl is supporting workload context. Claim semantics under this profile:

sub: identifies the original initiator. A replacement Transaction Token keeps sub unchanged ().
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 that they identify the same entity under local policy. In presenter-continuation mode, req_wl identifies the requesting workload (), which step 5 of Transaction Token Output Rules requires to correspond to the outermost actor. A recipient that relies on both to identify the current presenter requires them to identify the same entity and therefore rejects the token when it cannot reconcile them (Conventions and Definitions).
Inner act objects: identify prior presenters in the delegation path. At each level, act.sub_profile classifies the entity type of that presenter.

The following example shows a Transaction Token after two hops: The booking tool is the current presenter, identified by req_wl and the outermost act.sub and bound to the top-level cnf.jkt. The inner actor records the travel assistant's prior participation.

Presenter Authentication and Transition For a delegated request, the TTS applies the same two presenter-transition modes defined in Presenter Transition Model, but only for token-state subject_token inputs; that section also governs a request that is not delegated:

Presenter continuation: the authenticated requester is the same current presenter as the inbound token. When the inbound token carries a top-level presenter binding, the TTS validates proof for that binding under the applicable deployment profile, because defines no presenter-proof mechanism; a bearer inbound token yields a bearer Transaction Token, as in Sender Constraint and Proof-of-Possession Validation. 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 that is a direct presenter credential establishes the 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.

Through presenter rebind with a validated actor_token, the TTS can upgrade a bearer input to a sender-constrained Transaction Token, as in Sender Constraint and Proof-of-Possession Validation.

Supported Subject Tokens This profile defines TTS processing for whichever of the following inputs a TTS supports: JWT assertion grants, JWT access tokens, and Transaction Tokens. This document does not define TTS processing of ID Tokens or refresh tokens. For each accepted input, the TTS MUST apply the rules listed for it in the referenced sections:

Input	Rules applied	Section
JWT assertion grant	Validation and presenter continuity	Input Processing; JWT Assertion Grant as subject_token
JWT access token	Validation and extraction	Input Processing; JWT Access Token as subject_token
Transaction Token	Validation and extraction	Input Processing; Transaction Token as subject_token

The resulting state (subject, classification, chain, and binding) is input to Transaction Token Output Rules instead of to JWT access token issuance. For an inbound Transaction Token, the TTS maintains the call chain of requesting workloads as requires, and the issued token's req_wl identifies the workload that requested it (). The scope claim of a Transaction Token can use a different vocabulary from that of the inbound token (), so the literal scope-subset rules of Input Processing step 5 do not apply. The TTS still ensures that the requested scope does not exceed the authority of the subject_token () and rejects the request with invalid_scope when that authority cannot be determined (). A replacement Transaction Token cannot expand the scope of permitted actions ().

Transaction Token Output Rules The TTS applies Delegation Chain Validation and Construction and JWT Access Token Output, except its JWT access token structure requirement and its step 6, with the Transaction Token adaptations below. Transaction Token scope follows Supported Subject Tokens. 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, it MUST apply the following rules; steps 3 through 6 apply only when the request is delegated (Presenter Transition Model), including when an actor_token establishes delegation for an inbound token without act:

The TTS preserves sub from the inbound token, as step 2 of JWT Access Token Output requires.
- For an inbound JWT access token or JWT assertion grant, the TTS can 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). For an inbound Transaction Token, the replacement token keeps sub unchanged ().
The req_wl claim and any Transaction Token claims other than actor-profile claims remain governed by 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.
The TTS applies Enforce Depth Limit to the act chain that results from step 6.
The TTS validates the inbound token and establishes issuer trust (Validate Carrier Token) before preserving or extending any act chain. For the outermost act object in the inbound chain, the TTS applies Validate Outermost Actor, treating presenter rebind as extending the chain and presenter continuation as preserving it. For inner act objects in the inbound chain, Carry Prior-Actor Context applies.
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 the invalid_request error code. If local policy prohibits the preserved actor relationship, the TTS MUST reject the request with actor_unauthorized.
- Presenter rebind: The TTS MUST validate a direct presenter actor_token for the new presenter under Actor Tokens. 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 the presenter-continuation nor the presenter-rebind requirements, the TTS MUST reject the request with the invalid_request error code.
When the issued Transaction Token carries delegated actor information, it includes the top-level iss claim required by Transaction Tokens, identifying the TTS as its issuer, and the TTS MUST construct the act claim using Delegation Chain Validation and Construction. In summary:
- in presenter-continuation mode, preserve the inbound chain unchanged (Preserve Inbound Chain);
- 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).
When the issued Transaction Token includes a top-level presenter-binding claim such as cnf, that binding applies to the current presenter. Requester authentication follows ; the applicable deployment profile, not this document, defines the proof mechanism for that binding, because defines none.

This document does not define TTS-specific may_act processing. A deployment MAY use it as an authorization hint under local policy or another specification, but it MUST NOT replace credential validation, presenter authentication, or the rules in this document that govern whether a new outermost act is created.

Resource Server Processing

Actor Authorization When a token contains both a sub claim 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, or a permission).
Actor principal (act.sub): the party making the immediate request. This principal can differ from the subject in organizational domain and trust level. Wherever this document pairs sub with the outermost act.sub for authorization policy, the outermost actor is identified by its (act.iss, act.sub) pair (Actor Object Structure).

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 substitute for act.sub. Under this profile, actor authorization is conditional. 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. Whether or not it requires actor authorization, the RS SHOULD evaluate the (sub, outermost act.sub) pair according to local policy for authorization, audit, or trust decisions. For security-sensitive delegated access, the RS SHOULD enforce authorization of the (sub, outermost act.sub) pair on every request. 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:

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). An RS MAY still apply actor authorization without advertising it, but clients cannot rely on that behavior.
Evaluate subject authorization: Determine whether sub has been granted the requested scope or permission, using the same mechanisms applied to non-delegated tokens.
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.
Evaluate combined policy: Apply resource-specific actor authorization policies (e.g., requiring both principals to have agreed to terms of service).
If the RS requires actor authorization but cannot complete it, it MUST reject the request.

Nested actors are not inputs to actor authorization ().

JWT Access Token Processing On a request path where delegated-token processing may apply, an RS MUST validate and process JWT access tokens according to its delegated-token policy. A conforming act claim identifies a delegated token; the RS MUST NOT infer delegation from client_id, azp, or other client-identity claims alone. Protected Resource Metadata advertises delegated-token expectations; enforcement remains the responsibility of the RS. When the resource server evaluates a JWT access token as a delegated token under local policy, it MUST:

Validate the typ header, signature, iss, aud, and exp per and other temporal claims per , and reject a token whose visible act chain exceeds the configured maximum depth (Delegation Chains). If the request path requires actor-profile conformance, including through actor_profile_required: true:
- A token evaluated as delegated MUST carry act, and every actor object in the visible act chain MUST include iss. Otherwise, reject the token with HTTP 401 and error="invalid_token". This is structural validation, not independent authentication of historical actors.
- Non-delegated tokens need not carry act.
If the token carries a top-level cnf.jkt, validate the accompanying DPoP proof per . If the token carries a top-level cnf.x5t#S256, validate the client certificate of the mutual-TLS connection against it per . If a DPoP proof is present but the token carries neither cnf.jkt nor cnf.x5t#S256, the RS MUST treat the token as a bearer token; the RS MUST NOT infer a confirmation binding from the DPoP proof key.
Extract sub and the outermost act.sub as the two principals relevant for authorization policy.
If the token carries client_id, azp, or both, treat them as client-identity inputs only. The actor identifier is then act.sub, not client_id or azp. When local policy expects both to identify the same acting party, the RS SHOULD perform identifier reconciliation; if reconciliation cannot be established, the RS treats them as distinct and rejects the request when its authorization decision requires them to identify the same party, as defined for Identifier Reconciliation in Conventions and Definitions. See Client Identity and Delegation.
Apply actor authorization per Actor Authorization when required by local policy or when the token is accepted as satisfying a delegated-access requirement for the request path.
The RS MAY traverse inner act objects for audit. They are not inputs to access-control decisions ().
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 for bearer or mTLS-bound () tokens, or DPoP per for DPoP-bound tokens.
- If signature, iss, aud, temporal, or depth validation fails: HTTP 401 with error="invalid_token".
- If identifier reconciliation that the authorization decision requires fails (step 4): HTTP 403 with error="actor_unauthorized".
- If DPoP proof validation for cnf.jkt fails: HTTP 401 per .
- If the client certificate does not match cnf.x5t#S256: HTTP 401 with error="invalid_token", per .
- If actor authorization required by local policy fails for a structurally valid token: HTTP 403 with error="actor_unauthorized", registered in OAuth Error Registry. The RS MUST NOT use the insufficient_scope error code for this failure, because requesting broader scope does not resolve an actor-policy denial.
- The RS MUST NOT expose actor-specific rejection details outside the trust domain.

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

Validate the signature, audience, temporal claims, and issuer under and the deployment profile:
- If the token carries act, the top-level iss claim MUST be present, and the RS MUST validate it as the token issuer.
- If the token carries neither act nor iss, the RS MUST determine the issuer through the Transaction Token trust-domain rules and local configuration.
- A token whose visible act chain exceeds the configured maximum depth (Delegation Chains) fails validation.
- If the request path requires actor-profile conformance, including through actor_profile_required: true, a token evaluated as delegated MUST carry act, and every actor object in the visible act chain MUST include iss. If either is missing, reject the request. This is structural validation, not independent authentication of historical actors. Non-delegated tokens need not carry act.
When the token carries a top-level presenter-binding claim such as cnf, validate the accompanying proof according to the applicable deployment profile, because defines no presenter-proof mechanism. The top-level presenter binding applies only to the current presenter.
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 treats them as distinct and rejects the request when its authorization decision requires them to identify the same party, such as when it relies on both to identify the current presenter (Actor Claim in Transaction Tokens).
Apply actor authorization per Actor Authorization when required by local policy or when the token is accepted as satisfying a delegated-access requirement for the request path.
Optionally traverse inner act objects to audit the full delegation chain. They are not inputs to access-control decisions () and have the trust properties in Carry Prior-Actor Context.
If any of the above steps fail, the RS MUST reject the request through the deployment's Transaction Token handling, because defines no error response. Validation or presenter-proof failures are token-validation failures; failures of actor authorization required by local policy are authorization failures. The RS MUST NOT include actor-specific rejection details in error responses exposed outside the trust domain.

Token Introspection When token introspection () 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: true, per .
sub: REQUIRED. The subject of the delegated token, as defined in .
act: REQUIRED. The actor object conforming to Actor Object Structure, 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.

The AS MUST return actor claims from the token's authorization context, including the complete nested chain, except for the following privacy-filtering allowance. If local privacy policy requires omitting inner actors, the AS MAY filter them but MUST include "chain_complete": false. When chain_complete is false, the subject and the outermost actor remain available for authorization, and the RS records the incompleteness in any audit of the chain. The RS MUST NOT treat a partial chain as complete delegation history. Companion profiles with data aligned to act define their filtering behavior as required by Companion Profiles and Extension Points. When an AS supports delegated opaque access tokens through introspection, it MUST return the members listed above for active delegated tokens. Support for this compatibility path MUST NOT be inferred solely from actor_profile_required metadata; see Profile Scope. An introspecting RS MUST apply the same delegated-token processing as for equivalent locally validated JWT claims, including actor authorization when required by local policy. If policy or token context indicates delegation, a missing act member is an inconsistency, and the RS MUST reject the token with HTTP 401 and error="invalid_token"; actor_profile_required alone does not indicate delegation. Otherwise, the RS MAY treat an active response without act as non-delegated. Introspection endpoints for delegated tokens SHOULD be advertised using the introspection_endpoint parameter in AS metadata (). When revocation is integrated, the introspection response for a revoked delegated token returns "active": false per and MUST NOT include the act or sub_profile members. Resource servers that cache introspection responses for delegated tokens should use short cache lifetimes consistent with revocation requirements.

Error Responses When an AS or TTS rejects a request for reasons related to actor-profile processing, it MUST use the error mappings in this section and construct the response per . Input-validation errors depend on the request's grant type. On Token Exchange requests, including TTS requests, an invalid or policy-unacceptable subject_token or actor_token uses the invalid_request error code (). On JWT bearer grant requests, an invalid assertion uses the invalid_grant error code (). This distinction also applies to missing required claims, invalid actor structure, and excessive inbound chain depth. Client-authentication and proof-mechanism errors take precedence over these generic input-validation errors. Failed client authentication uses the invalid_client error code per or . A supplied invalid DPoP proof uses the invalid_dpop_proof error code; a nonce challenge uses the use_dpop_nonce error code, per Sections and of . A missing required grant proof is an input-validation failure and uses the grant-type-specific error above. Actor-authorization denials use the actor_unauthorized error code, an extension error permitted by . The following error codes apply to both AS and TTS endpoints:

Error	Condition
`invalid_request`	Malformed request, missing required request parameter, or an actor addition that would exceed the depth limit; on a Token Exchange request, also input-validation failures
`invalid_grant`	On a JWT bearer grant request: input-validation failures, including an invalid assertion, untrusted issuer, or failed grant binding
`invalid_scope`	No effective scope remains for reasons other than categorical actor denial, or a Transaction Token's scope authority cannot be determined
`actor_unauthorized`	Actor policy prohibits the request, rejects the actor type, or cannot confirm the required delegation relationship

Missing required claims include act.sub, act.iss, the binding claim of a sender-constrained JWT assertion grant, and the top-level iss claim on a delegated Transaction Token. TTS failures to preserve the subject or to trust inbound actor identifiers use the invalid_request error code. The error_description parameter 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. For a token-endpoint actor_unauthorized response, the client SHOULD check entity_profiles_supported.actor and any error_description. A different actor credential or grant might resolve the failure; local-policy prohibitions might have no remediation. After an RS returns this error, the client SHOULD obtain a token through a different actor credential or grant path. The following is an example of an actor_unauthorized error response:

Metadata and Discovery Authorization servers and resource servers advertise support for this profile using the following parameters:

Parameter	Metadata	Capability
`authorization_grant_profiles_supported`	Authorization server	JWT authorization-grant profiles
`actor_profile_token_exchange`	Authorization server	Token Exchange input and output types
`entity_profiles_supported.actor`	Authorization server	Accepted actor entity types
`actor_profile_required`	Protected resource	Resource requirements for delegated requests

defines authorization_grant_profiles_supported, and defines entity_profiles_supported.actor. This document defines the remaining two parameters in Authorization Server Metadata and Protected Resource Metadata. These signals do not guarantee acceptance of a particular request or every combination of advertised capabilities. Additional constraints are communicated through deployment documentation or agreements.

Authorization Server Metadata This profile uses the following parameters in the AS metadata document ():

authorization_grant_profiles_supported:

OPTIONAL. A JSON array defined by . An AS that processes JWT authorization grants carrying actor-profile claims SHOULD include urn:ietf:params:oauth:grant-profile:actor-profile. Including this value advertises the processing rules for all JWT authorization-grant paths defined in this document. An AS advertising this value MUST also list 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 this parameter is absent, the AS makes no claim about Token Exchange support under this profile. This document defines the following members:

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)
- urn:ietf:params:oauth:token-type:access_token: JWT access tokens (JWT Access Tokens)
- urn:ietf:params:oauth:token-type:id_token: OpenID Connect ID Tokens (OpenID Connect ID Token)
- urn:ietf:params:oauth:token-type:refresh_token: refresh tokens (Refresh Token)
- urn:ietf:params:oauth:token-type:txn_token: Transaction Tokens (Transaction Tokens)
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) and workload identity credentials (Workload Credential Processing), which Token Exchange Processing distinguishes
- urn:ietf:params:oauth:token-type:access_token: JWT access tokens (JWT Access Token as actor_token)
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)
- urn:ietf:params:oauth:token-type:jwt: JWT assertion grants (JWT Assertion Grants)
- urn:ietf:params:oauth:token-type:id-jag: ID-JAGs (), a JWT assertion grant profile (JWT Assertion Grant Output)
- urn:ietf:params:oauth:token-type:txn_token: Transaction Tokens (Transaction Tokens)

Advertising a token type does not guarantee support for every input/output combination, resource, scope, binding mechanism, or JWT variant. The following is an example of an AS metadata fragment:

Protected Resource Metadata This document defines the following parameter for use in Protected Resource Metadata ():

actor_profile_required:: OPTIONAL. A boolean indicating that delegated access to the resource requires actor information conforming to this profile. When the value is false or the parameter is absent, the metadata makes no such claim. Non-delegated requests need not carry the act claim. Clients SHOULD treat true as requiring a conforming token or an explicitly documented introspection path that provides equivalent claims for opaque tokens. An AS that knows, by configuration or from this metadata, that actor_profile_required is true for the resource MUST reject a request that would produce a nonconforming delegated token for the resource unless a supported introspection path provides equivalent actor information. An RS enforcing this policy MUST reject a delegated request for which neither form of actor information is available. The parameter applies to the resource as a whole. An RS with path-specific requirements MUST enforce them at the request layer. It MAY advertise true as a conservative resource-wide signal; clients and deployment documentation SHOULD account for path-specific enforcement that metadata cannot fully express.

Clients discover the actor entity profile values that an authorization server for the resource accepts by consulting the entity_profiles_supported.actor array in the AS metadata of one of the authorization servers listed in the resource's authorization_servers array (). When authorization_servers lists multiple entries, the client SHOULD select the AS that issued or will issue the token being presented. The following is an example of a Protected Resource Metadata fragment:

Transaction Token Capability Signaling An AS or TTS advertises Transaction Token support for Token Exchange under this profile through actor_profile_token_exchange.requested_token_types_supported. When an AS or TTS that can issue Transaction Tokens as delegated Token Exchange outputs under this profile publishes actor_profile_token_exchange, 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 a separate Transaction Token discovery parameter.

Capability Signaling Usage Clients consult the resource's Protected Resource Metadata () and the associated AS metadata () for the parameters listed in Metadata and Discovery. When this profile is combined with Identity Chaining (), clients SHOULD additionally consult identity_chaining_requested_token_types_supported; the two parameter sets are independent. The metadata defined in this document does not advertise authorization-code actor-selection mechanisms or per-scope or 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. As an example of a 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 ordinarily stops before making the token request because the AS does not advertise support for the actor type that the client needs to represent.

Companion Profiles and Extension Points This document defines delegated identity as represented in the current token; companion profiles can define supplementary behavior such as provenance, transparency, or deployment-specific audit material. A companion profile that builds on this profile:

MAY define additional top-level JWT claims, OAuth metadata parameters, or introspection response members that apply only to a token that conforms to this profile or to an introspection response for a delegated opaque access token under Token Introspection;
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.

A companion profile can define authorization based on independently verifiable per-hop evidence that it carries in its own top-level claims. Nested act objects remain informational for access control (). An implementation that conforms only to this core profile MUST ignore unrecognized companion-profile claims, metadata parameters, and introspection response members unless another specification or local policy defines their meaning. A deployment that requires support for a companion profile expresses that requirement through the companion profile's own metadata, through out-of-band agreement, or through another explicit local-policy mechanism.

Deployment Considerations

Migration and Adoption

RFC 8693 Backwards Compatibility An actor object without the iss claim does not conform to this profile. Implementations MUST treat it as nonconforming and MUST NOT infer semantics for absent claims. When local policy or advertised metadata requires profile conformance for a token or assertion, recipients MUST reject such actor objects. When an AS receives such an actor object:

If profile conformance is required by policy or metadata, the AS MUST reject the input under Error Responses.
Otherwise, the AS MAY apply local rules for non-profile processing. It MUST NOT add iss to an inherited actor, silently drop the inbound act, or carry the nonconforming chain into a profile-conforming output. A request requiring that output MUST be rejected.

A deployment can migrate in three stages:

Issuers emit act.iss for every actor in newly issued profile tokens, as Actor Object Structure requires. Existing consumers can ignore the additional claim.
Consumers SHOULD begin validating the actor identifier context once issuers support it.
Once all token issuers and consumers on a path have been updated, resources SHOULD enforce conformance through local policy and actor_profile_required: true. ASes can also require conformance on updated inbound paths.

Migrating from Implicit to Explicit Delegation Deployments that infer actors from client_id, azp, or request context can migrate incrementally:

Clients SHOULD prefer tokens with explicit actor claims when available.
Issuers SHOULD emit both legacy client identifiers and actor claims during the transition when feasible.
Without act, deployments MAY retain legacy client-based policy.
When both forms are present, deployments apply Client Identity and Delegation and record mismatches.

The legacy form carries only the client_id claim (and optionally the azp claim) to identify the acting party. The following example shows the explicit form, which adds an act claim: In this example, client_id and azp remain auxiliary client-identity inputs, while act.sub carries the explicit actor identity. The following example shows a mismatch: the OAuth client identifier and the explicit actor identifier name different parties unless trusted local mapping rules bind them.

Trusting Actor Identifier Pairs Validate Outermost Actor requires trust in the token issuer's authority to assert the (act.iss, act.sub) pair. Deployment-specific mechanisms for establishing that trust include:

federation metadata or trust-framework configuration that authorizes the token issuer to assert actor identifiers in the act.iss context (for example, );
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 identifiers, one possible local rule is URL namespace containment: an explicitly configured rule that compares scheme, host, port, and path boundaries. Scheme and host comparisons follow and ; paths are generally case-sensitive. Subdomain relationships alone are often insufficient to establish trust without explicit configuration. For example:

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.

Token Lifetime for Delegation Chains Deployments SHOULD use shorter lifetimes for delegated tokens than for non-delegated tokens of equivalent scope. JWT access tokens and assertion grants in multi-hop chains SHOULD last no longer than needed for the authorized task. The lifetime of an upstream artifact also limits how long a downstream actor can request tokens without renewing that artifact. Deployments with three or more actors SHOULD account for delayed revocation across hops. Where revocation risk is significant, for example where a user can withdraw consent at any time, deployments SHOULD combine short lifetimes with introspection at sensitive resources rather than relying solely on the exp claim. provides general guidance.

Security Considerations This document defines no trust framework for actor identifier contexts, delegation approval, or subject-identifier translation; the security of those decisions depends on deployment policy and agreements (Representation and Policy).

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. RS implementations validate the token signature before extracting actor claims, as the applicable token specification and Resource Server Processing require, 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 depends on the signature of the token that carries it. Implementations SHOULD use short token lifetimes, and an expired token is rejected per regardless of chain depth. Inner actor identities are not inputs to access-control decisions (): they are endorsed only by the outer token issuer's signature (Carry Prior-Actor Context). Companion Profiles and Extension Points describes how independently verifiable per-hop evidence can support authorization. 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.

Self-Issued Authorization Grants In a self-issued assertion grant, the acting entity is itself the grant's iss and directly asserts delegation to itself without any upstream AS having authenticated the actor or pre-validated the delegation relationship. JWT Assertion Grant Structure requires rejecting such grants by default; this section gives the controls a deployment needs when another specification or local policy enables them. This section does not apply to client assertions used as actor_token (JWT Client Assertion), for which iss = sub = client_id is the conformant pattern. 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 .
To prevent replay, reject an assertion whose validated (iss, jti) pair has already been accepted, for as long as the assertion remains acceptable, including any allowed clock skew.
Verify proof of possession per the token-endpoint mechanism in use (DPoP per or mTLS per ), and against the assertion's top-level cnf when present and not superseded by presenter rebind, as in step 6 of Authorization Grant Processing and JWT Assertion Grant as subject_token.
Apply the actor-profile validation and proof-of-possession requirements in Authorization Grant Processing.
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 a single trust domain and MUST NOT propagate them across organizational boundaries. Discovery of their acceptance is left to the enabling specification or local policy.

Assertion Replay Prevention An attacker who replays a delegated assertion can obtain tokens that exercise the subject's authorization and can establish an unauthorized delegation chain. Step 1 of Authorization Grant Processing defines replay prevention; short assertion lifetimes bound how long replay records are retained. Presenter rebind supersedes a sender-constrained grant's binding (JWT Assertion Grant as subject_token), so a party that obtains such a grant but not its key can redeem it once, as a Token Exchange subject_token, with any actor credential that local policy authorizes to act for sub. Actor authorization policy, mandatory single use of the grant, and short grant lifetimes remain the mitigations for this case.

Token Substitution An attacker who can present a token with a crafted sub_profile or delegation chain can 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 Preserve Inbound Chain for inherited actor objects and by step 5 of JWT Access Token Output for a carried-forward top-level sub_profile, and they MUST reject values that are malformed or disallowed by local policy.

Confused Deputy A resource server that evaluates only sub when act 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. The mitigation is to authorize the (sub, outermost act.sub) pair, as Actor Authorization describes.

Actor-Authorization Bypass A resource server that requires actor authorization but does not enforce it on every request path where it accepts delegated access, including introspection-based paths (Token Introspection), lets an attacker bypass that policy. Deployments that signal delegated-token requirements with actor_profile_required: true SHOULD ensure that the documented request paths requiring delegated access align with their actual enforcement behavior so that clients do not overinterpret the signal.

Client Identity and Delegation Client identity (client_id, azp, or authenticated client context) remains an auxiliary signal under this profile, and the outermost act.sub, when present, is the explicit delegated-actor signal. The following rules apply:

When act is present, implementations MUST NOT substitute client_id, azp, or other client-identity signals for it as the delegated-actor signal. A trusted local mapping can establish that a client identifier and act.sub identify the same entity without changing the meaning of either claim.
When a single client_id registration serves 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 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 perform identifier reconciliation; if it fails, the identifiers are treated as distinct, and an operation that requires them to identify the same party is rejected, as defined for Identifier Reconciliation in Conventions and Definitions.
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.

sub_profile Trust The token issuer asserts the sub_profile claim, so the claim 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.

Subject Namespace Translation An AS or TTS can translate sub when crossing identifier namespaces, but MUST NOT do so unless local policy establishes that both identifiers refer to the same subject. Trust to perform that mapping is separate from trust to sign tokens and SHOULD be established explicitly. A translated sub is authoritative only within the trust context of the issuer that performed the translation. A recipient that relies only on the issued token MAY evaluate the translated sub as the subject in that issuer's namespace. A recipient needing proof of equivalence to an upstream subject MUST obtain additional evidence, such as another specification, an identity-chain mechanism, or an explicit trust agreement. If required evidence is unavailable, it SHOULD reject the token. This profile provides neither portable subject-equivalence proofs nor a general mechanism for correlating subjects across domains.

Presenter Binding Without top-level presenter proof of possession, any party can replay a leaked token. A sender-constrained delegated token binds the current presenter (the outermost actor), and the RS validates the presenter proof against the top-level cnf claim (Sender Constraint and Proof-of-Possession Validation). Clients should also use the resource parameter () when requesting delegated tokens, because audience restriction limits where a leaked token can be used. 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.

Delegation Depth Limits Unbounded delegation chains increase the attack surface, complicate policy evaluation, and enable denial of service through chain parsing; the local maximum depth that Delegation Chains requires bounds them. Extensions that attach per-hop signed material grow token size in proportion to chain depth. Deployments that combine the reference chain depth with one or more such per-hop mechanisms SHOULD measure realistic token sizes against their transport limits (HTTP header limits are often 8 KB) and consider using token introspection () where inline carriage exceeds those limits.

Actor Identity Rotation 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. 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 explicitly re-establish delegation grants for the new identity; the old grants do not automatically transfer. Tokens issued under the old identity remain valid until they expire.

Delegation Revocation Token revocation () does not by itself revoke a delegation relationship or propagate revocation to downstream tokens. Without an additional revocation mechanism, those tokens can remain usable until expiration; see Token Lifetime for Delegation Chains. An AS with authoritative knowledge that a delegation has been revoked SHOULD refuse new tokens for that (subject, actor) pair. Revocation of a prior hop is enforced through the AS's own issuance records or independently verifiable evidence, not through nested act objects. Implementations MUST NOT skip revocation checks because of chain depth. Long-lived refresh behavior can delay revalidation of upstream delegation; refresh-token policy, delegation-state storage, and cross-hop revocation remain deployment-specific.

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. 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 through audience and token-design decisions made before issuance. Once an issuer preserves a delegation chain, Preserve Inbound Chain requires copying it intact. If local privacy requirements would require omitting a chain element, the issuer rejects the request rather than truncating the chain. A Transaction Token's txn value links service calls in the same transaction and can enable correlation across organizations. Deployments SHOULD follow the privacy guidance in when propagating it across trust domains. The act.sub_profile claim reveals the actor's entity type, including whether it is an AI agent. In some jurisdictions or deployment contexts, this disclosure can be legally significant or can reveal sensitive information about user behavior and tool composition. Issuers SHOULD consider audience-specific disclosure constraints and SHOULD omit unnecessary entity classifications when constructing new actor objects. Inherited actors remain subject to the preservation rules in Preserve Inbound Chain. The req_wl claim can reveal internal workload topology. A TTS SHOULD disclose it only where needed for authorization, audit, or policy enforcement, and SHOULD avoid exposing internal workload identifiers across domains unless the deployment requires it.

IANA Considerations

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 of this document

OAuth Authorization Server Metadata Registry This document requests IANA to register the following value in the "OAuth Authorization Server Metadata" registry ():

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 of this document

OAuth Protected Resource Metadata Registry This document requests IANA to register the following value in the "OAuth Protected Resource Metadata" registry ():

Metadata Name: actor_profile_required
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 of this document

OAuth Error Registry This document requests IANA to register the following value in the "OAuth Extensions Error Registry" ():

Error Name: actor_unauthorized
Error Usage Location: token error response, resource access error response
Related Protocol Extension: OAuth Actor Profile for Delegation
Change Controller: IETF
Reference: Error Responses of this document

OAuth Token Introspection Response Registry This document requests IANA to register the following value in the "OAuth Token Introspection Response" registry ():

Name: chain_complete
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 of this document

JWT Claims Registry This document does not request independent entries in the "JSON Web Token Claims" registry for the act object sub-claims (iss, sub_profile, and any extension claims) it defines or profiles. These claims appear only within the JSON object value of the act claim, which already registers in the "JSON Web Token Claims" registry.

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

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 . The IANA actions for those entries are contingent on the progression of .

References Normative References Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework: Bearer Token Usage This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] OAuth 2.0 Token Revocation This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. OAuth 2.0 Token Introspection This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. OAuth 2.0 Authorization Server Metadata This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. OAuth 2.0 Protected Resource Metadata This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. OAuth 2.0 Token Exchange This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. Resource Indicators for OAuth 2.0 This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. OAuth 2.0 Demonstrating Proof of Possession (DPoP) This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Transaction Tokens CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. WIMSE Workload Credentials Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. WIMSE Workload Proof Token Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. OAuth Entity Profiles Microsoft Microsoft Independent Identity Assertion JWT Authorization Grant Okta Independent Ping Identity OpenID Connect Core 1.0 OpenID Foundation Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Best Current Practice for OAuth 2.0 Security This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. JWT Authorization Grants with DPoP Okta OAuth Identity and Authorization Chaining Across Domains Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. OpenID Federation 1.0 OpenID Foundation

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

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`

The batch processor is both the OAuth client and the acting service. The client_id claim identifies the client registration, and act.sub explicitly identifies the acting service.

Access Token The Enterprise AS issues the following JWT access token for the Payroll API: This token carries a single-hop actor object: the act claim is present but contains no nested act object. The sub claim identifies the payroll administrator, while act.sub identifies the service exercising that administrator's authorization.

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, presenting its workload credential, issued by https://as.example.com, as actor_token. The Payroll API is the requesting workload (req_wl). In presenter-rebind mode, the TTS validates the inbound delegation chain and the workload credential, preserves the chain as an inner act object, and adds a new outermost actor for the Payroll API: The administrator remains the subject. The Payroll API becomes the outermost actor, and the batch processor remains the inner actor.

Cross-Domain AI Agent Flow: ID Token to Transaction Token This appendix follows a delegated request across two trust domains. Token validation and presenter proofs follow the underlying token specifications and the deployment profile. All claim values, JWK thumbprints, and domain names are synthetic. Long HTTP example lines use the backslash convention defined in ; other line breaks in form bodies are for readability only.

Scenario and Parties Alice authenticates at the Enterprise IdP AS. Her Travel Assistant exchanges the ID Token for an ID-JAG, then presents that grant to the Travel Provider AS for an access token. The agent calls the Booking Tool, which exchanges the access token for a Transaction Token to call the Inventory Service. ID Token | (2) Token Exchange v Enterprise IdP AS -> ID-JAG | (3) JWT bearer grant +--------> Travel Provider AS -> Access Token | Travel Assistant <-----------+ | (4) Access Token + DPoP v Booking Tool (RS) --(5) Token Exchange--> TTS ^ | +-------- Transaction Token ----------+ | (6) Transaction Token + WIMSE proof v Inventory Service (RS) ]]>

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

The following table lists the presenter key bindings:

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

Capability Discovery (Preflight) Before initiating the flow, the agent consults the following Travel Provider AS metadata (Metadata and Discovery) as an advisory compatibility check: 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 only coarse compatibility indicators; the agent proceeds because the advertised capabilities cover its planned path.

Step 1: User Authentication (ID Token) Alice authenticates to the Enterprise IdP AS, which issues the following ID Token. An ID Token implicitly identifies a user; it does not carry a sub_profile claim, and the AS establishes the entity type in subsequently issued tokens (Step 2):

Step 2: Enterprise Token Exchange (ID Token to ID-JAG) The agent presents Alice's ID Token as the subject_token in a Token Exchange request to the Enterprise IdP AS, requesting an ID-JAG (). The agent's client assertion () serves as both the client_assertion (for client authentication) and the actor_token (for actor identity), as described in JWT Client Assertion. The Enterprise IdP AS authenticates the client, verifies that the ID Token audience matches that client, and uses local delegation policy to construct the issued ID-JAG. The following is an example of the Token Exchange request: grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &subject_token= &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3A\ token-type%3Aid_token &requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3A\ token-type%3Aid-jag &audience=https%3A%2F%2Fas.travel-provider.example &resource=https%3A%2F%2Fapi.travel-provider.example &scope=booking%3Acreate &client_id=https%3A%2F%2Fagents.enterprise.example%2Ftravel-assistant &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A\ client-assertion-type%3Ajwt-bearer &client_assertion= &actor_token= &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt ]]> The Enterprise IdP AS validates the shared client assertion for both client authentication and actor identity, verifies the DPoP proof, and confirms Alice's delegation under local policy. It applies scope reduction and binds the following issued ID-JAG to the demonstrated DPoP key: In this ID-JAG, the client_id, azp, and act.sub claims carry the same URI because the agent is both the client and the actor. The top-level cnf.jkt member binds the grant to the agent's key.

Step 3: Agent Exchanges ID-JAG for Access Token at Travel Provider AS The agent presents the ID-JAG as a JWT bearer grant () to the Travel Provider AS, which processes it as an ID-JAG per with the actor-profile rules in Authorization Grant Processing: grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer &assertion= &scope=booking%3Acreate ]]> The Travel Provider AS performs actor-profile processing per Authorization Grant Processing: it verifies the request's DPoP proof against the top-level cnf.jkt in the inbound ID-JAG and checks that act.sub_profile (ai_agent) is permitted as an actor for the requested scope under local policy. It issues the following access token, which preserves the delegation chain: The Travel Provider AS preserves Alice's subject identifier and classification, the actor chain, and the agent's presenter binding. Client identifiers remain separate from actor semantics.

Step 4: Agent Calls Booking Tool API The agent presents the access token with a DPoP proof: DPoP: Content-Type: application/json {"origin": "SFO", "destination": "NYC", "depart": "2026-04-15"} ]]> The Booking Tool RS authorizes the (sub, outermost act.sub) pair (Resource Server Processing): it evaluates Alice (sub, sub_profile: user) together with the Travel Assistant (act.sub, sub_profile: ai_agent) for the requested operation. The act.sub_profile value is checked against entity_profiles_supported.actor per Authorization Server Metadata.

Step 5: Booking Tool Exchanges Access Token for Transaction Token The Booking Tool cannot reuse the received access token for internal calls because the token is sender-constrained to AgentJKT, a key that the Booking Tool does not possess. Instead, it requests a Transaction Token from the TTS. In this example, the TTS receives the Booking Tool's WIMSE Workload Identity Token (WIT), issued by the Travel Provider AS (https://as.travel-provider.example), 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: grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &subject_token= &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3A\ token-type%3Aaccess_token &actor_token= &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3A\ token-type%3Atxn_token &audience=https%3A%2F%2Ftravel-provider.example &scope=inventory%3Acheck &request_context=%7B%22req_ip%22%3A%22198.51.100.42%22%7D ]]> 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: 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 deployment profile defines the cnf.jkt binding, proven by the WPT, and the TTS binds the issued token to the Booking Tool's presenter key (ToolJKT), which the WIT's cnf.jwk carries: The presenter binding changes at this step: cnf.jkt is now ToolJKT because the Booking Tool is the current presenter.

Step 6: Booking Tool Calls Inventory Service Workload-Identity-Token: Workload-Proof-Token: ]]> The Inventory Service validates the WIT and WPT and then authorizes Alice and the Booking Tool as the subject and the immediate actor, respectively. It uses req_wl as supporting workload context. The Travel Assistant remains prior-actor context and is not used for access control.

Summary of Token Transformations

Step	Token	sub	req_wl	act.sub (outermost)	act.act.sub (nested)	cnf.jkt
1	ID Token	Alice
2	ID-JAG	Alice		Travel Assistant		AgentJKT
3	Access Token	Alice		Travel Assistant		AgentJKT
4	(API call)	Alice		Travel Assistant		AgentJKT
5	Transaction Token	Alice	Booking Tool	Booking Tool	Travel Assistant	ToolJKT
6	(internal call)	Alice	Booking Tool	Booking Tool	Travel Assistant	ToolJKT

Key observations:

In this example, sub (Alice) is unchanged across all trust domains and token transformations.
The presenter-binding key changes once, at Step 5, when the TTS rebinds 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.

Acknowledgments The author thanks the OAuth Working Group for the specifications on which this profile builds.

Document History [[ To be removed from the final specification ]] -01

Restructured and tightened the text: each rule has one home, dependencies are cited rather than restated, tables cover claim roles, token types, and error mappings, Token Exchange inputs share one processing algorithm, and Security Considerations point to the rules they rely on. Removed the Conformance section, which restated those rules.
Revised the Introduction to state what Token Exchange leaves open and the ID-JAG extension point this profile fills.
Added hop and visible-hop terminology; only an introspection server filters the visible act chain.
Required client_id in JWT access tokens, per , and limited the JWT access token structure to JWT access token output.
Reworked presenter transitions: bearer continuation by the authenticated outermost actor, rebind by a direct presenter credential or the may_act client, rejection of delegated requests that fit neither mode, a new Token Exchange actor only from an actor_token or the may_act path, issuance without act for requests that are not delegated, a refresh token's recorded act chain kept on Token Exchange and on the refresh_token grant, every requested audience and resource issued or invalid_target returned, and new-presenter proof only for sender-constrained output.
Kept nested act informational for access control, per : inner actors are prior-actor context only.
Rebind now supersedes a sender-constrained assertion grant's binding and makes the grant single-use; grant replay protection depends on an enforced grant-level sender constraint and the (iss, jti) pair.
Aligned error codes with and : invalid_request on Token Exchange, invalid_grant on JWT bearer grants, and actor_unauthorized for actor-policy denials, with explicit error precedence.
Set an ID-JAG's aud to the Resource Authorization Server's issuer identifier, capped the scope issued from an assertion-grant or Transaction Token subject_token, required jti in assertion grants, and required an ID Token's aud to match the authenticated client.
Aligned Transaction Token rules with : act only for delegation, sub unchanged on replacement, scope within the subject_token's authority, and presenter proof and rejection per the deployment profile.
Used may_act.iss as the identifier context when present, and preserved inherited actor objects, their extension and confirmation members, and unrecognized sub_profile values unchanged.
Resource servers validate mTLS-bound tokens, require iss on every visible actor object when conformance is required, identify the outermost actor by its (act.iss, act.sub) pair, treat a missing act in introspection as an error only when delegation is indicated, and enforce the depth limit.
Clarified actor-token classification and validation for standalone JWT client assertions, JWT access tokens, and WIMSE workload credentials, including each type's act.iss and a client check for a bearer JWT access token.
Tightened the metadata triggers and added the ID-JAG token type to requested_token_types_supported.
Removed BCP 14 keywords from guidance no other party can observe, made RFC 6749, RFC 7800, OpenID Connect Core, and ID-JAG normative, corrected citations, and aligned the examples on one travel scenario.

-00

Initial version.