OAuth Actor Profile for Delegation

1.1. Illustrative Use Case

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

1.2. Relationship to Related Work

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

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

Identity Assertion JWT Authorization Grant ([I-D.ietf-oauth-identity-assertion-authz-grant]): An ID-JAG carrying an act claim is processed per Section 4.2 of this document. See Appendix B for an end-to-end example.¶

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

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

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

3.1. Overview

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

3.2. Profile Invariants

The following invariants define the interoperable core of this profile:¶

• sub is the authorizing principal.¶

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

• act.iss identifies namespace authority for act.sub; it is not a credential-issuer claim or hop-provenance marker.¶

• Nested act objects are preserved prior-actor context unless a deployment explicitly applies additional local-policy processing to them; this profile does not standardize authorization semantics for those nested entries.¶

• client_id and azp are OAuth client identifiers, not actor identifiers.¶

3.3. What This Profile Does Not Standardize

This profile does not standardize the following:¶

• delegation approval, consent, or grant-management policy¶

• subject-identifier translation mechanisms or proof of subject equivalence across namespaces¶

• authorization semantics for nested act objects¶

• client discovery or preflight algorithms beyond the metadata semantics defined here¶

• cross-domain trust frameworks for establishing namespace authority for act.iss¶

• SAML 1.1 or SAML 2.0 assertions as Token Exchange subject_token inputs; while [RFC8693] defines token type URNs for SAML assertions, actor-profile extraction from XML-based SAML credentials is outside the scope of this document¶

3.4. Conformance Scope

Conformance to this profile means that issuers and consumers represent, preserve, validate, and interpret actor claims consistently according to this document. It does not require every deployment to enforce authorization of the (sub, outermost act.sub) pair on every request, although such enforcement is RECOMMENDED for security-sensitive delegated access.¶

Same-domain deployments will often satisfy these requirements with straightforward local configuration for namespace authority and identifier mapping. Cross-domain deployments typically require explicit trust-framework or bilateral agreement decisions and therefore have a higher interoperability burden under this profile.¶

This profile defines actor-profile requirements for JWT assertion grants, JWT-formatted access tokens, and Transaction Tokens. It does not define an equivalent interoperable profile for opaque access tokens. Deployments using opaque access tokens, including as subject_token or actor_token inputs to Token Exchange, are out of scope for this document. An AS MAY translate introspection results for an opaque access token into equivalent local inputs for deployment-specific use, but that behavior is not interoperable behavior defined by this document.¶

The actor profile defines processing rules for the following token types as issued outputs: JWT assertion grants (Section 4), JWT-formatted access tokens (Section 5), and Transaction Tokens (Section 7.1). It also defines Token Exchange input processing for JWT assertion grants, JWT access tokens, OpenID Connect ID tokens, refresh tokens, and Transaction Tokens as subject_token, and for workload identity credentials, JWT client assertions, and JWT access tokens as actor_token. The may_act pre-authorization claim (Section 6.1.6) applies to any JWT used as subject_token.¶

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

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

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

3.5. Implementation Summary

The following table summarizes the minimum implementation obligations by role. The "Detailed rules" column contains forward references to the normative sections where each role's requirements are fully defined; readers using this table as a quick-reference checklist may follow those links directly.¶

3.6. Actor Object Structure

An actor object is a JSON object that is the value of the act claim. In addition to the sub claim required by [RFC8693], an actor object MUST contain an iss claim, SHOULD contain a sub_profile claim, and MAY contain a cnf claim.¶

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

sub:

REQUIRED. The subject identifier of the actor, as defined in [RFC8693], Section 4.1. This value identifies the acting party. It is a StringOrURI as defined in [RFC7519]. When the (act.iss, act.sub) pair identifies the same entity as the (iss, sub) pair of the token (that is, when the actor and subject are the same party under the same namespace authority), no delegation is expressed; including an act claim is typically not useful in that case. When act is present but identifies the same entity as sub, consumers MUST NOT infer a meaningful delegation relationship from the token. String equality of act.sub and sub alone is not a sufficient test; the namespace authority (act.iss vs. token iss) must also be considered.¶

iss:

REQUIRED. Identifies the namespace authority for the actor identifier carried in act.sub, playing the same role for act.sub that the JWT iss claim plays for the token sub: just as iss + sub form a globally unique principal identifier in a JWT (see [RFC9493]), act.iss + act.sub form a globally unique actor identifier within the delegation chain. For URI, client, workload, or other deployment-specific identifiers, the value of act.iss MUST identify the authority that the deployment treats as authoritative for resolving or validating that actor identifier. See "Cross-Domain Delegation" in Section 2. The value is a StringOrURI as defined in [RFC7519].¶

Unlike the credential issuer, which is an AS-internal concern resolved during assertion validation, act.iss identifies only the namespace authority and is not a credential-issuer claim or hop-provenance marker. The namespace authority and the credential issuer may be the same entity or different entities. In many deployments the value is an HTTPS URL, but other well-known identifier schemes (for example, a URN for workload identities) are also possible. Preserving an inner act object in a newly issued token does not change the meaning of its act.iss value and does not cause that inner entry to become independently authenticated by the new issuer; it remains prior-actor information carried within the outer issuer's trust context.¶

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

sub_profile:

RECOMMENDED. A space-delimited list of entity profile values classifying the actor identified by act.sub, as defined in Section 4.2 of [I-D.mora-oauth-entity-profiles]. Values used within act objects MUST be registered with the "Actor Profile" usage location in the OAuth Entity Profiles registry (Section 14.1 of [I-D.mora-oauth-entity-profiles]) or be privately defined collision-resistant values. If the acting entity fits more than one profile, multiple values MAY be included as a space-delimited string (e.g., "service ai_agent"). Policy evaluation rules for multi-value strings are defined in Section 3.7.¶

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

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

When an act object contains extension members beyond those defined in this document, issuers and consumers MUST ignore unrecognized members unless another specification or local policy defines their meaning. An issuer that re-issues a validated actor chain MAY preserve unrecognized extension members in inherited act objects under local policy.¶

3.7. Multi-Value sub_profile Policy Evaluation

Value preservation and propagation for unrecognized sub_profile values are governed by [I-D.mora-oauth-entity-profiles]. An AS or RS MUST NOT reject a token or assertion solely because a sub_profile value is unrecognized; unrecognized values MUST NOT be used to infer authorization semantics.¶

The sub_profile claim improves local policy expression and coarse compatibility signaling, but it does not make authorization outcomes portable across deployments. Two deployments can accept the same sub_profile value while applying different authorization consequences to it.¶

When local policy restricts the accepted set of sub_profile values for an actor, that set SHOULD be advertised via entity_profiles_supported.actor in AS metadata (Section 10.2.2) so that clients can detect incompatibility before making a request. Clients discover the accepted set for a given resource by consulting entity_profiles_supported.actor in the AS metadata for the AS listed in the resource's authorization_servers ([RFC9728]).¶

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

When sub_profile contains multiple space-delimited values, the following guidance applies to policy evaluation:¶

• As a safe default, an entity can be treated as matching a policy rule if any of its sub_profile values satisfies that rule. For example, an entity with "service ai_agent" matches both a policy rule for service and a policy rule for ai_agent.¶

• When multiple values match different policy rules with conflicting outcomes, implementations are encouraged to apply the more restrictive outcome rather than the union of all matched rules' privileges. The specific conflict resolution logic is a local policy decision; this document recommends least privilege across the matched set as a safe default.¶

