OAuth Actor Profile for Delegation

1.1. Illustrative Use Case

Alice authorizes an AI agent to book a business trip on her behalf. The agent calls an external booking tool operated in a separate organizational trust domain. The flow is:¶

1. Alice authenticates at her enterprise identity provider authorization server (Enterprise IdP AS), and the agent obtains an ID Token establishing Alice's identity. This authentication step is out of scope for this document; the processing described here begins when the Enterprise IdP AS receives the upstream credential.¶

2. The agent exchanges the ID Token at the Enterprise IdP AS to obtain an Identity Assertion JWT Authorization Grant (ID-JAG): a JWT produced by token exchange that carries Alice's identity, the agent's actor profile, and an audience bound to the external tool AS's token endpoint. When the agent later presents that JWT to another AS using the JWT bearer grant, the JWT functions as a profiled JWT assertion grant.¶

3. The agent submits the ID-JAG as a JWT bearer authorization grant to the external tool's AS token endpoint. The tool AS validates the enterprise chain and issues an access token for the external tool's API.¶

4. The agent calls the external tool's API using that access token.¶

5. The external tool exchanges the received access token at its Transaction Token Service (TTS) to obtain a Transaction Token for a backend internal service call, with the issued token rebound to the tool as the new presenter under the Transaction Token deployment's proof mechanism rather than the agent's.¶

6. The tool calls the internal service using the Transaction Token.¶

At each step, Alice's identity is preserved as sub, the agent's identity is preserved in act, the current presenter holds a key-bound token, and the trust-domain boundary enforcer (the tool AS) re-issues the credential under local control.¶

1.2. How to Read This Document

This document is organized for multiple audiences. Readers may find it useful to navigate directly to the sections most relevant to their role:¶

• Client or agent implementors (building an agent or workload that obtains and presents delegated tokens): start with Section 4 for the actor object structure and claim semantics, then Section 5 for how to construct and submit an assertion grant, Section 10 for how to check whether a target AS and RS support this profile before making a request, and Appendix A for a complete worked example.¶

• Authorization server implementors (building an AS that accepts assertion grants or issues delegated tokens): start with Section 4, then Section 5.2 for the full validation and issuance steps, Section 6.2 for how actor information must be preserved across token transformations, and Section 7.3 for Transaction Token issuance.¶

• Resource server implementors (building an API that receives and validates delegated tokens): start with Section 4 for claim semantics, then Section 6.3 for validation steps and error responses, and Section 8 for authorization policy guidance.¶

• Deployers and architects (evaluating the profile or planning a deployment): start with Section 4, then Section 10 for metadata and capability negotiation, Section 10.5 for migration from implicit delegation, and Appendix A for a full end-to-end flow.¶

Readers unfamiliar with the underlying specifications should consult [RFC8693] for Token Exchange, [RFC9068] for JWT-formatted access tokens, [RFC9449] for DPoP, and [I-D.ietf-oauth-transaction-tokens] for Transaction Tokens.¶

3.1. Overloaded Subject Semantics

The sub claim of a JWT access token [RFC9068] is routinely overloaded to represent heterogeneous entity types: an end-user, a service account, a workload identifier, or an AI agent. Resource servers must rely on out-of-band conventions or proprietary claim extensions to determine which type of entity sub refers to. This ambiguity prevents deterministic cross-domain policy evaluation.¶

3.2. Inconsistent Actor Representation

[RFC8693] defines the act claim for tokens obtained via token exchange but does not extend its semantics to JWT assertion grants or JWT access tokens issued by other means. Deployments that do not use token exchange (for example, those using JWT client assertions for service-to-service calls) have no standard location for actor information. Even when act is present, there is no standard sub-claim that identifies the entity type of the actor.¶

Many existing deployments rely on implicit delegation: the OAuth client identity (client_id, azp, or authenticated client context at the token endpoint) is treated as evidence of the acting party, and authorization policy infers delegation from the fact that the client obtained or presented the token. That approach can work within tightly controlled deployments, but it does not explicitly encode the delegated actor relationship in the token itself and is not portable across issuers, token transformations, or resource servers. This specification defines explicit delegation by representing the delegated actor directly in act, while allowing authenticated client identity to remain an authorization input where needed.¶

In simple deployments, the OAuth client is often treated in practice as the effective initial actor because it obtained, redeemed, or presented the token. However, that is a deployment assumption rather than a universal protocol rule. The client_id identifies the OAuth client registration, not necessarily the concrete acting instance or operational principal. Shared-client deployments, backend-for-frontend patterns, multi-tier applications, device-bound instances, and agent or plugin execution are all cases where the OAuth client and the delegated actor can diverge even in non-token-exchange flows.¶

3.3. Missing Proof-of-Possession Binding for Actors

Sender-constrained tokens [RFC9449][RFC8705] bind the token to a proof-of-possession key identified in the top-level cnf claim. When delegation is present, the presenter is the actor, not the original subject. There is no standard mechanism to separately bind the actor's key within the act claim, leaving implementations to use the top-level cnf for both the token holder and the actor simultaneously, which is semantically ambiguous in chained delegation scenarios.¶

3.4. No Cross-Token Profile Consistency

JWT assertion grants, JWT access tokens, and Transaction Tokens are specified in different documents with different claim conventions. There is no common profile that spans all three and specifies how actor information flows from an assertion presented to an AS through to the access token issued by that AS and into any downstream Transaction Token.¶

3.5. Absent Discovery and Capability Negotiation

Neither AS metadata [RFC8414] nor Protected Resource Metadata [RFC9728] define parameters for advertising actor-profile support. Deployments therefore require bilateral out-of-band configuration, which is impractical for AI agents that dynamically discover and invoke tools across organizational boundaries.¶

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

The actor profile is applicable to:¶

• JWT assertion grants (Section 5)¶

• JWT-formatted access tokens (Section 6)¶

• Transaction Tokens (Section 7)¶

Subject to endpoint policy and the underlying token-exchange or grant mechanism, implementations MAY transform any supported input token type into any other supported output token type. When they do so, actor profile information MUST be preserved and validated as specified in this document for the resulting token type.¶

For a complete worked example showing the actor profile in use across all three token types in a cross-domain flow, see Appendix A.¶

4.2. Scope of This Profile

This document standardizes the structure and processing of actor-profile claims when they are carried in supported token types. In particular, it standardizes:¶

• the actor object structure and its claim semantics,¶

• how actor-profile information is preserved across supported token transformations,¶

• how authorization servers and resource servers validate and consume those claims, and¶

• the metadata used to advertise actor-profile support.¶

This document does not standardize:¶

• which token transformations a given authorization server or TTS must support,¶

• the local policy by which a subject authorizes a specific actor,¶

• the trust framework by which one domain decides to trust another domain's issuer, or¶

• the identifier-mapping logic by which different namespaces are determined to refer to the same logical entity.¶

Those decisions remain deployment- and policy-specific, except where a referenced specification defines them more precisely.¶