• When local policy accepts only a specific set of sub_profile values (e.g., via entity_profiles_supported.actor), the entity can be accepted if at least one of its values appears in the accepted set. Values not in the accepted set SHOULD be ignored for that acceptance check; they do not by themselves require rejection.¶

3.8. Delegation Chains

Delegation chains MUST be represented by nesting act objects as specified in [RFC8693], Section 4.1. In a nested structure, the outermost act object identifies the immediate actor; inner act objects represent prior actors in the chain, with the innermost representing the original delegating party. This structure records delegated-actor history within the trust model of the issuer that conveys it; it does not, by itself, provide independent cryptographic provenance for each prior hop.¶

This document uses the following terminology consistently:¶

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

• An inbound actor chain is the complete act structure received in an inbound token, whether depth 1 or greater.¶

• A preserved actor chain is an inbound actor 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.¶

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

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

Delegation depth is defined as the number of act objects in the chain, counting from the outermost. A token with a single act object and no nested act within it has depth 1. Each additional level of nesting adds 1. Depth is counted on the resulting chain after any new outermost act is added, not on the inbound token. Implementations MUST support at least one level of delegation (depth 1). Implementations intended for cross-domain multi-hop interoperability SHOULD support at least five levels of nested act objects to accommodate realistic multi-tier architectures (e.g., user → orchestrator → agent → tool → internal service). An implementation that supports only depth 1 and rejects all depth-2 or deeper chains is conformant to this document but will not interoperate with multi-hop deployments. Same-domain deployments MAY support a shallower local maximum when that limit is sufficient for their architecture. Implementations MAY support larger depths and SHOULD define and enforce a local maximum delegation depth according to deployment needs. Implementations that receive a token exceeding their configured local maximum delegation depth MUST reject it with invalid_request. When a request would result in a chain that exceeds that local limit, the AS MUST reject the request with invalid_request; it MUST NOT silently truncate the chain.¶

3.9. Actor Chain Validation and Construction

The following normative algorithm governs how an AS validates an inbound actor chain and constructs the actor chain in the issued token. It applies to all token types defined in this profile. Type-specific sections in Section 4.2, Section 6, and Section 7.4 reference this algorithm and add type-specific preconditions. This algorithm governs claim handling only; it does not by itself create new delegation-authorization requirements beyond those imposed by the applicable processing section and local policy.¶

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

  if inbound_chain is present:
    outermost.act = inbound_chain  // nest entire validated inbound chain
    verify depth(outermost) <= local_max_depth  // per V5

  return outermost

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

3.10. Sender Constraint and Key Binding

When sender-constrained tokens are used with a delegated token, the top-level cnf claim identifies the key or certificate of the immediate presenter of that token. When delegation is present, that immediate presenter is ordinarily the party identified by the outermost actor. Authorization servers and resource servers validate current proof of possession against the top-level cnf.¶

When a sender-constrained token is used only as an inbound credential in Token Exchange, its top-level cnf remains binding information for that inbound token instance. If the exchange keeps the same presenter, the requester proves possession of that key per the underlying sender-constraint mechanism. If the exchange legitimately introduces a distinct new presenter established by an actor_token or by the output-token mechanism (for example, Transaction Token issuance that re-binds the delegation chain to a new presenter), the AS validates the current requester's proof under the credential or mechanism that establishes that new presenter and MUST NOT require the new presenter to prove possession of the prior presenter's key solely because the inbound subject_token was sender-constrained.¶

When DPoP [RFC9449] is used:¶

• The top-level cnf.jkt of the token MUST identify the key of the immediate presenter, the actor identified by the outermost act claim.¶

This profile does not define per-actor confirmation members within nested act objects. Stronger prior-hop key provenance, if needed, would require another profile layered on top of this one.¶

When mTLS ([RFC8705]) is used instead of DPoP, the top-level cnf.x5t#S256 identifies the current presenter's certificate.¶

3.11. Proof-of-Possession Validation in Delegated Requests

The following normative rules govern proof-of-possession (PoP) validation for all token types and credential exchanges defined in this profile. Individual processing sections reference these rules and MUST apply them in addition to any type-specific requirements stated there.¶

3.12. Summary of Actor-Profile Claims

The act object structure defined in Section 3.6 applies uniformly to all three token types covered by this document. The following tables summarize claim requirements.¶

The sub-claims of the act object have the same requirement level regardless of which token type carries the act claim:¶

Requirements for top-level claims vary by token type:¶

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. Its value MUST be a space-delimited entity profile string per [I-D.mora-oauth-entity-profiles] and applies exclusively to sub; it 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.¶

Detailed token definitions and processing rules are defined in Section 4, Section 5, Section 6, and Section 7.4.¶

4.1. Structure

Actor-profile requirements apply to any JWT used as an authorization grant under [RFC7521] and [RFC7523], independent of how or by which specification it was produced. One such profile is the Identity Assertion JWT Authorization Grant (ID-JAG, [I-D.ietf-oauth-identity-assertion-authz-grant]), a JWT bearer grant produced by Token Exchange.¶

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

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

iss (REQUIRED):

Identifies the assertion issuer. MUST be authorized by local policy to assert the relationship between sub and act.sub.¶

sub (REQUIRED):

The principal on whose behalf the grant is being made.¶

sub_profile (RECOMMENDED):

Classifies the entity type of sub. MUST conform to the values defined in Section 3.¶

act (REQUIRED when delegation is asserted):

The actor object identifying the entity exercising the subject's delegated rights. MUST conform to the actor object structure defined in Section 3. MUST include act.sub and act.iss.¶

cnf.jkt (REQUIRED when DPoP is used; otherwise OPTIONAL):

When the JWT assertion grant is sender-constrained with DPoP, the assertion MUST carry a top-level cnf.jkt identifying the DPoP key to which the assertion is bound. When DPoP is not used, top-level cnf is OPTIONAL for JWT assertion grants unless required by another profile or local policy.¶

When the assertion or request context also identifies an OAuth client via client_id, azp, or an authenticated client credential, interoperable processing SHOULD use act.sub rather than treating that client identity as a substitute for it. Deployments that rely on client identity as a substitute actor signal are outside the interoperable scope of this profile; see step 7 in Section 4.2.¶

Clients SHOULD use JWT assertion grants carrying actor-profile claims only when the AS's support for the actor-determination model has been confirmed via deployment documentation, prior agreement, or discovery.¶

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

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

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

The AS-issued grant is the more trustworthy pattern because the issuing AS independently authenticated the agent and validated the delegation relationship before signing. The receiving AS needs to trust only the enterprise AS as an issuer.¶

For AS-issued grants, the issuing AS MUST set act.iss to the namespace it is authoritative for, typically its own issuer URI.¶

Allowed issuer patterns are:¶

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

• an assertion carrying a pre-existing nested act chain where the current JWT iss is trusted to carry forward prior actor assertions, and¶

• a self-issued actor assertion (see Section 4.1.1 below).¶

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

4.2. Authorization Grant Processing

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

1. The AS MUST validate the assertion per [RFC7523].¶

2. The AS MUST determine that the assertion issuer is trusted to assert the relationship between the JWT sub and act.sub. In the typical case the JWT iss is a trusted AS, and the AS MUST verify that this issuer is authorized under local policy to assert delegation on behalf of the actor identified by act.sub. For self-issued grants, see Section 4.1.1.¶