In particular, this specification standardizes the representation and processing of actor information once an issuer has determined the acting party. It does not standardize every upstream proof mechanism by which that determination is made. Deployments MAY derive actor information from authenticated client context, local delegation policy, pre-registered grants, or other trusted deployment-specific inputs, but those inputs are not themselves made interoperable by this specification. Clients therefore SHOULD prefer acquisition paths that produce explicit actor-profile claims when such paths are available and understood to be supported, and SHOULD treat AS-derived actor determination as deployment-specific behavior unless documented otherwise.¶

This matters especially for grant types such as the authorization code flow, where the base protocol does not define a general interoperable request parameter for an actor distinct from the OAuth client. In such cases, an issuer may still determine a delegated actor from stronger deployment-specific evidence and represent that actor explicitly in act, but the absence of such evidence MUST NOT be interpreted as meaning that the OAuth client automatically defines the delegated actor.¶

4.3. Implementation Summary

The following table summarizes the minimum implementation obligations by role:¶

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

iss:

REQUIRED. The issuer namespace that is authoritative for the actor identifier carried in act.sub. This value scopes act.sub to an issuer namespace so that relying parties can distinguish otherwise-colliding subject identifiers across domains. It identifies the authority for the actor identifier itself, not merely the token issuer that copied or conveyed the claim. act.iss answers the question "who owns the namespace in which this act.sub value is meaningful?" rather than "who issued the enclosing token?" 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].¶

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. In that case, the token issuer and the actor-identifier authority differ, and both values are valid in their respective roles.¶

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 MUST be drawn from the OAuth Entity Profiles registry in Section 14.1 of [I-D.mora-oauth-entity-profiles] or be privately defined collision-resistant values. Only values registered with the "Actor Profile" usage location (defined in Section 9) SHOULD be used within act objects. 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 4.5.¶

cnf:

OPTIONAL. A confirmation claim as defined in [RFC7800]. When present, this value records keying material associated with the actor identified by this act object. It is primarily useful for audit, visibility, diagnostics, and optional local policy when delegation chains are propagated across token transformations. It is distinct from the top-level cnf claim, which identifies the keying material the current presenter of the overall token MUST use to demonstrate proof of possession. Recipients MUST NOT treat nested act.cnf values as active presenter-binding requirements for the current token. When a public key is conveyed in act.cnf, the jkt member is RECOMMENDED.¶

The intended use of act.cnf under "optional local policy" is: when an AS receives an inbound assertion whose outermost act object carries cnf.jkt, the AS MAY use that value as the expected key for the actor-as-current-presenter, to check that the inbound DPoP proof was signed by the same key the actor declared in the assertion. This is a local policy choice, not a general protocol requirement. An AS that supports this check SHOULD document it in its deployment guide and SHOULD return invalid_grant when the check is required and fails. This use applies only to the outermost act; act.cnf values in nested inner objects are key history only and MUST NOT be used to drive proof-of-possession checks at any layer.¶

4.5. Forward Compatibility for sub_profile Values

Because the OAuth Entity Profiles registry is extensible, implementations will encounter sub_profile values that were not defined when the implementation was built. The following rules govern handling of unrecognized values:¶

• An AS or RS that does not recognize a sub_profile value MUST NOT reject the token or assertion solely on that basis. The value MUST be treated as an opaque string and preserved without modification when the token is transformed or propagated.¶

• When local policy requires that the sub_profile of a subject or actor belong to a specific set of known values, and the presented value is absent or not in that set, the AS or RS MAY reject the request. The accepted set SHOULD be advertised via entity_profiles_supported (for subject profiles) or entity_profiles_supported.actor (for actor profiles) in AS or RS metadata, so that clients can detect incompatibility before making a request.¶

• An AS that propagates actor-profile claims into an issued token MUST propagate unrecognized sub_profile values unchanged. It MUST NOT substitute, drop, or normalize a value it does not recognize.¶

• Implementations MUST NOT infer authorization semantics from an unrecognized sub_profile value. Policy evaluation for unrecognized values is a local decision; the safe default is to treat the entity as having no additional privileges conferred by that profile value.¶

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

• An entity MUST 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, the more restrictive outcome MUST apply. Implementations MUST NOT grant the union of all matched rules' privileges; they MUST apply least privilege across the matched set.¶

• When local policy accepts only a specific set of sub_profile values (e.g., via entity_profiles_supported.actor), the entity is accepted if at least one of its values appears in the accepted set. Values in the string that are not in the accepted set MUST be ignored for the purposes of that acceptance check; they do not cause rejection on their own.¶

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

{
  "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",
    "cnf": { "jkt": "0ZcOCORZNYy...9ZhHiZN" },
    "act": {
      "sub": "https://agents.example.com/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent",
      "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8A...CQ" }
    }
  }
}

In this example the booking tool (outermost act) is the immediate actor acting for the travel assistant (nested act), which is acting for Alice (sub). Each actor carries associated key history via cnf.jkt, and the chain carries prior-actor information to the extent that the current token issuer is trusted to have validated and faithfully propagated it.¶

Implementations MUST NOT represent delegation depth greater than five levels. Implementations that receive a token with more than five levels of nested act MUST reject it. This limit is sufficient to accommodate foreseeable multi-hop deployment patterns (e.g., user → orchestrator → sub-agent → tool → backend service) while bounding the computational and policy-evaluation cost of chain validation.¶

4.7. 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 the outermost actor. Authorization servers and resource servers validate current proof of possession against the top-level cnf, not against nested act.cnf values.¶

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

• The cnf.jkt within each act object identifies keying material associated with that specific actor in the delegation chain.¶

This separation ensures that the resource server can verify the current presenter while carrying forward actor-associated key history for prior actors in the delegation chain within the trust model of the current issuer. In single-hop cases, the top-level cnf and outermost act.cnf can carry the same value because the current presenter and current actor are the same party. In multi-hop cases, the top-level cnf identifies the current presenter for the current token, while nested act.cnf values can preserve actor-key context for earlier hops.¶

When mTLS ([RFC8705]) is used instead of DPoP, the top-level cnf.x5t#S256 identifies the current presenter's certificate. Actor-associated key history in act.cnf SHOULD use a confirmation member appropriate to the mechanism in use; where a public key is conveyed, jkt is RECOMMENDED.¶

4.8. Backwards Compatibility

This profile extends the base act claim semantics from [RFC8693] by requiring iss within each actor 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.¶

Implementations that previously treated act.cnf as an active sender-constraining mechanism (requiring proof of possession from each prior actor in a chain) should note that this specification defines act.cnf as actor-associated key history for audit, diagnostics, and optional local policy only. Active proof-of-possession requirements apply only to the top-level cnf claim and the immediate presenter. Deployments that relied on per-hop act.cnf key verification for multi-hop security properties MUST review their key-verification logic against the semantics defined in Section 4.4 and Section 4.7.¶

4.9. Top-Level Subject Classification

The sub_profile claim MAY also appear as a top-level claim in a JWT (outside any act object) to classify the entity type of the token's sub claim. When present at the top level:¶