3. If act.iss is absent from the inbound act object, the AS MUST reject the request with invalid_request; an absent act.iss is a structural violation, not a validation failure. Otherwise, the AS MUST establish, under a trusted framework or local policy, that act.iss is authoritative for the identifier namespace of act.sub. This step validates namespace authority only; it does not reinterpret act.iss as a credential-issuer claim or as proof that every upstream hop was independently authenticated. This document does not define a single interoperable algorithm for making that determination. Deployments MAY rely on federation metadata, pre-registration, bilateral agreements, deployment-specific policy, or another equivalent trust mechanism. Cross-domain interoperability for act.iss validation is only well-defined when the participating parties share such a trust framework or explicit agreement. If the AS cannot establish that act.iss is authoritative for the namespace containing act.sub, the AS MUST reject the request with invalid_grant. Section 11.3 provides non-normative examples of local validation approaches.¶

4. Before issuing a token, the AS SHOULD evaluate whether act.sub is authorized to exercise delegation on behalf of sub, using the AS's local policy (for example, a pre-registered delegation grant, an explicit consent record, or a policy rule covering the acting party). When AS policy explicitly prohibits the identified actor from acting on behalf of the subject, the AS MUST return access_denied. The form of delegation authorization is not standardized by this profile.¶

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

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

   • Entries used by the AS for issuance decisions: Interoperable processing is defined around sub and the outermost act.sub. If local policy additionally uses an inner act object for authorization, scope determination, or another issuance decision, the AS SHOULD validate the act.sub and act.iss pair per step 3 and SHOULD evaluate the delegation relationship per step 4. Such use of inner act objects is deployment-specific rather than part of the baseline interoperable behavior of this profile.¶

   • Preserved prior-actor context: For inner act objects the AS preserves only as prior-actor context, the AS MAY rely on trust in the outer assertion issuer per step 2 rather than independently validating each prior hop. Under this profile, preserved inner act objects are not part of the baseline interoperable authorization input; downstream authorization interoperability is defined around sub and the outermost act.sub.¶

   • No implicit authentication: The AS MUST NOT treat any preserved inner actor as independently authenticated merely because it appears in the re-issued token, and preserving such an entry does not by itself endorse it for downstream access-control use.¶

6. The AS MUST verify proof of possession per the token-endpoint mechanism in use (DPoP per [RFC9449] or mTLS per [RFC8705]).¶

   • DPoP: The inbound assertion grant MUST carry a top-level cnf.jkt. The AS MUST verify the DPoP proof against that value rather than the presenter's locally registered key. In cross-domain flows the cnf.jkt was set by the upstream issuer; the AS SHOULD treat it as the expected key and SHOULD reject with invalid_request if it is absent or invalid_grant if the proof does not match, unless another sender-constraint profile or explicit local binding rule defines a different continuity model. > Note: The absence of confirmation members inside act does not affect the DPoP binding obligation; [RFC9449] requires the AS to bind the issued token's top-level cnf.jkt to the DPoP proof key regardless.¶

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

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

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

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

8. If the AS accepts the assertion, it MUST propagate the actor information into the issued token according to the rules for the output token type being issued. For JWT access tokens, see Section 6.3.2. For Transaction Tokens, see Section 7.4. When the output is another JWT assertion grant profile, the resulting assertion MUST preserve the validated actor information subject to local policy and the chain-depth limit in Section 3.8.¶

9. The AS MAY add additional sub_profile or act metadata to the issued token based on its own knowledge of the principals.¶

5.1. Structure

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

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

iss (REQUIRED):

Identifies the access token issuer.¶

sub (REQUIRED):

Identifies the principal on whose behalf the access token is issued.¶

sub_profile (RECOMMENDED):

Classifies the entity type of sub. MUST conform to the values defined in Section 3.¶

act (REQUIRED when the token represents delegation):

The actor object identifying the entity exercising the subject's delegated rights. MUST conform to the actor object structure defined in Section 3. MUST include act.sub and act.iss. When the token does not represent delegation, act MUST be omitted.¶

cnf (REQUIRED when sender-constrained; otherwise OPTIONAL):

Binds the access token to the current presenter when a sender-constraining mechanism such as DPoP or mTLS is used.¶

client_id and azp (OPTIONAL):

Identify the OAuth client when carried in the token. They do not identify the delegated actor and MUST NOT be used as a substitute for act.¶

Some deployments also carry an azp claim as an auxiliary client-identity signal, often as an OpenID Connect carry-over used by vendors in practice. When an issuer uses both azp and act.sub to represent the same acting party, it SHOULD ensure they are semantically consistent or else treat them as distinct identifiers under local policy. Deployments that rely on client identity claims as a substitute for act are outside the interoperable scope of this profile. For migration and reconciliation rules, see Section 11.4 and Section 12.2.¶

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

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

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

5.2. Issuance Outside Token Exchange

When an AS issues a JWT access token outside Token Exchange and intends the token to represent delegation, it MUST establish an independent delegation basis for the (sub, actor) relationship. Examples include a pre-registered delegation grant, an explicit consent record, or a policy rule covering the acting party or a class of acting parties.¶

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

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

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

6.1. Subject Tokens

6.2. Actor Tokens

6.3. Output Token Rules

7.1. Transaction Tokens

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

The Transaction Token claim structure in this section reflects [I-D.ietf-oauth-transaction-tokens] as of the date of this document. If [I-D.ietf-oauth-transaction-tokens] revises any claim listed here, the definition in [I-D.ietf-oauth-transaction-tokens] takes precedence for those claims; the actor-profile-specific requirements in Section 7.1.1 and Section 7.4 remain binding for this profile.¶

A Transaction Token contains the following claims. Claims marked REQUIRED are defined as such by [I-D.ietf-oauth-transaction-tokens]; claims marked OPTIONAL may be omitted at the issuer's discretion.¶

iss (OPTIONAL in [I-D.ietf-oauth-transaction-tokens]; REQUIRED by this profile when carrying act):

Issuer of the Transaction Token. MUST be present when the Transaction Token carries an act claim, because act.iss values in the chain are evaluated relative to the token issuer for cross-domain detection and recipients cannot establish namespace authority for act.sub without it. SHOULD be present when the Transaction Token crosses trust-domain boundaries, even in non-delegated cases, as recipients can require it to validate issuer identity or chain-of-trust per local policy. MAY be omitted only when no delegation (act) is present, all tokens are scoped to a single Trust Domain, and all recipients have out-of-band knowledge of the issuer. When iss is omitted, recipients MUST rely on the trust-domain and issuer-identification rules of [I-D.ietf-oauth-transaction-tokens] and local deployment configuration rather than the generic outer-token iss processing rules in this document.¶

aud (REQUIRED):

Identifies the Trust Domain in which the Transaction Token is valid.¶

iat (REQUIRED):

Issued-at time per [RFC7519].¶

exp (REQUIRED):

Expiration time per [RFC7519].¶

sub (REQUIRED):

The identity of the human user or non-personal entity that originated the transaction.¶

scope (REQUIRED):

The transaction authorization scope, as defined by the TTS for the specific transaction.¶

txn (REQUIRED):

A transaction identifier that links all tokens in the same business transaction, as defined in [I-D.ietf-oauth-transaction-tokens].¶

req_wl (REQUIRED):

The workload identifier of the workload that requested the Transaction Token from the TTS. When a Transaction Token is exchanged for a replacement, req_wl is updated to reflect the new requesting workload per [I-D.ietf-oauth-transaction-tokens]. This claim provides TTS-level workload context and is not a substitute for act.sub; see Section 7.1.1.¶

tctx (OPTIONAL):

Transaction context information that remains stable across the call chain.¶

rctx (OPTIONAL):

Request context information. Defined sub-claims are req_ip (originating IP address) and authn (authentication method used).¶

The following table summarizes the claims in a Transaction Token as profiled by this document.¶

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

7.2. Supported Subject Tokens