• The value MUST be a space-delimited entity profile string as defined in Section 3.3 of [I-D.mora-oauth-entity-profiles], drawn from the OAuth Entity Profiles registry or privately defined.¶

• The claim applies exclusively to the top-level sub; it does not affect or override sub_profile values within act objects.¶

• Entity-type profiles are not restricted to actor contexts; for example, user is valid at the top level of an access token whose sub is an end-user.¶

Issuers SHOULD include a top-level sub_profile when they can authoritatively classify the subject entity type.¶

4.10. Summary of Actor-Profile Claims

The act object structure defined in Section 4.4 applies uniformly to all three token types covered by this specification. 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:¶

Detailed semantics and processing rules for each token type are defined in Section 5, Section 6, and Section 7 respectively.¶

5.1. Structure

A JWT used as an authorization grant [RFC7521][RFC7523] MAY include an act claim conforming to the actor profile defined in Section 4. 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.¶

aud (REQUIRED):

MUST identify the token endpoint of the receiving AS, per [RFC7523], Section 3.¶

exp (REQUIRED):

Expiration time per [RFC7519].¶

iat (REQUIRED):

Issued-at time per [RFC7519].¶

jti (REQUIRED):

A unique identifier for the assertion per [RFC7523], Section 3, used to prevent replay.¶

sub_profile (RECOMMENDED):

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

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 4. MUST include act.sub and act.iss.¶

When the assertion or request context also identifies an OAuth client via client_id, azp, or an authenticated client credential, that client identity MUST NOT be treated as a substitute for act.sub; see step 7 in Section 5.2.¶

An Identity Assertion JWT Authorization Grant (ID-JAG) is a JWT that can be produced by token exchange and then presented using the JWT bearer grant. When an ID-JAG is used as a JWT bearer assertion grant, this section applies to it. In that usage, the ID-JAG carries delegation information using this profile. In ID-JAG issuance flows, the acting party is often determined from the authenticated client and local delegation policy rather than from a separate actor_token. This specification profiles the resulting issued JWT, not the upstream actor-determination mechanism. Clients SHOULD therefore rely on this path only when deployment documentation, prior interoperability agreement, or successful discovery and testing indicate that the AS supports that actor-determination model. The term and token type originate in [I-D.ietf-oauth-identity-assertion-authz-grant].¶

{
  "iss": "https://agents.example.com/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.example.com/travel-assistant",
    "iss": "https://as.enterprise.example",
    "sub_profile": "ai_agent",
    "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" }
  }
}

The top-level sub_profile describes the entity type of the JWT's sub. The sub_profile within act describes the entity type of the actor.¶

This example shows a self-issued assertion grant: the agent (iss) directly asserts Alice's delegation to itself (act.sub), relying on a pre-established trust relationship between the agent and the receiving AS. An alternative pattern is an AS-issued assertion grant, in which an AS performs Token Exchange on the agent's behalf and issues the assertion grant as the iss. The ID-JAG pattern illustrated in Appendix A uses the AS-issued form. The processing rules in Section 5.2 apply to both forms; the difference lies in which party the receiving AS must have established trust with as the assertion issuer.¶

In the self-issued pattern, the client MUST set act.iss to the issuer namespace that is authoritative for its own identifier — typically the AS that issued the client's credentials or that governs the identifier namespace in which act.sub is registered. The client MUST NOT set act.iss to its own identifier or to the target AS's issuer unless that party is in fact the authoritative namespace owner. In the AS-issued pattern, the issuing AS sets act.iss to the namespace it is authoritative for, which is typically its own issuer URI.¶

When a self-issuing client intends to record actor-associated key context for the resulting issued token, it SHOULD include act.cnf.jkt in the act object, set to the JWK thumbprint of the key it will use for proof of possession. The AS will then verify the request's top-level proof-of-possession mechanism per step 6 of Section 5.2 before issuing the token and MAY copy the verified key reference into act.cnf.¶

Allowed issuer patterns include:¶

• a self-issued actor assertion where JWT iss and act.sub identify the same logical entity under trusted local mapping rules,¶

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

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

In all cases, the receiving AS MUST determine whether the JWT issuer is trusted to assert the subject-actor relationship conveyed by the assertion.¶

5.2. Authorization Server 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. If the issuer does not identify the same logical entity as act.sub under local policy, the AS MUST apply local policy to determine whether the issuer is authorized to speak for that actor.¶

3. The AS MUST verify that the act.iss value is authoritative for the identifier namespace of act.sub. An AS MUST establish this using one or more of the following mechanisms:¶

   • URL namespace containment: the act.sub identifier is within the URL namespace of act.iss (e.g., act.sub uses the same scheme, host, and port as act.iss).¶

   • Federation metadata: act.iss is listed as authoritative for the identifier namespace containing act.sub in federation metadata (e.g., [OpenID.Federation]) trusted by the AS.¶

   • Pre-registration: the AS has a pre-registered entry explicitly authorizing act.iss to assert identifiers of the form used in act.sub.¶

   • Local policy: an explicit AS policy rule authorizes act.iss to assert the specific class of identifier used in act.sub.¶

   If none of these mechanisms can be satisfied, the AS MUST reject the request with invalid_grant.¶

4. The AS MUST verify that the act.sub is authorized to act on behalf of the assertion's sub, using the AS's own policy (for example, a pre-registered delegation grant, a consent record, or a policy rule).¶

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 4.6. If the AS does not accept pre-chained assertions, it MUST reject the request.¶

   • Validation of inner chain: An AS that propagates an inner chain MUST independently validate each inner act.sub and act.iss before including that chain in the issued token. An AS that blindly forwards an inner chain without validating it launders unverified actor claims into a token bearing its own signature.¶

   • Delegation relationships: When the AS relies on the inner chain as a security-relevant delegation path (rather than informational audit context), it MUST also validate the delegation relationship at each hop in the nested chain according to local policy.¶

6. The AS MUST verify proof of possession for the token request according to the token-endpoint proof mechanism in use (DPoP per [RFC9449] or mutual TLS per [RFC8705]). When the outermost act object in the inbound assertion carries a cnf.jkt claim and local AS policy uses that value to verify the expected key for the actor-as-current-presenter, the AS SHOULD check that the inbound DPoP proof (or mTLS certificate) is consistent with the key identified in act.cnf.jkt. If local policy requires that check and it cannot be satisfied, the AS MUST reject the request with invalid_grant. Nested act.cnf values below the outermost level are actor-associated key history and MUST NOT drive proof-of-possession requirements for the current request; see Section 4.4.¶

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 MUST NOT infer that the client is authorized to act on behalf of the subject solely because the client initiated the request. When the client identity is intended to identify the same acting party as act.sub, the AS MUST validate semantic consistency between the two identifiers before issuing a token.¶

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.2. For Transaction Tokens, see Section 7.3. 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 4.6.¶

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

5.3. Error Responses

When an AS rejects a JWT assertion grant or Token Exchange request 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:¶

invalid_request:

Use when the act claim structure is syntactically invalid, the delegation chain depth exceeds the limit in Section 4.6, or a required claim such as act.sub is absent.¶

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 does not permit the identified actor (act.sub) to act on behalf of the subject (sub), or when the requested scope exceeds what is permitted for this (subject, actor) pair.¶

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

Example rejection:¶

{
  "error": "access_denied",
  "error_description": "actor_profile not permitted for requested scope"
}

5.4. Refresh Tokens

Authorization servers SHOULD NOT issue refresh tokens in response to cross-domain JWT assertion grant requests that carry actor-profile delegation. For this purpose, an assertion grant is considered cross-domain when the actor's identity namespace (governed by act.iss) differs from the assertion issuer (iss); that is, when the actor's identifier is not governed by the same authority that issued the assertion. This is consistent with the guidance in [I-D.ietf-oauth-identity-chaining]. In same-domain deployments, including authorization code flows or same-issuer token exchange where the issuer can continuously enforce local delegated-access policy, an AS MAY issue refresh tokens according to local policy.¶

The rationale is that a cross-domain delegated assertion grant is itself a short-lived, re-issuable artifact: the actor can obtain a new assertion grant and exchange it for a new access token at any time, provided the delegation relationship remains valid. Issuing a long-lived refresh token in that context would allow an actor to continue obtaining access tokens without re-presenting a current assertion, bypassing re-validation of the delegation relationship at the trust boundary. This creates a window where a revoked or expired delegation could still yield new access tokens until the refresh token itself expires or is revoked.¶

When a cross-domain delegated token is needed beyond the original access token lifetime, the preferred pattern is to re-present a new assertion grant, which ensures that:¶

• The delegation relationship is re-validated at each token issuance.¶

• The current presenter binding (cnf) is re-validated.¶

• Revocation of the delegation relationship takes effect immediately at the next token request.¶

If an AS issues a refresh token in a delegated context, it MUST bind the refresh token to the specific (subject, actor) pair from the original grant and MUST NOT allow the refresh token to be used to obtain tokens for a different actor. In cross-domain deployments, the AS SHOULD additionally ensure that refresh-token use does not bypass the revocation and trust-boundary checks that would otherwise occur when re-presenting the assertion grant. The AS MUST revoke the refresh token immediately if the delegation relationship between the subject and actor is revoked.¶

6.1. Structure

A JWT access token [RFC9068] MUST include an act claim conforming to the actor profile defined in Section 4 when any of the following conditions hold:¶

• The token was issued following acceptance of a JWT assertion grant that itself contained an act claim per Section 5;¶

• The token was issued via Token Exchange ([RFC8693]) and the request carried explicit actor information, such as an actor_token or a subject_token that already carried an act chain; or¶

• The AS has independent knowledge — established by a pre-registered delegation grant, an explicit consent record, or a policy rule that names both the subject and the acting party — that the subject's rights are being exercised by a distinct, identifiable acting party whose identifier and entity type the AS can assert authoritatively.¶

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 specification. The interoperability defined here applies to the issued token and its processing, not to the upstream method by which the AS determined the actor.¶

When none of these conditions hold, an act claim MUST NOT be added solely on the basis of the azp claim being present.¶

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. It is referenced here for completeness, not because this specification, [RFC9068], or [RFC8693] makes it a required delegation input. When an issuer uses both azp and act.sub to represent the same acting party, it MUST ensure they are semantically consistent. Client identity claims (client_id, azp) identify the OAuth client, not the delegation relationship; they MUST NOT be treated as a substitute for act. For migration and reconciliation rules, see Section 10.5 and Section 11.8.¶

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",
    "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" }
  }
}

Here the top-level bearer key (NzbLsX...) and the actor's key (NzbLsX...) are identical because in this single-hop case the actor is the bearer; in multi-hop chains each actor carries a distinct key, as shown in the detailed cross-domain example in Appendix A.¶

The top-level cnf.jkt identifies the key the immediate bearer (the travel assistant) MUST use to prove possession. The act.cnf.jkt carries the same value in this single-actor scenario because the actor is the sole bearer; in a multi-hop chain these values will differ for each hop. The client_id and azp claims identify the OAuth client; act.sub is the authoritative delegated-actor identifier. When they refer to the same logical entity under trusted local mapping rules, the issuer MUST ensure semantic consistency as described above.¶

6.2. Propagation from Assertion Grants and Token Exchange

When an AS issues a JWT access token following:¶

• Acceptance of a JWT assertion grant that contains an act claim (Section 5), or¶

• A Token Exchange request ([RFC8693]) that carries explicit actor information, such as an inbound actor_token or a subject_token that already carried an act chain,¶

the AS MUST include an act claim in the issued access token that faithfully represents the delegation relationship conveyed in the inbound request. The AS MUST NOT silently drop actor information.¶

The AS MUST ensure that the issued token refers to the same underlying subject as the inbound token. If the AS uses a different subject-identifier namespace, it MAY change the sub value only to re-express that same subject in the new namespace. It MUST NOT replace sub with an identifier for a different subject while treating the result as the same delegation chain.¶

If the Token Exchange request itself contains a subject_token that already carries an act claim (i.e., the delegation chain already has depth > 1), the AS MUST nest the existing act structure within a new outermost act that represents the newly-identified actor, unless the AS has policy that limits chain depth. When constructing this new outermost act object, the AS MUST set act.sub to the new actor's identifier and MUST set act.iss to the issuer namespace that local policy treats as authoritative for that actor's identifier — typically the AS's own issuer URI when it is the authority for the actor's namespace, or a pre-registered federation issuer otherwise. The AS MUST NOT omit act.iss from a newly-created outermost act object.¶

If the inbound actor information cannot be validated or would exceed the maximum chain depth defined in Section 4.6, the AS MUST reject the request and MUST NOT issue a token that partially preserves the delegation chain.¶

The AS SHOULD add sub_profile to the issued token's top-level claims if it can authoritatively classify the token's sub entity type.¶

When the inbound credential or authenticated request context carries client_id, azp, or both, the AS MAY preserve those values in the issued token according to the requirements of the output token profile or local deployment policy. If preserved, they MUST continue to identify the OAuth client and MUST NOT be rewritten to represent delegation state that belongs in act. If the AS cannot preserve those values without creating ambiguity about the delegated actor relationship, it SHOULD omit them rather than overload them with actor semantics. When local policy depends on continuity of client identity across token transformations, the AS SHOULD preserve the inbound client identifier values unchanged or apply a documented local translation rule; otherwise it SHOULD omit them rather than emit values that imply a different logical client.¶

The AS MUST apply least-privilege scope reduction when issuing delegated access tokens:¶

• The scope of the issued token MUST NOT exceed the scope of the subject's original authorization.¶

• When the Token Exchange request specifies a scope parameter, the issued token MUST NOT carry scopes beyond those explicitly requested.¶

• When no scope parameter is specified, the AS SHOULD restrict the issued scope to the minimum necessary for the stated purpose rather than inheriting the full scope of the subject token.¶

• The AS SHOULD further restrict scope based on policy for the (subject, actor) pair or the actor's sub_profile.¶

The granted scope MUST be reflected in the issued token's scope claim so that resource servers and audit systems can verify that least-privilege constraints were applied. Deployments involving AI agents or automated workloads SHOULD treat scope reduction as effectively mandatory unless a specific policy exception has been established for the (subject, actor) pair.¶

The same preservation requirements apply regardless of whether the inbound credential presented to the AS is a JWT assertion grant, a JWT access token, or a Transaction Token, provided that local policy and the underlying grant or token-exchange mechanism permit issuance of a JWT access token from that input.¶

6.3. Resource Server Processing

Upon receiving a JWT access token that contains an act claim, 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 8. A resource server that requires actor authorization for delegated tokens MUST advertise that requirement using actor_authorization_required: true (Section 10.3).¶

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

1. Validate the token's signature, iss, aud, and temporal claims per [RFC9068].¶

2. If the token carries a top-level cnf.jkt, validate the accompanying DPoP proof per [RFC9449]. The DPoP proof MUST be signed by the key identified in cnf.jkt, which is the key of the immediate bearer—the outermost actor when delegation is present.¶

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

4. If the token carries client_id, azp, or both, treat those as client-identity inputs only. The RS MUST NOT use client_id or azp as a substitute for act.sub. When local policy expects both to identify the same acting party, the RS MUST verify semantic consistency; in the absence of such a policy determination, the RS MUST treat them as distinct identifiers. See Section 11.8.¶

5. Apply actor authorization per Section 8 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 informational and SHOULD 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 actor chain. The RS MUST NOT treat nested actor issuers as independently authenticated merely because their identifiers appear in inner act.iss values.¶

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. When the subject's scope was sufficient but the actor lacked authorization, the RS SHOULD include error="insufficient_scope" in the WWW-Authenticate challenge. When the actor's sub_profile is not in the RS's accepted list, the RS MAY use error="access_denied".¶

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

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

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 indicating a non-delegated token and MUST NOT assume delegation when the claim is absent.¶

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

7.1. Overview

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

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

Issuer of the Transaction Token. May be omitted when all tokens are scoped to a single Trust Domain. 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.2.¶

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

7.2. Actor Claim in Transaction Tokens

When a Transaction Token is used in a delegated scenario, the act claim conforming to this profile MUST be included to represent the current acting party and any prior delegation steps, as specified in Section 7.3. In non-delegated Transaction Tokens, inclusion of act is OPTIONAL. In Transaction Tokens, req_wl identifies the workload that requested the token from the TTS, while act.sub identifies the immediate acting party in the subject identifier namespace used by this profile. For authorization decisions under this specification, the authoritative actor identifier is the outermost act.sub; req_wl is supporting workload context.¶

The semantics are as follows:¶

• sub identifies the original human or non-personal initiator of the transaction. When a Transaction Token is exchanged for a replacement, the new token MUST continue to refer to the same underlying subject. If the issuer uses a different subject-identifier namespace, it MAY change the sub value only to re-express that same subject in the new namespace.¶

• scope captures the transaction authorization intent for this specific token instance, using the semantics defined by the TTS.¶

• req_wl identifies the workload that requested this specific token instance from the TTS.¶

• When an act claim is present, the outermost act.sub identifies the immediate acting party that presents the token downstream. In deployments where req_wl contains a single workload identifier for that same entity, the issuer SHOULD ensure that req_wl and the outermost act.sub are semantically consistent.¶

• When a downstream workload exchanges a Transaction Token to obtain a new Transaction Token, the new token retains the original sub, updates req_wl to the new requester, and preserves prior presenter history by creating a new outermost act for the new presenter and nesting any existing act chain beneath it.¶

• Inner nested act objects, when present, identify prior presenters in the transaction's delegation path.¶

• act.sub_profile classifies the entity type of the current presenter, while nested act.sub_profile values classify prior presenters.¶

• If a recipient relies on both req_wl and the outermost act.sub to identify the current presenter, and those values cannot be mapped by local policy to the same current presenter, the recipient MUST treat that mismatch as a policy or trust failure and reject the token unless deployment-specific rules explicitly define how to reconcile the two identifiers.¶

The following example shows a Transaction Token after two hops:¶

{
  "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",
    "cnf": { "jkt": "0ZcOCORZNYy9ZhHiZN..." },
    "act": {
      "sub": "https://agents.example.com/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent",
      "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" }
    }
  }
}

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

7.3. Transaction Token Service Processing

When a TTS receives a token-exchange request to issue or refresh a Transaction Token, and an inbound token carried in the request contains actor-profile claims (for example, in the subject_token or actor_token):¶

1. The TTS MUST ensure that the issued token refers to the same underlying subject as the inbound token. It MUST preserve the inbound sub value unchanged when the same subject-identifier namespace is used. If the TTS uses a different subject-identifier namespace, it MAY change the sub value only to re-express that same underlying subject in the new namespace. It MUST NOT replace sub with an identifier for a different subject while treating the result as the same delegation chain.¶

2. The TTS MUST set req_wl to the authenticated requesting workload's identity per [I-D.ietf-oauth-transaction-tokens].¶

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

4. The TTS MUST create a new outermost act object identifying the new presenter. If the inbound token already carries an act chain, the TTS MUST nest that chain beneath the new outermost act object so that prior presenters are preserved. The TTS MUST set act.iss in that new outermost actor object to the issuer namespace that local policy treats as authoritative for the identifier used in the new presenter's act.sub. This value identifies the authority for the presenter identifier, not merely the service that issued the Transaction Token.¶

5. The TTS SHOULD include sub_profile in any new act object it creates, based on its knowledge of the new presenter's entity type.¶

6. The TTS MUST set the top-level confirmation claim to bind the Transaction Token to the new authorized presenter according to the proof mechanism used by the Transaction Token deployment. When that mechanism conveys a public-key thumbprint in cnf.jkt, the TTS MUST set cnf.jkt to the key of the new authorized presenter. In WIMSE-based deployments, this presenter binding is typically established using a Workload Identity Token (WIT) conveyed in the Workload-Identity-Token header field together with a Workload Proof Token (WPT) conveyed in the Workload-Proof-Token header field. The WPT proves possession of the private key associated with the WIT and can bind accompanying tokens, including a Transaction Token, through token-hash claims such as tth [I-D.ietf-wimse-workload-creds][I-D.ietf-wimse-wpt].¶

7. The TTS MUST set the Transaction Token scope according to the authorization semantics defined by [I-D.ietf-oauth-transaction-tokens] for the requested transaction, and it MAY include tctx or rctx as appropriate for downstream services.¶

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

8.1. 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 (i.e., that the actor is authorized to act on behalf of the subject) before granting access. This specification recommends this subject-plus-actor evaluation model for delegated tokens, but does not require every RS to use it in every deployment.¶

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, policy refinement, or chain validation.¶

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 authorization, trust, or risk inputs in addition to sub and the outermost act.sub. This specification does not require or standardize such evaluation, and clients MUST NOT assume that nested actors will be used for authorization unless deployment-specific agreements say otherwise.¶