7.3. Presenter Authentication and New Actor Establishment

When a delegated Transaction Token is issued, the newly authenticated presenter becomes the new outermost actor for that token. Presenter proof is governed by [I-D.ietf-oauth-transaction-tokens] and the applicable deployment profile, while the actor-profile consequences of that presenter change are defined in Section 7.4.¶

7.4. Transaction Token Output Rules

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

1. The TTS MUST preserve sub to refer to the same underlying subject as the inbound token. The TTS MAY change sub only to re-express that same subject in a different identifier namespace under a trusted local mapping. The TTS MUST NOT replace sub with an identifier for a different subject. The mechanics and assurance of subject-identifier translation are deployment-specific and are not otherwise standardized by this document.¶

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

3. The TTS MUST verify that adding a new outermost act object would not cause the chain depth to exceed the limit in Section 3.8. If it would, the TTS MUST reject the request with invalid_request.¶

4. Before preserving or extending any inbound act chain, the TTS MUST validate the inbound token and trust the issuer that conveyed the chain. For the outermost inbound act object, which always represents the outermost actor the TTS is acting upon, the TTS MUST:¶

   • verify that act.iss is authoritative for the identifier namespace of the corresponding act.sub, using local trust mechanisms equivalent in strength to those described in Section 4.2 step 3; and¶

   • evaluate the delegation relationship per local policy, as described in Section 4.2 step 4.¶

   Interoperable processing is defined around sub and the outermost act.sub. If local policy additionally uses inner act objects from the inbound chain to make access-control or scope decisions (beyond carrying them as audit history), the TTS SHOULD apply the same validation as for the outermost entry. For inner act objects that the TTS preserves solely as prior-actor context (carried forward for audit purposes without driving any security decision), the TTS MAY rely on trust in the outer token issuer rather than independently validating each prior hop. The TTS MUST NOT treat prior-context inner actors as independently authenticated merely because they appear in the re-issued token. If local policy treats an inner actor as a security-relevant input but cannot validate it to the assurance level required by that policy, the TTS SHOULD reject the request with invalid_grant.¶

5. 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 local policy explicitly prohibits that (sub, new presenter) relationship, the TTS MUST reject the request with access_denied. If the required actor relationship is absent or cannot be confirmed from the current inputs and policy, the TTS MUST reject the request with actor_unauthorized.¶

6. Because the issued Transaction Token carries delegated actor information, the TTS MUST include a top-level iss claim identifying itself as the Transaction Token issuer, and it MUST create a new outermost act object for the new presenter:¶

   • The TTS MUST set act.sub to the new presenter's identifier.¶

   • The TTS MUST set act.iss to the issuer namespace authoritative for the new presenter's identifier. This obligation applies only to the act object the TTS creates for the current presenter. The TTS MUST NOT rewrite act.iss or any other field in act objects inherited from the inbound token; those entries were authored by upstream ASes and their content is fixed at the point of authorship.¶

   • If the inbound token already carries an act chain, the TTS MUST nest it beneath the new outermost act.¶

   • The TTS SHOULD set act.sub_profile based on its knowledge of the new presenter's entity type.¶

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

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

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

7.5. may_act Pre-Authorization

When the inbound subject_token presented to the TTS is a JWT carrying may_act, the TTS MUST apply the matching rules in Section 6.1.6.2 using the newly authenticated presenter as the candidate actor identity that would become the new outermost act in the issued Transaction Token. A matching may_act MAY satisfy the delegation-authorization requirement in Section 7.4 step 5, but it does not replace validation of the inbound credential, presenter authentication, or the obligation to create a new outermost act.¶

8.1. Authorization Server Error Responses

When an AS rejects a request under this profile for reasons related to actor-profile validation, it MUST return an OAuth error response per [RFC6749], Section 5.2 and [RFC8693], Section 2.2. The following error codes apply across all token types defined in this profile. They do not override invalid_client when a request fails client authentication per [RFC6749] or [RFC7523].¶

invalid_request:

Use when the act claim structure is syntactically invalid, the delegation chain depth exceeds the limit in Section 3.8, a required claim (act.sub or act.iss) is absent, a delegated Transaction Token omits the required top-level iss, or a DPoP-bound JWT assertion grant omits the required top-level cnf.jkt.¶

invalid_grant:

Use when the assertion or subject token cannot be validated, the issuer is not trusted to assert the delegation relationship, or the request's required proof-of-possession check cannot be confirmed.¶

access_denied:

Use when AS policy explicitly prohibits the identified actor (act.sub) from acting on behalf of the subject (sub) for the requested resource or scope, and the prohibition is a definitive policy decision (not a transient or recoverable failure).¶

actor_unauthorized:

Use when the request fails a remediable actor-policy check for the (sub, act.sub) pair. Examples include: the actor's sub_profile is not in the accepted set, the delegation relationship required by local policy is absent or could not be confirmed from current inputs, or the actor lacks the delegation grant required for the requested scope. This code allows clients and agent orchestrators to distinguish actor policy mismatches from credential or structural failures. access_denied remains for explicit deny policy rather than input-contingent actor-policy mismatch.¶

The error_description field SHOULD be included and SHOULD describe which aspect of actor-profile validation failed, to the extent permitted by the AS's security and privacy policy.¶

When a client or agent orchestrator receives actor_unauthorized, it SHOULD attempt the following remediation steps in order:¶

1. Consult entity_profiles_supported.actor in AS metadata (Section 10.2.2) to determine whether the actor's sub_profile is in the accepted set. If not, the AS does not support this actor type for the resource; the failure is terminal for this actor identity.¶

2. If the sub_profile is in the accepted set, inspect error_description to determine whether the failure is due to a missing or unconfirmed delegation grant. If so, obtain or register the delegation grant before retrying.¶

3. If neither step resolves the failure, consult deployment documentation or contact the resource owner to determine whether any path to authorization exists for this (sub, act.sub) pair and scope.¶

4. If no remediation path exists, treat the failure as terminal for this delegation path.¶

actor_unauthorized is distinct from access_denied, which represents a definitive policy prohibition. Receiving actor_unauthorized does not preclude retrying with a different actor credential that may satisfy the AS's actor policy.¶

Example of a definitive prohibition:¶

{
  "error": "access_denied",
  "error_description": "actor is explicitly denied access for this subject"
}

Example of an actor not authorized for the requested scope:¶

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

8.2. Transaction Token Service Error Responses

When a TTS rejects a request for reasons related to actor-profile processing, it MUST return an OAuth error response per [RFC6749], Section 5.2 and [RFC8693], Section 2.2. The following error codes apply:¶

invalid_request:

Use when the inbound token's act claim structure is syntactically invalid, the delegation chain depth would exceed the limit in Section 3.8, a required actor-profile claim (act.sub or act.iss) is absent from an act object in the inbound token, or a delegated Transaction Token omits the required top-level iss claim.¶

invalid_grant:

Use when the inbound token fails validation, the sub identity cannot be preserved per step 1 of Section 7.4, or inbound actor information that the TTS relies on for security-relevant processing cannot be validated per step 4 of Section 7.4.¶

access_denied:

Use when local TTS policy explicitly prohibits the requesting workload from acting in the delegation chain for the identified subject, and the prohibition is a definitive policy decision.¶

actor_unauthorized:

Use when the request fails a remediable actor-policy check for the (sub, act.sub) pair in the requested transaction, including the newly authenticated presenter the TTS would install as the new outermost actor. Examples include: the act.sub_profile of an inbound actor is not in the accepted set for this TTS, or the delegation relationship required by local policy is absent or could not be confirmed from current inputs. As with the equivalent AS error code (Section 8.1), this code signals an input-contingent actor-policy mismatch rather than a structural, credential, or explicit deny decision.¶

The error_description field SHOULD be included and SHOULD describe which aspect of actor-profile processing failed, to the extent permitted by the TTS's security and privacy policy.¶

9.1. Actor Authorization Model

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

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

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

Actor authorization at the resource server evaluates both principals and the relationship between them, that is, whether the outermost actor is authorized to act on behalf of the subject. This specification describes subject-plus-actor evaluation as one approach for resource servers; it does not require every RS to implement or enforce actor authorization.¶

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

This specification defines subject-plus-actor evaluation as the interoperable baseline. Deployments MAY apply multi-principal authorization under local policy by considering one or more nested act objects as additional trust or risk inputs in addition to sub and the outermost act.sub, but this specification does not standardize such authorization behavior, and clients MUST NOT assume that nested actors will be used for authorization unless deployment-specific agreements say otherwise.¶

9.2. Subject-Plus-Actor Evaluation

Actor authorization is OPTIONAL for delegated tokens under this profile. 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 subject-plus-actor policy:¶

1. Advertise requirements: An RS that wants to signal actor-authorization expectations to clients SHOULD set actor_authorization_required: true (Section 10.2.3). An RS that does not advertise this value MAY still apply subject-plus-actor evaluation, but clients MUST NOT rely on that behavior.¶

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

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

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

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

   • the token's scope claim.¶

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

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

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

When a deployment applies multi-principal authorization under local policy, the outermost act.sub remains the baseline interoperable actor identifier, while nested act objects are additional local-policy inputs only. Failure semantics, ordering, and weighting for those nested actors are deployment-specific.¶

9.3. JWT Access Token Resource Server Processing

Upon receiving a JWT access token on a request path where delegated-token processing may apply, a resource server MUST validate and process that token according to its local delegated-token policy. The authorization-policy model for delegated tokens is defined in Section 9. Protected resource metadata can advertise delegated-token expectations to clients, but the RS's enforcement decision remains local to the resource server.¶

When the resource server accepts delegated tokens, it MUST:¶

1. Validate the token's signature, iss, aud, and temporal claims per [RFC9068]. If local policy for the request path requires actor-profile conformance, including when the resource advertises actor_profile_required: true (Section 10.2.3), and the token carries no act claim or carries an act object missing act.iss, the RS MUST reject the request with HTTP 401 invalid_token.¶

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

   • Note: When delegation is present, the key identified in cnf.jkt is the key of the outermost actor (the immediate bearer), since the outermost actor is the current presenter.¶

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

4. If the token carries client_id, azp, or both, treat those as client-identity inputs only. In interoperable processing, the RS SHOULD use act.sub rather than client_id or azp as the actor identifier when act is present. Deployments that rely on client identity as a substitute actor signal are outside the interoperable scope of this profile. When local policy expects both to identify the same acting party, the RS SHOULD verify semantic consistency; if that consistency cannot be established, the RS MUST either treat them as distinct identifiers or reject the request according to local policy. See Section 12.2.¶

5. Apply actor authorization per Section 9.2 when required by local policy. Resource servers that do not require actor authorization SHOULD still evaluate the actor as part of authorization, audit, or trust decisions.¶

6. Optionally traverse inner act objects to audit the full delegation chain; inner actors are prior-actor context and MUST NOT be required to present proof of possession at the resource server.¶

7. If the resource server relies on inner act objects for audit, policy refinement, or trust decisions, it MUST do so only after validating the outer token issuer and only when local policy trusts that issuer to carry forward the asserted delegation chain. The RS MUST NOT treat nested actor issuers as independently authenticated merely because their identifiers appear in inner act.iss values. Under this profile, interoperable authorization behavior is defined around sub and the outermost act.sub; use of nested actors for access control is deployment-specific.¶

8. If any of the above steps fail, return an appropriate error response per [RFC6750], Section 3.1:¶

   • If signature, iss, aud, or temporal validation fails: HTTP 401 with WWW-Authenticate: Bearer error="invalid_token".¶

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

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

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

9.4. Transaction Token Resource Server Processing

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

When the resource server accepts delegated Transaction Tokens, it MUST:¶

1. Validate the Transaction Token per [I-D.ietf-oauth-transaction-tokens] and local deployment profile: signature, aud, temporal claims, and issuer identification. When the token carries an act claim, the top-level iss claim MUST be present and the RS MUST validate it as the Transaction Token issuer identifier. When the token carries no act claim and iss is absent, the RS MUST determine the issuer using the trust-domain and issuer-identification rules of [I-D.ietf-oauth-transaction-tokens] and local deployment configuration. If local policy for the request path requires actor-profile conformance, including when the resource advertises actor_profile_required: true (Section 10.2.3), and the token carries no act claim or carries an act object missing act.iss, the RS MUST reject the request.¶

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

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

4. Apply actor authorization per Section 9.2 when required by local policy. Resource servers that do not require actor authorization SHOULD still evaluate the actor as part of authorization, audit, or trust decisions.¶

5. Optionally traverse inner act objects to audit the full delegation chain. If the RS relies on inner act objects for audit, policy refinement, or trust decisions, it MUST do so only after validating the outer token issuer and only when local policy trusts that issuer to carry forward the asserted delegation chain. The RS MUST NOT treat nested actor issuers as independently authenticated merely because their identifiers appear in inner act.iss values.¶

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

9.5. Token Introspection

When token introspection ([RFC7662]) is used, an AS that issues delegated tokens MUST include the act claim and top-level sub_profile claim in introspection responses for active tokens that carry those claims. The AS MUST NOT omit actor profile claims from introspection responses, as their omission would misrepresent the delegation status of the token to the introspecting RS. When a delegated token carries a nested act chain (delegation depth greater than 1), the AS MUST include the complete nested act structure in the introspection response unless local privacy policy requires omitting specific inner chain entries.¶

When local privacy policy requires omitting specific inner chain entries, the AS MAY return a filtered act chain but MUST include "chain_complete": false in the introspection response to signal that the chain is incomplete. When chain_complete is absent from the introspection response, the RS SHOULD treat the chain as complete unless local policy or deployment context indicates otherwise (for example, a known introspection proxy that does not emit chain_complete). An RS that requires a guaranteed-complete chain for its authorization policy SHOULD explicitly require chain_complete: true rather than relying on absence. An introspecting RS that receives "chain_complete": false MUST NOT treat the partial chain as a faithful representation of the complete delegation history; it SHOULD apply more conservative policy and MAY reject the request when its local policy requires a complete delegation chain.¶

Opaque access tokens are not conformant to this profile as token formats. When an AS issues a delegated opaque access token and supports introspection, it MAY expose equivalent actor-profile information through introspection for RS processing. This is a deployment-specific compatibility mechanism for opaque tokens; it does not make the opaque token itself conformant to this profile, and support for this path MUST NOT be inferred solely from actor_profile_required or actor_authorization_required metadata. When used, the following claims define the minimum equivalent introspection semantics for active delegated tokens:¶

• active: REQUIRED. MUST be true for an active token.¶

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

• act: REQUIRED. The actor object conforming to Section 3.6, including act.sub, act.iss, and any nested act chain, structured identically to the JWT form defined in this document. When local privacy policy causes inner chain entries to be omitted, chain_complete MUST be set to false.¶

• chain_complete: OPTIONAL. A boolean. 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.¶

• sub_profile: REQUIRED 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.¶