8.2. Resource Server Processing

Actor authorization is OPTIONAL but RECOMMENDED for delegated tokens under this profile. An RS that requires actor authorization for a resource MUST advertise that requirement using actor_authorization_required: true (Section 10.3). An RS that does not advertise this value MAY still apply subject-plus-actor evaluation, but clients MUST NOT rely on that behavior. Deployments that treat actor information as informational only SHOULD do so only in narrowly scoped and explicitly documented cases. The following steps describe the RECOMMENDED evaluation:¶

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

2. Evaluate presenter or actor authorization: When the RS applies actor authorization, determine whether the current non-subject principal is permitted to exercise the subject's authorization. This principal is the outermost act.sub. For Transaction Tokens, the RS SHOULD evaluate req_wl as supporting workload context and MAY verify semantic consistency between req_wl and the outermost act.sub when the deployment uses a single workload identifier for the current presenter. If the RS relies on both claims and cannot reconcile them under local policy, it MUST reject the request. If the RS does not rely on req_wl for that purpose, req_wl remains supporting context only. This actor 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, which reflects the least-privilege restrictions applied at the AS when the token was issued.¶

3. Evaluate combined policy: Apply any resource-specific subject-plus-actor policies. For example, a resource server may require that both the subject and the actor have independently agreed to terms of service.¶

If the resource server requires actor authorization but cannot evaluate actor authorization, it MUST reject the request. Resource servers that do not require actor authorization SHOULD still log or otherwise account for delegated actor information when it is relevant to audit or trust decisions.¶

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

8.3. Policy Claims Summary

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

9.1. Overview

[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, and an IANA registry of entity profile values with associated usage locations ("Subject Profile", "Client Profile").¶

This document extends that specification in one way:¶

1. It defines a new "Actor Profile" usage location, indicating that an entity profile value is valid within an act object's sub_profile claim.¶

It does not define a separate registry. All entity profile values used by this specification are registered in the "OAuth Entity Profiles" registry established by [I-D.mora-oauth-entity-profiles].¶

9.2. Actor Profile Usage Location

The "OAuth Entity Profiles" registry includes a "Usage Location" field that indicates where a profile value may appear. This document adds a new usage location:¶

Actor Profile:

The entity profile value appears in the sub_profile claim within an act object, classifying the entity identified by act.sub. This usage location is defined by this document.¶

The following existing values from [I-D.mora-oauth-entity-profiles] are extended with the "Actor Profile" usage location:¶

These are the initial entity profile values that this document extends for actor use. This document does not imply that all existing entity-profile values are automatically valid within act.sub_profile; only values explicitly registered with the "Actor Profile" usage location are valid in that position. Additional values MAY be added to the registry in the future through the normal registration process when their semantics are appropriate for acting entities.¶

When processing act.sub_profile, issuers and consumers MUST treat these values according to the entity profile semantics defined in Section 3 of [I-D.mora-oauth-entity-profiles].¶

9.3. Extension to entity_profiles_supported

Section 5 of [I-D.mora-oauth-entity-profiles] defines the entity_profiles_supported AS metadata parameter as a JSON object containing client and subject arrays. This document extends that object with an actor array, defined normatively here. The actor member does not depend on [I-D.mora-oauth-entity-profiles] being updated to include it; it is an extension defined by this document and registered per Section 13.3.¶

actor:

OPTIONAL. A JSON array of entity profile values (per Section 3.3 of [I-D.mora-oauth-entity-profiles]) indicating which profiles the AS recognizes and will validate when they appear in act.sub_profile claims in inbound tokens and actor assertions. Actors whose sub_profile is not listed in this array MAY be rejected by the AS.¶

An AS implementing both this profile and [I-D.mora-oauth-entity-profiles] SHOULD include an actor array in its entity_profiles_supported object.¶

Example:¶

{
  "entity_profiles_supported": {
    "client": ["service", "ai_agent"],
    "subject": ["user", "service", "ai_agent"],
    "actor":   ["user", "service", "ai_agent"]
  }
}

10.1. Overview

This section defines a minimal set of metadata parameters that, together with the entity_profiles_supported extension in Section 9, allow authorization servers and resource servers to advertise actor-profile support without out-of-band configuration. These parameters provide partial capability negotiation only; they do not provide a complete machine-readable description of every supported grant path or method by which the AS determines the acting party.¶

The design principle is that capability flags go in this spec's metadata; entity type enumeration goes in [I-D.mora-oauth-entity-profiles] metadata. Clients MUST use entity_profiles_supported.actor (Section 9.3) to determine which actor entity profiles an AS or RS accepts, and MUST use actor_profile_token_types_supported (Section 10.2) to determine which delegated output token types the AS can issue under this profile.¶

10.2. Authorization Server Metadata

One new parameter is defined for use in the AS metadata document ([RFC8414]):¶

actor_profile_token_types_supported:

OPTIONAL. A JSON array of token-type URI strings indicating the delegated output token types that the AS can issue while applying actor-profile processing as defined in this document. When a token type appears in this array, the AS can produce that token type as an output with actor-profile claims preserved or created according to this specification. This parameter does not by itself indicate every accepted input token type for a transformation; clients MUST combine it with grant_types_supported, deployment documentation, and the processing rules of the relevant token type before assuming that a particular exchange path is supported. Defined values are:¶

• urn:ietf:params:oauth:token-type:access_token — JWT access tokens (Section 6)¶

• urn:ietf:params:oauth:token-type:jwt — JWT assertion grants (Section 5)¶

• urn:ietf:params:oauth:token-type:txn_token — Transaction Tokens (Section 7)¶

When absent, the AS makes no claim about delegated output token types under this profile.¶

The entity profile types the AS accepts for actors are advertised via the entity_profiles_supported.actor array defined in Section 9.3, not via a separate metadata parameter. DPoP support is advertised via dpop_signing_alg_values_supported per [RFC9449].¶

Example AS metadata fragment:¶

{
  "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"
  ],
  "entity_profiles_supported": {
    "client": ["service", "ai_agent"],
    "subject": ["user", "service", "ai_agent"],
    "actor":   ["user", "service", "ai_agent"]
  }
}

10.3. Protected Resource Metadata

Two new parameters are defined for use in Protected Resource Metadata ([RFC9728]):¶

actor_profile_required:

OPTIONAL. A boolean. When true, the RS requires that tokens presented for this resource carry an act claim conforming to the actor profile defined in this document. The RS MUST reject tokens that omit act or that carry act claims not conforming to this profile. When false or absent, actor-profile conformance is not required.¶

actor_authorization_required:

OPTIONAL. A boolean. When true, the RS advertises that it requires evaluation of the actor as an authorization input in addition to the subject, as described in Section 8. An RS that requires actor authorization for a resource MUST set this value to true. When false or absent, the RS makes no declaration to clients about whether actor authorization is applied, and clients MUST NOT rely on that behavior unless the value is true.¶

Clients discover which actor entity profile values the RS's AS will accept by consulting entity_profiles_supported.actor in the AS metadata for the AS listed in the resource's authorization_servers.¶