The AS MUST NOT omit the act claim or sub_profile from the introspection response when those claims are part of the delegated token's authorization context. An introspecting RS MUST apply the same delegated-token processing to this response as it would to a directly validated JWT access token carrying equivalent claims.¶

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

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

9.6. Policy Claims Summary

The following claims are available as subject-plus-actor policy inputs:¶

10.1. OAuth Entity Profile Usage

[I-D.mora-oauth-entity-profiles] defines the OAuth Entity Profiles mechanism, including the sub_profile and client_profile JWT claims, the entity_profiles_supported AS metadata parameter with its client, subject, and actor arrays, and an IANA registry of entity profile values with associated usage locations, including the "Actor Profile" usage location. It also explicitly defines sub_profile within act (Actor) nodes per [RFC8693] for classification of delegated actors in delegation chains.¶

This document uses the actor profile support defined in [I-D.mora-oauth-entity-profiles]. The sub_profile claim within an act object classifies the entity identified by act.sub, using values registered with the "Actor Profile" usage location in the "OAuth Entity Profiles" registry. The entity_profiles_supported.actor array in AS metadata advertises which actor entity profile values are accepted, as defined in [I-D.mora-oauth-entity-profiles].¶

The values registered for actor use are defined in [I-D.mora-oauth-entity-profiles]. Values within act.sub_profile MUST be either registered with the "Actor Profile" usage location in the "OAuth Entity Profiles" registry or privately defined collision-resistant values (see Section 3.6). When processing act.sub_profile, issuers and consumers MUST treat registered values according to the entity profile semantics defined in [I-D.mora-oauth-entity-profiles] and MUST NOT reject tokens solely because a value is unrecognized (see Section 3.7).¶

This document makes no independent requests to the "OAuth Entity Profiles" registry; all actor-profile-related registry definitions are provided by [I-D.mora-oauth-entity-profiles].¶

10.2. Discovery and Capability Negotiation

{
  "issuer": "https://as.enterprise.example",
  "token_endpoint": "https://as.enterprise.example/token",
  "grant_types_supported": [
    "urn:ietf:params:oauth:grant-type:token-exchange",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "dpop_signing_alg_values_supported": ["ES256", "RS256"],
  "actor_profile_token_types_supported": [
    "urn:ietf:params:oauth:token-type:access_token",
    "urn:ietf:params:oauth:token-type:jwt",
    "urn:ietf:params:oauth:token-type:txn_token"
  ],
  "actor_profile_actor_token_profiles_supported": [
    "jwt_access_token",
    "jwt_client_assertion",
    "workload_identity_jwt"
  ],
  "actor_profile_max_chain_depth": 5,
  "entity_profiles_supported": {
    "client": ["service", "ai_agent"],
    "subject": ["user", "service", "ai_agent"],
    "actor":   ["user", "service", "ai_agent"]
  }
}

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

11.1. Backwards Compatibility

This profile extends the base act claim semantics from [RFC8693] by unconditionally requiring iss in every act object, and by defining sub_profile and optional actor-scoped confirmation semantics. Deployments that receive an act object that conforms only to [RFC8693] but omits this profile's required members MUST treat that actor object as not conforming to this profile.¶

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

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

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

2. Update consumers to validate act.iss per Section 3.6 once issuers have deployed step 1.¶

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

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

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

• If local policy or advertised metadata requires actor-profile conformance for the request path, the AS MUST reject the request. It MUST return invalid_request consistent with Section 8.1.¶

• If actor-profile conformance is not required, the AS MAY process the inbound act object under local policy only for non-profile behavior. It MUST NOT rewrite an inherited actor entry to add act.iss, and it MUST NOT omit the inbound act claim from an issued token that would otherwise preserve or extend the chain under this profile. Any request path that would preserve or extend such a non-conforming chain into an actor-profile token MUST be rejected.¶

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

11.2. Refresh Token Issuance Considerations

This document does not standardize whether an AS issues refresh tokens in response to delegated JWT assertion grant requests, how such refresh tokens are revoked, or whether later use of such refresh tokens requires re-presentation of upstream delegation artifacts. Those decisions remain deployment-specific. When a refresh token is later used to obtain a delegated output token, the actor-profile rules in Section 6.1.5.2 and the output-token rules of this document apply.¶

11.3. Establishing act.iss Namespace Authority

This profile requires issuers and consumers to determine whether act.iss is authoritative for the identifier namespace of act.sub, but it does not define a universal validation algorithm. That determination depends on a trusted framework or local policy.¶

Examples of local validation approaches include:¶

• federation metadata that lists act.iss as authoritative for the namespace containing act.sub (for example, [OpenID.Federation]);¶

• pre-registration entries that explicitly authorize act.iss to assert identifiers of the form used in act.sub; and¶

• bilateral or deployment-local policy rules that authorize act.iss to assert the specific class of identifier used in act.sub.¶

For HTTPS URI identifiers, one common local rule is URL namespace containment. Under that style of rule, deployments often treat act.iss as authoritative when the scheme, host, and port of act.iss and act.sub match, or when act.sub falls within a path prefix of act.iss that has been explicitly configured as authoritative. In those deployments, scheme and host comparison typically follows the case-insensitive rules in [RFC3986], Section 3.2.2, while path-prefix matching is usually case-sensitive and boundary-aware. Subdomain relationships alone are often insufficient to establish authority without explicit configuration.¶

Examples:¶

• act.iss = https://as.enterprise.example and act.sub = https://as.enterprise.example/agents/travel-assistant would commonly be treated as authoritative under a same-host local rule.¶

• act.iss = https://as.enterprise.example and act.sub = https://idp.enterprise.example/users/alice would not ordinarily be treated as authoritative by URL containment alone, because the host differs.¶

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

11.4. Migration from Implicit to Explicit Delegation

The invariant of this document is that client_id identifies the OAuth client registration, sub identifies the authorizing principal, and act.sub is the authoritative actor identity signal when delegation is present. Migration from implicit delegation is the process of making this distinction explicit in tokens where these roles were previously conflated through client_id or inferred from token-request context.¶

Deployments that currently rely on implicit delegation can migrate incrementally to this profile. During migration, existing client-oriented inputs such as client_id, azp, and authenticated client context MAY remain in use, but the outermost act.sub becomes the authoritative explicit delegation signal whenever act is present. A common transition pattern is to emit both legacy client-oriented identifiers and explicit actor claims during rollout, measure and reconcile mismatches, and then require act where explicit delegation is needed.¶

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

One safe migration pattern is:¶

• If act is present, use the outermost act.sub as the authoritative delegated-actor signal.¶

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

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

• If both explicit and implicit signals are present and local policy expects them to identify the same party under trusted local mapping rules, implementations SHOULD apply those mapping rules and either reconcile the identifiers or treat them as distinct according to local policy.¶

• If both are present and no such equivalence rule exists, implementations SHOULD treat them as distinct identifiers with different semantics rather than infer equivalence.¶

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

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

Legacy implicit form:¶

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

Explicit form:¶

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

client_id and azp remain as auxiliary client-identity inputs; act.sub is the authoritative delegation signal. When local policy expects both to identify the same party under trusted local mapping rules, implementations SHOULD attempt to reconcile them under those rules; otherwise they SHOULD be treated as distinct or rejected according to local policy.¶

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

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

An AS or RS that expected the client and actor to identify the same party under trusted local mapping rules would typically reject this token unless those rules explicitly bind travel-assistant-client-id to https://agents.other-provider.example/concierge-bot. If no such mapping rule exists, the safer interpretation is to treat the identifiers as distinct.¶

12.1. Delegation Chain Integrity and Trust

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

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

The act.iss values in inner act objects are assertion-based prior-actor context set by whoever constructed those objects at an earlier hop, not by the issuer of the current token. Implementations MUST NOT treat an inner act.iss as independently authenticated merely because it appears in the token; the trust basis is the outer token issuer's endorsement. Consequently: an RS that relies on inner act.iss for audit or policy MUST do so only when it trusts the outer issuer to have validated and faithfully propagated that chain; ASes that propagate inner chains SHOULD validate inner act.sub and act.iss entries only when local policy chooses to use those entries as additional inputs to issuance decisions per Section 4.2 step 5; and security policies relying on inner actor identities for access control SHOULD be treated as lower-assurance and deployment-specific relative to policies based on the outermost act.sub.¶

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

12.2. Client Identity and Delegation

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

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

• When a single client_id registration fronts multiple distinct acting entities (for example, an agent orchestration platform executing requests on behalf of different agent instances), client_id alone does not identify the runtime actor. Each such request SHOULD carry act.sub identifying the specific acting principal; deployments that rely on client_id alone for actor distinction in this scenario are operating outside the interoperable scope of this profile.¶

• During token issuance, client_id and azp MUST NOT be rewritten to represent delegation state that belongs in act; see Section 6.3.2 for propagation rules.¶

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

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

The detailed migration rules and transition patterns are defined in Section 11.4.¶

12.3. Presenter Binding

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

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

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

This document does not define per-hop actor-key provenance within the delegation chain. Stronger assurance for prior-hop provenance would require an additional mechanism outside the scope of this document, such as signed hop receipts, transparency-log-based recording, or another future extension.¶

12.4. Delegation Depth Limits

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

12.5. Sub_profile Trust

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

12.6. Delegation Revocation

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

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

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

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

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

12.7. Confused Deputy

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

12.8. Actor-Authorization Bypass

A resource server that advertises actor_authorization_required: true but fails to enforce authorization of the (sub, outermost act.sub) pair on the request paths where clients are expected to rely on that signal allows an attacker to bypass that expectation by exploiting gaps in the enforcement logic. Resource servers that require such authorization SHOULD advertise that behavior using actor_authorization_required: true and SHOULD apply the evaluation on every request path where they intend that metadata signal to be relied upon, including introspection-based validation paths when used. Deployments that choose not to align metadata and enforcement on some request paths SHOULD document that choice explicitly so that clients do not over-read the signal.¶

12.9. Subject Namespace Translation

Several processing rules in this document tolerate an AS re-expressing sub in a different identifier namespace when local deployment policy treats the identifiers as referring to the same subject (see Section 6.3.2 step 2 and Section 7.4 step 1). This document does not standardize subject-translation mechanisms or proof of equivalence between subject namespaces. Such translation creates a subject-substitution risk: a malicious or misconfigured AS could map sub to a different entity in the new namespace, silently replacing the authorized principal with a different one.¶

Mitigations:¶

• Receiving ASes and RSes SHOULD NOT accept sub translations from ASes they do not trust to authoritatively map identifiers between the two namespaces. Trust for namespace mapping is separate from trust for token signing and SHOULD be established explicitly in local policy.¶

• Subject-namespace translation is a high-assurance operation and SHOULD be used only when the issuer has authoritative mapping information for both the original and translated namespaces.¶

• When an AS translates sub, it SHOULD include both the original and translated identifiers, or otherwise provide enough context for the receiving party to verify the mapping, where local policy requires such verification.¶

• RSes that enforce access control against a specific sub value SHOULD verify that the issuing AS is authoritative for the subject-identifier namespace used, and SHOULD NOT accept subject identifiers from namespaces for which the issuing AS is not authoritative.¶

• If the receiving party cannot validate or otherwise trust that the translated sub still refers to the same underlying subject, it SHOULD reject the token rather than treat the translation as advisory.¶

12.10. Negative Examples

The following abbreviated examples illustrate rejection cases that implementations are expected to handle:¶

{
  "iss": "https://as.resource-domain.example",
  "sub": "https://idp.example.com/users/alice",
  "act": {
    "sub": "urn:workload:booking-tool",
    "iss": "https://unrelated.example"
  }
}

{
  "iss": "https://as.example.com",
  "sub": "https://idp.example.com/users/alice",
  "act": {
    "sub": "https://agents.example.com/travel-assistant"
  }
}

{
  "iss": "https://as.example.com",
  "sub": "https://idp.example.com/users/alice",
  "aud": "https://api.example.com",
  "scope": "payments:create",
  "act": {
    "sub": "https://agents.example.com/travel-assistant",
    "iss": "https://as.example.com",
    "sub_profile": "ai_agent"
  }
}

12.11. Token Substitution

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

14.1. OAuth Authorization Server Metadata Registry

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

• Metadata Name: actor_profile_token_types_supported¶

• Metadata Description: JSON array of delegated output token-type URIs that the AS can issue while applying actor-profile processing per this document¶

• Change Controller: IETF¶

• Reference: Section 10.2.2 of this document¶

• Metadata Name: actor_profile_actor_token_profiles_supported¶

• Metadata Description: JSON array of advertised actor_token credential profiles that the AS accepts for Token Exchange under this profile¶

• Change Controller: IETF¶

• Reference: Section 10.2.2 of this document¶

• Metadata Name: actor_profile_max_chain_depth¶

• Metadata Description: Positive integer indicating the maximum delegation chain depth the AS will accept in inbound tokens and produce in issued tokens under this profile¶

• Change Controller: IETF¶

• Reference: Section 10.2.2 of this document¶

14.2. OAuth Protected Resource Metadata Registry

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

• Metadata Name: actor_profile_required¶

• 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: Section 10.2.3 of this document¶

• Metadata Name: actor_authorization_required¶

• Metadata Description: Boolean indicating whether the RS advertises that it evaluates the actor as an authorization input in addition to the subject for delegated tokens¶

• Change Controller: IETF¶

• Reference: Section 10.2.3 of this document¶

• Metadata Name: actor_profile_max_chain_depth¶

• Metadata Description: Positive integer indicating the maximum delegation chain depth the RS will accept in tokens presented to it¶

• Change Controller: IETF¶

• Reference: Section 10.2.3 of this document¶

14.3. OAuth Error Registry

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

• Error Name: actor_unauthorized¶

• Error Usage Location: Token endpoint response, resource server response¶

• Related Protocol Extension: OAuth Actor Profile for Delegation¶

• Change Controller: IETF¶

• Reference: Section 8.1 of this document¶

14.4. OAuth Token Introspection Response Registry

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

• Claim Name: chain_complete¶

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

• Change Controller: IETF¶

• Reference: Section 9.5 of this document¶

14.5. JWT Claims Registry

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

14.6. OAuth Entity Profiles Registry

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

15.1. Normative References

[RFC3986]

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

[RFC6750]

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

[RFC7009]

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

[RFC7519]

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

[RFC7517]

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

[RFC7521]

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

[RFC7523]

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

[RFC8705]

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

[RFC7662]

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

[RFC7800]

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

[RFC8126]

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

[RFC8414]

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

[RFC9728]

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

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/info/rfc8693>.

[RFC9068]

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

[RFC8707]

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

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/info/rfc9449>.

[I-D.ietf-oauth-transaction-tokens]

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

[I-D.ietf-wimse-workload-creds]

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

[I-D.ietf-wimse-wpt]

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

[I-D.mora-oauth-entity-profiles]

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

[RFC2119]

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

[RFC8174]

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

15.2. Informative References

[RFC9493]

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

[RFC6749]

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

[RFC9700]

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

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., and B. Campbell, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-08, 9 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-08>.

[I-D.ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", 2 March 2026, <https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-02.txt>.

[I-D.ietf-oauth-security-topics]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-29, 3 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29>.

[OpenID.Core]

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

[OpenID.Federation]

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

A.1. Scenario

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

A.2. Access Token

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

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

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

A.3. Transaction Token

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

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

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

B.1. Scenario and Parties

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

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

Presenter key bindings:¶

B.2. Discovery and Capability Negotiation

The agent consults the Travel Provider AS metadata (Section 10.2) as an advisory compatibility check before initiating the flow:¶

{
  "issuer": "https://as.travel-provider.example",
  "actor_profile_token_types_supported": [
    "urn:ietf:params:oauth:token-type:jwt",
    "urn:ietf:params:oauth:token-type:access_token",
    "urn:ietf:params:oauth:token-type:txn_token"
  ],
  "entity_profiles_supported": {
    "subject": ["user", "ai_agent"],
    "actor":   ["user", "ai_agent", "service"]
  }
}

The agent observes that its sub_profile (ai_agent) is listed in entity_profiles_supported.actor and that delegated JWT assertion grants and delegated access tokens are advertised as output types in actor_profile_token_types_supported. These metadata do not by themselves advertise acceptance of JWT subject_token or JWT actor_token inputs, and they do not by themselves advertise support for the more specific ID-JAG token type used later in this flow. Together with grant_types_supported, the ID-JAG specification, and deployment documentation, they indicate that the delegated-token path is plausibly compatible with the Booking Tool RS's advertised requirements.¶

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

Alice authenticates to the Enterprise IdP AS. The profile-relevant claim is sub_profile, which propagates Alice's entity type into downstream tokens:¶

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

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

The agent presents Alice's ID Token to the Enterprise IdP AS using Token Exchange. In this example, the same JWT is used both as the RFC 7523 client_assertion and as the Token Exchange actor_token, making the authenticated client's actor identity explicit. The Enterprise IdP AS authenticates the client as https://agents.enterprise.example/travel-assistant, verifies that the ID Token audience matches that client, and uses local delegation policy plus that explicit actor credential to construct the actor-profile claims in the issued ID-JAG:¶

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

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

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

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

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

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

The agent presents the ID-JAG as a JWT Bearer authorization grant ([RFC7523]) to the Travel Provider AS. In this usage, the ID-JAG functions as a profiled JWT assertion grant, so the processing rules in Section 4.2 apply to it:¶

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

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

The Travel Provider AS performs actor-profile processing per Section 4.2: 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 an access token preserving the actor chain:¶

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

Alice's sub and sub_profile are preserved verbatim from the ID-JAG (Section 6.3.2). The Travel Provider AS does not translate or substitute the enterprise subject identifier. The client_id and azp values continue to identify the OAuth client, but they do not replace act.sub as the authoritative delegated-actor identifier.¶

B.6. Step 4: Agent Calls Booking Tool API

The agent presents the access token with a DPoP proof:¶

POST /bookings HTTP/1.1
Host: api.travel-provider.example
Authorization: DPoP <tp-access-token>
DPoP: <AgentJKT-proof>
Content-Type: application/json

{"origin": "SFO", "destination": "NYC", "depart": "2026-04-15"}

The Booking Tool RS applies authorization of the (sub, outermost act.sub) pair (Section 9): it evaluates Alice (sub, sub_profile: user) together with the Travel Assistant (act.sub, sub_profile: ai_agent) for the requested operation. Because the RS advertises actor_authorization_required: true, the (sub, outermost act.sub) relationship MUST satisfy local policy. The act.sub_profile value is checked against entity_profiles_supported.actor per Section 10.1.¶

B.7. Step 5: Booking Tool Exchanges Access Token for Transaction Token

The Booking Tool cannot reuse the received access token for internal calls: it is sender-constrained to AgentJKT, which the Booking Tool does not possess. It requests a Transaction Token from the TTS. In this example, the TTS receives the Booking Tool's WIMSE Workload Identity Token (WIT) as the Token Exchange actor_token and validates a Workload Proof Token (WPT). The WIT identifies the Booking Tool and carries its confirmation key, while the WPT proves possession of that key and binds the request to the accompanying access token:¶

POST /token HTTP/1.1
Host: tts.travel-provider.example
Content-Type: application/x-www-form-urlencoded
Workload-Proof-Token: <tool-wpt-with-wth-and-ath>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=<tp-access-token>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&actor_token=<booking-tool-wit>
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn_token
&audience=https%3A%2F%2Ftravel-provider.example
&scope=inventory%3Acheck
&rctx={"req_ip":"198.51.100.42"}

The WIT is therefore the JWT actor_token defined by this profile, while the WPT provides the accompanying proof of possession required by the workload-credential profile.¶

The TTS applies actor-profile processing per Section 7.4: it preserves sub and sub_profile from the subject token, sets req_wl to the authenticated Booking Tool, and creates a new outermost act object for the Booking Tool while nesting the subject token's existing act claim beneath it. In this WIMSE-based deployment, the underlying Transaction Token mechanism also binds the issued token to the Booking Tool's presenter key (ToolJKT) identified in the WIT confirmation claim:¶

{
  "iss": "https://tts.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "sub_profile": "user",
  "scope": "inventory:check",
  "req_wl": "https://tools.travel-provider.example/booking-tool",
  "aud": "https://travel-provider.example",
  "jti": "txn-tok-20260401-001",
  "txn": "550e8400-e29b-41d4-a716-446655440001",
  "exp": 1743375750,
  "iat": 1743375650,
  "tctx": {
    "action": "check-availability",
    "origin": "SFO",
    "destination": "NYC",
    "depart": "2026-04-15"
  },
  "rctx": { "req_ip": "198.51.100.42" },
  "cnf": { "jkt": "ToolJKT-0ZcOCORZNYy9ZhHi" },
  "act": {
    "sub": "https://tools.travel-provider.example/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service",
    "act": {
      "sub": "https://agents.enterprise.example/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent"
    }
  }
}

The presenter binding rotates at this step: cnf.jkt is now ToolJKT because the Booking Tool is the current presenter. The nested actor chain records that the Booking Tool is now the current actor and that the Travel Assistant was the prior delegated actor.¶

B.8. Step 6: Booking Tool Calls Inventory Service

GET /inventory?origin=SFO&dest=NYC&depart=2026-04-15 HTTP/1.1
Host: internal.travel-provider.example
Txn-Token: <txn-token>
Workload-Identity-Token: <booking-tool-wit>
Workload-Proof-Token: <tool-wpt-with-wth-and-tth>

The Inventory Service validates the WIT and WPT according to the WIMSE specifications: the WPT proves possession of the key identified by the WIT, wth binds the proof to the presented WIT, and tth binds it to the presented Transaction Token. The Inventory Service then applies authorization of the (sub, outermost act.sub) pair (Section 9): Alice (sub) governs data access policy (e.g., travel tier), and the Booking Tool (act.sub) is the authorized internal workload for that request. The req_wl claim provides consistent TTS workload context for the same service in this example. The nested act.act.sub (Travel Assistant) is carried as prior delegation context and is not evaluated for access control at this internal tier, consistent with the guidance on inner actors in Section 9.2.¶

B.9. Summary of Token Transformations

Key observations:¶

• In this example, sub (Alice) is unchanged across all trust domains and token transformations.¶

• The presenter-binding key rotates once, at Step 5 when the TTS re-binds the Transaction Token to the Booking Tool's key.¶

• At Step 5 the TTS creates a new outermost act for the Booking Tool and nests the prior act chain beneath it.¶