Example Protected Resource Metadata fragment:¶

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

10.4. Capability Negotiation Flow

The following steps describe a RECOMMENDED capability-negotiation pattern a client agent can use as a preflight check to evaluate whether a cross-domain delegation is likely to be feasible:¶

1. Discover target resource metadata: The client fetches Protected Resource Metadata ([RFC9728]) for the target API and reads actor_profile_required, actor_authorization_required, and authorization_servers.¶

2. Discover target AS metadata: The client fetches AS metadata ([RFC8414]) for the listed AS and reads:¶

   • actor_profile_token_types_supported to determine whether the desired delegated output token type is advertised.¶

   • entity_profiles_supported.actor to confirm the client's own entity profile (its sub_profile value) is in the accepted list.¶

3. Proceed or abort: If actor_profile_required is true at the RS and the client's entity profile is not listed in entity_profiles_supported.actor at the AS, the client MUST NOT proceed with a delegation-based request and SHOULD surface the capability mismatch to the invoking system. If the desired delegated output token type is not listed in actor_profile_token_types_supported, the client MUST treat that output as unsupported. If actor_authorization_required is true, the client SHOULD expect the RS to require actor evaluation in addition to subject evaluation and SHOULD acquire a token whose actor information can satisfy that policy. If the listed metadata is insufficient to determine whether the AS supports the needed input grant or exchange path, the client SHOULD treat support as indeterminate and rely on deployment-specific knowledge or a trial request.¶

   As a safe default, a client that intends to make a request on behalf of another principal SHOULD treat actor_profile_required: true as meaning that it needs an explicit act-carrying token for that resource. Clients SHOULD prefer acquisition paths that explicitly carry actor information over paths that depend on AS-derived actor determination when both are available.¶

4. Construct and submit token exchange or assertion grant: The client proceeds per Section 5 for JWT assertion grants or per [RFC8693] for token-exchange requests. When the delegated request explicitly carries actor-profile claims and act.sub_profile is included, its value MUST be drawn from the entity_profiles_supported.actor accepted list. When actor information is derived by the AS from authenticated client context or other local policy, the client SHOULD verify — via deployment documentation, prior test requests, or AS metadata — that the acting entity corresponds to an accepted actor profile before relying on the AS to issue a delegated token under this profile.¶

5. RS validation: The RS validates the resulting token according to the rules for that token type and applies local delegated-token policy. If the RS requires actor authorization, it applies that policy per Section 8. For JWT access tokens, see Section 6.3. For Transaction Tokens, see [I-D.ietf-oauth-transaction-tokens] together with Section 7 of this document.¶

Example client preflight failure:¶

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

10.5. Migration from Implicit to Explicit Delegation

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

The safe migration default 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, they MUST reconcile under those rules or the request MUST be rejected.¶

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

The following table summarizes the transition:¶

During transition, issuers SHOULD emit both legacy client-oriented identifiers and explicit actor claims whenever doing so is feasible for the deployment, and they SHOULD log whether delegation was processed explicitly, implicitly, or inconsistently.¶

Migration example, 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"
}

Migration example, 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"
}

Here client_id and azp carry the opaque OAuth client registration identifier, while act.sub carries the delegated actor identifier in the namespace scoped by act.iss. These are different identifier formats for the same party under trusted local mapping rules. A deployment can continue using its existing client-based authorization inputs during migration if trusted local mapping rules bind travel-assistant-client-id to https://agents.example.com/travel-assistant. If no such mapping rule exists, the deployment MUST treat the identifiers as distinct and MUST NOT infer equivalence.¶

10.6. Transaction Token Flows

Transaction Token support is advertised using the transaction_token_supported AS metadata parameter and the transaction_token_required Protected Resource Metadata parameter, both defined in [I-D.ietf-oauth-transaction-tokens], Section 8. This document does not redefine those parameters.¶

When Transaction Tokens are used, the actor-profile claims MUST be propagated per Section 7.3, and the AS or TTS MUST list urn:ietf:params:oauth:token-type:txn_token in actor_profile_token_types_supported when it can issue Transaction Tokens as delegated outputs under this profile.¶

11.1. Delegation Chain Integrity

The act claim MUST be set by a trusted AS that has validated the delegation relationship. Resource servers MUST NOT accept tokens in which the act claim was demonstrably set by an untrusted party. Concretely, RS implementations MUST validate the token signature before extracting actor claims, and MUST verify that the issuer of the token is authoritative for the claims it contains.¶

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

11.2. Actor Identity Binding

Without top-level presenter proof of possession, a leaked token can be replayed by any party. When an act.cnf.jkt is present:¶

• The AS that set this value SHOULD have verified the actor's possession of the corresponding key before including it.¶

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

• The RS MAY use act.cnf as audit, diagnostic, or policy input, but MUST NOT treat nested act.cnf values as independently verifiable presenter bindings for prior hops.¶

Deployments of AI agent systems SHOULD require sender-constrained tokens for the current presenter to prevent delegation token theft, and MAY carry act.cnf for actor-chain visibility.¶

Nested act.cnf values do not by themselves provide independently verifiable provenance for prior actor hops across trust boundaries. An intermediate issuer that is trusted to issue a new token can also rewrite nested actor-chain content, including nested act.cnf values. Accordingly, act.cnf is useful for carrying actor-associated key history, but it does not solve cross-domain integrity or non-repudiation for prior hops. Stronger assurance for prior-hop provenance would require an additional mechanism outside the scope of this specification, such as signed hop receipts, transparency-log-based recording, or another future extension.¶

11.3. Delegation Depth Limits

Unbounded delegation chains increase attack surface and complicate policy evaluation. This document specifies a maximum depth of five nested act objects (Section 4.6), sufficient for foreseeable multi-hop scenarios. Implementations that encounter chains exceeding this limit MUST reject the token to prevent denial-of-service through chain parsing.¶

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

11.5. Inner Actor Issuer Trust

The act.iss values in nested (inner) act objects are assertion-based: they were set by whoever constructed those inner objects at an earlier point in the delegation chain, not by the issuer of the current token. The outer token's signature guarantees that the token issuer endorsed the entire payload as presented — including inner act objects — but it does not mean that the named inner act.iss authorities independently authenticated or signed those claims.¶

Implementations MUST NOT treat an inner act.iss value as independently authenticated merely because it appears in the token. The trust basis for inner actor claims is the outer token issuer's endorsement of them, not the inner act.iss authority's own signature.¶

Consequently:¶

• An RS that relies on an inner act.iss for audit or policy purposes MUST do so only when it trusts the outer token issuer to have validated and faithfully propagated that inner actor chain at issuance time.¶

• ASes that propagate inner actor chains during token exchange MUST independently validate each inner act.sub and act.iss before endorsing them in an issued token (see step 5 of Section 5.2). An AS that blindly forwards an inner act chain without validating it launders unverified actor claims into a token bearing its own signature.¶

• Security policies that rely on inner actor identities for access control SHOULD be treated as lower-assurance than policies based on the outermost act.sub, which is validated by the immediate token issuer.¶

11.6. Cross-Domain Trust

When a token crosses organizational boundaries, the receiving AS or RS MUST apply appropriate trust evaluation. The iss claim of the outer token identifies the issuing AS; inner act objects may reference actors whose sub is from a different domain. ASes performing token exchange MUST evaluate cross-domain delegation grants explicitly and MUST NOT implicitly grant cross-domain actors the same rights as same-domain actors.¶

11.7. Delegation Revocation

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

Authorization servers SHOULD maintain a delegation grant registry mapping (subject, actor) pairs to active delegation relationships. When a delegation grant is revoked, the AS MUST refuse to issue new tokens for that (subject, actor) pair. Because refresh tokens SHOULD NOT be issued for delegated assertion grants (see Section 5.4), revocation of the delegation relationship takes effect at the next assertion grant presentation. If an AS has issued refresh tokens in a delegated context, it MUST proactively revoke them when the delegation relationship is revoked.¶

Resource servers in security-sensitive deployments SHOULD use token introspection ([RFC7662], Section 6.4) rather than local JWT validation so that revocation state is checked on each request. Implementations MUST NOT use delegation chain depth as a rationale for skipping revocation checks.¶

Operators deploying AI agent systems MUST provide end-users with a mechanism to enumerate and revoke active delegation grants.¶

11.8. 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 specification, those values remain auxiliary client-identity signals, while the outermost act.sub is the explicit delegated-actor signal when present. Client identity alone does not prove delegation, and implementations MUST NOT treat it as a substitute for act. The detailed migration and reconciliation rules are defined in Section 10.5.¶

For example, if a token contains client_id for travel-assistant-client-id but act.sub identifies https://agents.example.com/concierge-bot, an AS or RS that expected the client and actor to identify the same party under trusted local mapping rules MUST reject the request unless those rules explicitly bind the identifiers to the same actor.¶

11.9. Confused Deputy and Actor-Authorization Bypass

A resource server that evaluates only the subject principal when an act claim is present is susceptible to a confused deputy attack where a malicious actor exploits a subject's pre-existing permissions without the subject's ongoing consent. Resource servers SHOULD implement actor authorization for delegated tokens under this profile. Resource servers that require actor authorization MUST advertise that behavior using actor_authorization_required: true. Deployments that choose not to require actor authorization SHOULD follow the narrowly scoped and explicitly documented informational-only cases described in Section 8.¶

11.10. 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 specification, 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 4.5, and they MUST reject values that are malformed or disallowed by local policy.¶

13.1. OAuth Authorization Server Metadata Registry

This document requests IANA to register the following value 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 of this document¶

13.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 requires delegated requests to use tokens carrying an act claim conforming to this profile¶

• Change Controller: IETF¶

• Reference: Section 10.3 of this document¶

• Metadata Name: actor_authorization_required¶

• Metadata Description: Boolean indicating whether the RS requires actor authorization in addition to subject authorization per this document¶

• Change Controller: IETF¶

• Reference: Section 10.3 of this document¶

13.3. OAuth Entity Profiles Registry

This document requests the following updates to the "OAuth Entity Profiles" registry established by [I-D.mora-oauth-entity-profiles].¶

13.4. Extension to entity_profiles_supported Metadata

This document defines an optional actor member for the entity_profiles_supported AS metadata parameter, alongside the existing client and subject members, as defined in Section 9.3 of this document. If [I-D.mora-oauth-entity-profiles] is published as an RFC without this member, this document requests that its definition be updated accordingly. Until then, implementations SHOULD treat the actor member defined in Section 9.3 as a vendor-agreed extension to the base parameter.¶

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

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

[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.mora-oauth-entity-profiles]

Mora, S. C. and P. Dingle, "OAuth Entity Profiles", 17 October 2025, <https://www.ietf.org/archive/id/draft-mora-oauth-entity-profiles-00.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>.

14.2. Informative References

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

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

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

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

[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 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 5. 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:¶

A.2. Discovery and Capability Negotiation

The agent checks the Travel Provider AS metadata (Section 10) to confirm actor-profile support 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 confirms that its sub_profile (ai_agent) is listed in entity_profiles_supported.actor, that both jwt and access_token are covered by actor_profile_token_types_supported, and that the Booking Tool RS requires explicit actor-profile support and actor authorization.¶

A.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": "travel-assistant-client-id",
  "exp": 1743379200,
  "iat": 1743375600
}

A.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. The Enterprise IdP AS authenticates the client as travel-assistant-client-id, verifies that the ID Token audience matches that client, and uses local delegation policy plus the authenticated client context 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=travel-assistant-client-id
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=<travel-assistant-client-assertion>

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

{
  "iss": "https://as.enterprise.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "sub_profile": "user",
  "client_id": "travel-assistant-client-id",
  "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",
    "cnf": { "jkt": "AgentJKT-NzbLsXh8uDCcd7MN" }
  }
}

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 they all refer to the same party under trusted local mapping rules. Both cnf.jkt (top-level, for DPoP binding) and act.cnf.jkt (actor-associated key reference) are set to AgentJKT because the agent is both the bearer and the acting principal at this stage.¶

A.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 5 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 5.2: it verifies the request's DPoP proof against the current presenter binding and checks that act.sub_profile (ai_agent) is permitted as an actor for the requested scope. 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": "travel-assistant-client-id",
  "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",
    "cnf": { "jkt": "AgentJKT-NzbLsXh8uDCcd7MN" }
  }
}

Alice's sub and sub_profile are preserved verbatim from the ID-JAG (Section 6.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.¶

A.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 actor authorization (Section 8): it evaluates both Alice (sub, sub_profile: user) and the Travel Assistant (act.sub, sub_profile: ai_agent). Because the RS advertises actor_authorization_required: true, both principals MUST be independently authorized. The act.sub_profile value is checked against entity_profiles_supported.actor per Section 9.¶

A.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 authenticates the Booking Tool using a WIMSE Workload Identity Token (WIT) and 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-Identity-Token: <booking-tool-wit>
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
&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 TTS applies actor-profile processing per Section 7.3: it preserves sub and sub_profile from the subject token, sets req_wl to the authenticated Booking Tool, creates a new outermost act object for the Booking Tool, nests the subject token's existing act claim beneath it, and binds the issued Transaction 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",
    "cnf": { "jkt": "ToolJKT-0ZcOCORZNYy9ZhHi" },
    "act": {
      "sub": "https://agents.enterprise.example/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent",
      "cnf": { "jkt": "AgentJKT-NzbLsXh8uDCcd7MN" }
    }
  }
}

The presenter binding rotates at this step: cnf.jkt is now ToolJKT, and the outermost act.cnf.jkt matches it because the Booking Tool is now the current actor. The nested act.act.cnf.jkt retains the agent's original key, illustrating the multi-hop key-rotation property described in Section 4.7.¶

A.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 actor authorization (Section 8): Alice (sub) governs data access policy (e.g., travel tier); the Booking Tool (act.sub) is the authorized internal workload. 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 8.2.¶

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