OAuth 2.0 Profile for Agent Principal Federation

1.1. Protocol Overview

A platform runs several agents behind one OAuth client. Client authentication identifies the platform, but the resource needs to know which agent is acting. The identity provider (IdP) maps an authenticated client or workload identity to a stable Agent Principal and checks whether the client may use that identity. It issues a grant identifying the agent. The resource domain correlates that identity with its local principal (an account it manages) and applies its own authorization policy at its resource authorization server (RAS) and API. Delegated access identifies both the user and the agent; self-acting access identifies the agent as the subject.¶

The client makes three requests, which Appendix A.1 shows message by message:¶

1. To the IdP token endpoint, an OAuth Token Exchange request [RFC8693] (Section 5.2). The IdP returns the grant: a short-lived JWT, signed by the IdP, for one resource at one RAS.¶

2. To the RAS token endpoint, presenting the grant with the jwt-dpop grant type if it is bound to the client's key, or the JWT bearer grant type if not (Section 6.1). The RAS returns an access token.¶

3. To the API, with the access token (Section 7).¶

 Client authentication or workload evidence
                      |
               Identity Binding .......... which agent?
                      v
       Agent Principal (IdP namespace)
                      |
              Client Association ........ may this client use it?
                      |
          +-----------+------------+
          |                        |
 Delegation Authorization    Agent Authorization
   agent acts for user         agent acts for itself
          |                        |
 ID-JAG: sub = user          WAG: sub = agent
         act = agent               |
          |                        |
          +-----------+------------+
                      |
                      v
 RAS: validate grant; correlate agent with local principal
                      |
                      v
 RAS and API: resource authorization; actor gate if delegated

Each relationship answers one question:¶

• Identity Binding (IdP): Which governed agent does this credential identify?¶

• Client Association (IdP): May this OAuth client use that agent's identity?¶

• Agent or Delegation Authorization (IdP): What authority (scope and any authorization details for one resource) may the agent request, on its own or for a user?¶

• Correlation and resource policy (RAS and API): What access will the resource domain permit? For delegated access, this includes the actor gate: may this agent act for this user?¶

For example, an Identity Binding maps the platform identity workload-7, qualified by its issuer, to the Agent Principal (https://idp.example/, agent-42). Grants carry that IdP-qualified principal, not the platform identity:¶

Platform identity:  https://platform.example/  workload-7
                            |  Identity Binding at the IdP
                            v
Agent Principal:    https://idp.example/       agent-42

Delegated ID-JAG (excerpt):
  "sub": "alice",
  "act": {"iss": "https://idp.example/", "sub": "agent-42"}

Self-acting WAG (excerpt):
  "iss": "https://idp.example/", "sub": "agent-42"

The act claim is the actor claim of Token Exchange (Section 4.1 of [RFC8693]): it names the party acting for the subject.¶

The relationships do not imply one another. Mapping an identity grants no permission, owning an agent does not establish a user's delegation to it, and how far and how fast disablement propagates depends on the lifecycle mechanism a deployment selects, such as [AGENT-LIFECYCLE].¶

Clients and IdPs support dedicated-client resolution: one OAuth client per agent, authenticating with private_key_jwt, so that client authentication identifies the agent (Section 5.3.2). For delegated access, they also support ID Token subjects. Deployments may use other mutually supported inputs. The existing platform JWT input is required for generic shared-client interoperability; when used, it accompanies each grant-issuance request to the IdP (Section 5.3.3; Appendix A.2.1 shows one). Conformance follows Section 9.1.¶

Section 3 and Section 4 apply to every role. The IdP's processing is in Section 5, the RAS's in Section 6, and the API's in Section 7. [GUIDE] adds a primer and the configuration each party maintains.¶

The profile sits within the agent identity management framework that AIMS [AIMS] describes and defines how the identities in one transaction relate across authorization domains.¶

The federation model (Section 3) is independent of the grant that carries it. Two peer realizations carry it, each with its own mandatory path, and an implementation claims one or both (Section 9.1):¶

• Delegated access (Section 4.1): the Identity Assertion JWT Authorization Grant (ID-JAG) [ID-JAG], with the user as subject and the Agent Principal as actor.¶

• Self-acting access (Section 4.2): the Workload Authorization Grant (WAG) [WAG], with the Agent Principal as subject.¶

Other grant realizations need their own composition rules. Dedicated-client assertions and existing platform JWTs supply inputs to this identity model (Section 5.3.1). [INPUTS] defines further inputs, such as SPIFFE JWT Verifiable Identity Documents (JWT-SVIDs).¶

This document federates an agent governed by the IdP that issues the grant into a resource domain. It does not define identity continuity across a chain of IdPs or brokers. Forwarding an actor from another IdP's namespace is out of scope. Also out of scope (Appendix B):¶

• task or mission authorization;¶

• asynchronous approval;¶

• continuation of approved work across grants;¶

• provisioning protocols and account administration ([GUIDE]);¶

• multi-agent delegation chains;¶

• authorization of individual client instances, and propagation of instance context across domains; and¶

• enrollment or key-replacement protocols.¶

Each processing chapter covers delegated and self-acting access, with client requirements beside the requests and responses.¶

2.1. Roles

Agent Platform (the platform):

The environment that runs agents. It supplies verifiable workload evidence from its own or an approved external credential authority and can implement the OAuth client that obtains access for an agent.¶

Client:

Software making OAuth requests for an agent. It authenticates as an OAuth client and presents the evidence, target, and proofs for the selected grant flow.¶

Identity Provider (IdP):

The OAuth authorization server that resolves validated inputs to an Agent Principal, checks the permitted client and acting relationship, and issues a grant naming that agent as subject or actor.¶

Resource Authorization Server (RAS):

The OAuth authorization server that validates the grant, resolves its identities, applies local policy, and issues an access token for its resources.¶

API (resource server):

The OAuth resource server that accepts the access token and enforces the acting relationship and proof binding it carries.¶

One service can implement several roles.¶

Two companion System for Cross-domain Identity Management (SCIM) profiles complete the family and define their own administrative roles. [AGENT-MANAGEMENT] establishes the relationships at the IdP, and [AGENT-LIFECYCLE] carries the principal's administrative state into the resource domain and revokes what depends on it.¶

2.2. Terms

Agent Principal:

A stable, non-human authorization principal in the IdP's namespace representing an independently governed workload or agent. It is independent of the external credentials, execution environments, and OAuth clients used to obtain authorization for it (Section 3.4).¶

Workload:

An external computational principal identified by accepted workload evidence. It can span multiple running instances; its identity does not necessarily distinguish executions.¶

Dedicated client:

An OAuth client whose authenticated identity maps explicitly to one Agent Principal in the IdP's client-registration context. Dedicated refers to identity resolution, not to one process, replica, or installation.¶

Shared client:

An OAuth client serving multiple Agent Principals. Its authenticated client identity alone cannot distinguish those agents; resolution requires independently validated workload identity.¶

Identity Binding:

An approved association from an exact client or workload identity, qualified by its registration context or credential authority, to one Agent Principal. The Agent Principal can have the same identifier as that identity. An Identity Binding is administered in a Governance Tenant and establishes identity resolution, not permission to exercise the agent.¶

Client Association:

An approved permission for an authenticated OAuth client to use an Agent Principal through the selected Identity Binding, acting relationship, and credential class (Section 5.3.6).¶

Credential class:

A configured category of agent-resolution input with mutually exclusive validation rules. Examples are an RFC 7523 client assertion, a SPIFFE Verifiable Identity Document (SVID), Client Attestation, and a platform issuer's workload JWT profile. JWT encoding alone does not identify the class.¶

Acting relationship:

Whether the Agent Principal acts as the subject of a grant (self-acting) or as the actor for a user (delegated).¶

Delegation Authorization:

The IdP's decision that an Agent Principal may act for a user within an approved client, tenant, target, and authority context.¶

Agent Authorization:

The self-acting counterpart of Delegation Authorization: the IdP's decision that an Agent Principal may access a target on its own behalf within an approved client, tenant, target, and authority context.¶

Agent Principal Correlation:

The RAS's authoritative association of an IdP-qualified Agent Principal with a local principal.¶

Issuer-bound presenter key:

A key the credential issuer has attested belongs to the workload, such as a Client Attestation's confirmation key. It shows that the credential authority authorized the key.¶

Request proof key:

A key the presenter proves in the request without issuer attestation, as with Demonstrating Proof of Possession (DPoP) [RFC9449] accompanying bearer evidence. It shows possession alone (Section 5.3.4).¶

Grant proof key:

The DPoP key proven when requesting an ID-JAG or WAG and bound into that grant for redemption (Section 5.3.4).¶

Governance Tenant:

The IdP's administrative scope within which an Agent Principal and its relationships are managed: a tenant of the IdP's issuer in the sense of Section 6.1 of [ID-JAG]. It is not part of the Agent Principal's identity, which the IdP issuer qualifies (Section 3.3).¶

Target Tenant:

The tenant at the RAS in which the agent or user is authorized, that is, where authority is exercised. It can differ from the Governance Tenant.¶

Where the meaning is clear, this document uses agent as shorthand for Agent Principal.¶

3.1. Resource Domain Contract

The mapping from execution identity to Agent Principal is local to the IdP. The security contract across the boundary between the IdP and the resource domain is interoperable. The RAS does not resolve the agent from the execution credential; the grant carries the resolved Agent Principal instead. The RAS performs no platform-specific credential validation or workload resolution and need not know which input the agent authenticated with. From a validated grant it receives:¶

• the Agent Principal, qualified by its governing issuer: act.iss and act.sub in an ID-JAG (Section 5.6.4), or iss and sub in a WAG;¶

• the acting relationship: delegated, with the user as subject, or self-acting;¶

• the client's registration at the RAS, in client_id; and¶

• the authority the IdP approved (scope and any authorization details), as a ceiling for the RAS decision.¶

The RAS correlates the Agent Principal with a local principal, which can be an existing service principal. Correlation does not replace the IdP-qualified identity (Section 6.3). For delegated access, the RAS translates the user into its local namespace and preserves the agent (Section 6.4.2). Correlation does not grant authority: the RAS decides within the grant's ceiling (Section 3.6.4, Section 6.5).¶

3.2. Authentication, Resolution, and Proof

The IdP MUST validate a credential according to its configured type before using it for identity resolution. A generic JWT token-type URI, an unverified header, or a caller-supplied claim MUST NOT select a weaker validation path or establish an Identity Binding.¶

Credential metadata follows its credential specification; discovery MUST NOT establish trust. Request hints, discovered client metadata, and unverified JWT claims MUST NOT by themselves establish credential-authority trust or change an approved Identity Binding or Client Association.¶

The IdP MUST NOT substitute one of three distinct functions for another:¶

• Client authentication: evidence authenticating the OAuth client.¶

• Agent resolution: resolution of the authenticated dedicated-client identity or independently validated workload identity through an Identity Binding to exactly one Agent Principal.¶

• Key possession: proof that the presenter controls a key, with the binding semantics of the proof mechanism.¶

Up to three identities meet in one request:¶

• the workload identity asserted by accepted evidence (Section 5.3.1);¶

• the authenticated OAuth client; and¶

• the Agent Principal (Section 5.3.6).¶

None of them is inferred from another. With a dedicated client, the authenticated client identity is itself the resolution input, and no separate workload identity exists. The distinction between an issuer-bound presenter key and a request proof key (Section 2.2) determines what a proof establishes.¶

The same credential can serve client authentication and agent resolution without making the client and agent the same principal. Successful client authentication MUST NOT imply successful agent resolution. Successful agent resolution MUST NOT imply permission for the authenticated client to exercise that agent.¶

3.3. Canonical Identity and Tenant Boundaries

The Agent Principal identifier MUST be unique and non-reassignable within the IdP issuer's namespace, across all Governance Tenants sharing that issuer identifier. The Governance Tenant is not part of the downstream agent identity. A tenant-local identifier therefore needs qualification to meet this issuer-wide uniqueness requirement before use as an Agent Principal identifier. The Agent Principal identifier need not equal an external subject, OAuth client identifier, SPIFFE ID, display name, or instance identifier.¶

This profile provides identity continuity for the agent across changes of execution environment, through Identity Binding, and across the boundary between the IdP and the resource domain. Identity continuity is an explicit decision by the governing authority to preserve the same principal. It does not imply that the principal's permissions remain unchanged. It is also not work continuity: whether an approved task, with its purpose, approval, and lifecycle, still justifies an action is outside this profile.¶

After a transfer to a different Governance Tenant under a different administrative authority:¶

• The IdP MUST assert the agent under a new Agent Principal identifier.¶

• Delegations held for the previous identifier do not carry forward automatically (Section 3.6.2).¶

• RAS principal links held for the previous identifier MUST NOT be re-keyed to the new identifier (Section 6.3).¶

For example, moving an agent to another customer's governance domain creates a new identity. Renaming a tenant or changing its owner or administrator within the same governance domain does not by itself change the principal. This document defines no cross-tenant identity migration protocol.¶

The IdP MUST establish an unambiguous Governance Tenant and, before issuance, the Target Tenant for the requested RAS and resource. The RAS MUST interpret an agent identifier in its asserted issuer context and MUST NOT key agent authorization on a bare sub. Tenant resolution failures use the errors in Section 4.7 and Section 5.8.¶

A single-tenant issuer has one Governance Tenant, which the issuer identifies. A multi-tenant issuer identifies each of its tenants by tenant together with the issuer (Section 6.1 of [ID-JAG]). At a multi-tenant issuer:¶

• The IdP MUST NOT issue an ID-JAG for an agent whose Governance Tenant is not the user's tenant, which the ID-JAG's tenant claim names (Section 6.4 of [ID-JAG]). That claim therefore also names the agent's Governance Tenant.¶

• The IdP MUST include tenant, set to the agent's Governance Tenant, in every WAG (Section 5.7.2), the claim that Section 6.3 of [WAG] recommends for an issuer that several tenants share.¶

• The RAS MUST reject a WAG with invalid_grant unless tenant is present and the RAS trusts iss and tenant together for the Target Tenant, as Section 4.4.1 of [ID-JAG] requires for an ID-JAG.¶

Only a multi-tenant issuer includes tenant (Section 6.1 of [ID-JAG]), so a grant that carries it is from one, whatever the RAS's configuration says of the issuer. The RAS MUST reject such a grant with invalid_grant unless it trusts iss and that tenant together for the Target Tenant. A RAS configured with the issuer alone therefore fails closed instead of trusting every tenant of a shared issuer.¶

A RAS's trust in a multi-tenant issuer to assert agents, including just-in-time correlation (Section 6.3.1) and an actor-gate rule that admits every agent an issuer asserts, is therefore trust in each issuer tenant the RAS trusts for the Target Tenant. The access token does not carry the issuer tenant, so an API that evaluates the actor gate itself cannot narrow such a rule to one of those tenants. The Agent Principal identifier remains unique across the issuer, and tenant does not become part of the agent's identity.¶

3.4. Governance Boundary and Execution Independence

Clients, workloads, or other actors that require independently managed authorization, delegation, attribution, resource correlation, or disablement as principals need separate Agent Principal identities. This holds even when they share a runtime, OAuth client, workload credential, or deployment. Differences in process, replica, session, worker, or credential alone do not require distinct identities.¶

An execution that shares its authorization, delegation, attribution, resource correlation, and disablement with an Agent Principal can run as that Agent Principal. A sub-agent working entirely within its parent's authority and attributed to it is an example. An execution that needs any of these separately needs its own identity.¶

Multiple executions can operate as the same Agent Principal. An agent can move between workloads or execution environments through approved Identity Bindings. Conversely, one environment can host multiple Agent Principals. The validated resolution input and its Identity Binding therefore need to distinguish exactly one Agent Principal for each authorization transaction. The IdP rejects an ambiguous mapping (Section 5.3.6), and a shared workload identity alone cannot select among agents.¶

Scaling, restarting, rescheduling, migration, credential rotation, or creation of additional executions, replicas, credentials, Identity Bindings, or Client Associations does not by itself create, merge, transfer, or increase Agent Principal authority. This profile defines no aggregate budget, quota, or concurrency semantics.¶

3.5. Grant Paths

An Agent Principal is not intrinsically self-acting or delegated. The authorization transaction determines whether it is represented as the subject, in a WAG (Section 4.2), or as the actor for a user, in an ID-JAG (Section 4.1). Authorization for one relationship does not imply authorization for the other.¶

3.6. Authorization Relationships

The basis for Agent or Delegation Authorization is a deployment choice. Administrator assignment, organizational policy, and task authorization are all acceptable, as is user consent for Delegation Authorization. Assignment and approval records and their storage are outside this profile.¶

The RAS and API determine effective resource and operation authorization, including the actor gate (Section 3.6.4). The IdP need not interpret every tool argument or business object. An issuance decision that depends on those semantics requires authoritative resource-domain evaluation, locally or through a trusted policy service.¶

4.1. Delegated Access with ID-JAG

This document profiles ID-JAG issuance and redemption through the actor extension point in Section 9.10 of [ID-JAG]. Where it is silent, ID-JAG applies unchanged.¶

4.2. Self-Acting Access with WAG

Self-acting access is a peer realization of the federation model: the Agent Principal is the subject of a Workload Authorization Grant (WAG) [WAG] issued by the IdP (Section 5.7) and redeemed at the RAS (Section 6.5). This document specifies a governed composition of WAG, including the issuance exchange, client binding, principal correlation, and grant protection. Generic WAG support does not imply these requirements. This document defines the complete wire contract it relies on, so [WAG] is an informative reference, and the composition remains subject to alignment with the evolving WAG specification (Appendix B.2.1). Appendix B.1 compares this composition with WAG-02.¶

4.3. Adoption Profiles

The adoption path preserves existing Enterprise-Managed Authorization [EMA] deployments, which need no changes to continue, and adds agent governance before requiring grant binding. The names identify deployment profiles, not assurance ratings.¶

Enterprise access is a migration baseline, not conformance to this document's governed profiles. Adding act alone does not establish governed agent conformance: identity resolution and actor authorization are also required. The adoption profiles apply to both realizations, each under its own URIs (Section 9.2).¶

"Bound" refers to sender constraint on the grant, ID-JAG or WAG, between issuance and redemption. It does not imply sender constraint on the agent-resolution credential or the resulting access token. Grant protection, workload-evidence protection, and access-token protection are separate choices. Even bound governed agent access can use bearer workload evidence and, under explicit resource policy, bearer access tokens.¶

4.4. Grant Protection

Client authentication and all governance requirements remain mandatory in either adoption profile.¶

By profile:¶

• Bound governed agent access: The client MUST supply a DPoP proof at issuance. The IdP MUST reject a missing proof with invalid_request. The RAS MUST require cnf.jkt in the grant.¶

• Governed agent access: DPoP support is OPTIONAL. The IdP and RAS MAY issue and accept grants without cnf only when trusted policy explicitly permits them for the client, trust relationship, and resource.¶

In both profiles:¶

• Supplied proof: A supplied DPoP proof MUST be validated under [RFC9449]. An endpoint that does not support DPoP MUST reject a request containing a DPoP proof with invalid_request; it MUST NOT silently ignore the proof. At issuance, a valid proof MUST result in cnf.jkt binding of the grant, as in Section 9.11.1.1 of [ID-JAG].¶

• Bound grant: A grant containing cnf MUST have a valid, supported jkt binding, and the client redeems it with the jwt-dpop grant type (Section 6.1). The RAS MUST require a fresh DPoP proof whose public key thumbprint matches exactly, as in Section 9.11.1.2 of [ID-JAG] and Section 5 of [JWT-DPOP-GRANT]. Missing required binding, unsupported confirmation, or key mismatch MUST fail with invalid_grant. A missing proof MUST fail with invalid_grant (Section 9.11.1.2.2 of [ID-JAG]) or invalid_dpop_proof (Section 5 of [JWT-DPOP-GRANT]).¶

• Unbound grant: When policy permits a grant without cnf, the client MAY present a DPoP proof only at redemption to obtain a DPoP-bound access token (Section 6.7). That proof does not retroactively bind the grant.¶

• Credential proof: Selecting governed agent access MUST NOT disable proof required by the agent-resolution input or client authentication method.¶

4.5. Client Authentication and Algorithms

Client authentication: RFC 7523 client authentication at either server follows Section 5.3.2. JWT-SVID client authentication at either server is not a dedicated-client method; an implementation that uses it claims the JWT-SVID input of [INPUTS] and follows its rules. Other configured methods MAY be used, and client identifiers and keys MAY differ between servers.¶

Algorithms: Each implementing role MUST support the capabilities below for the artifacts it produces or validates:¶

Other algorithms permitted by the selected specification MAY be used through trusted configuration and metadata.¶

4.6. Time, Replay, and Key Validation

Validators MUST enforce:¶

• Time claims: Apply the selected credential's expiration and other time rules. Reject iat later than the current time plus permitted clock skew. Under [RFC7519], iat has no not-before semantics.¶

• Clock skew: Use a configured tolerance that MUST NOT extend a configured maximum age or lifetime. It SHOULD remain within the few minutes contemplated by [RFC7519].¶

• Replay protection: Apply each credential, proof, and grant mechanism independently. Where a mechanism retains replay state, that state MUST remain in effect for as long as the credential, proof, or grant would otherwise be acceptable, including the maximum allowed skew.¶

Key lookup MUST retain the issuer or trust-domain association (Section 3.8 of [RFC8725]).¶

A fresh proof does not renew an expired credential; an unchanged identifier does not authorize a new proof key.¶

An IdP that accepts [WISE] events from a credential authority it trusts MUST stop accepting, for agent resolution, the following from the time each event takes effect (Section 2.3 of [WISE]), within the credentials, trust material, and trust domains that its configuration trusts that authority for:¶

• a credential that credential-revoked or credential-compromised identifies;¶

• trust material that trust-anchor-revoked identifies; and¶

• credentials from a trust domain that trust-domain-federation-revoked names.¶

An event about anything outside that scope changes no resolution: an authority that ends its own federation with a trust domain does not end trust that the IdP's configuration places in that domain directly. Disabling an Identity Binding or the Agent Principal in response is IdP policy (Section 12.8): an agent can have other valid bindings.¶

4.7. Token Endpoint Errors

Token endpoint errors follow Section 5.2 of [RFC6749] and the applicable extension, authentication, and proof specifications. Servers MUST validate client authentication, credentials, and proofs before authorization. Proof, grant-binding, grant-claim, and authorization-detail failures use the errors specified in Section 4.4, Section 6.2, Section 5.2, and the applicable input profile. Section 5.8 and Section 6.9 list the failures specific to each server.¶

Client authentication failures use the authentication method's error, including when the same credential supplies an agent-resolution input.¶

Error descriptions SHOULD NOT reveal identity, binding, or policy details beyond those disclosed by the error category (Section 12.3).¶

4.8. Profile Applicability and Downgrade Prevention

Profile applicability follows these rules:¶

1. Establish policy: Before exchange, trusted configuration MUST establish the applicable governed profile and minimum requirements for the client, issuer trust relationship, and target resource. The client, IdP, and RAS MUST use that configuration. This document defines no transaction-level profile negotiation.¶

2. Enforce the minimum: Each server MUST enforce its configured minimum regardless of absent actor_token, act, DPoP, or cnf. Their presence or absence MUST NOT select a different profile. Metadata advertises capabilities; it MUST NOT authorize a lower profile or override resource policy.¶

3. Prevent fallback: Implementations MUST NOT retry a failed governed request as ordinary EMA or drop proof to retry as governed agent access. A lower profile requires a separately authorized configuration, not an error-driven fallback.¶

4. Enforce resource policy: The RAS and API MUST agree on the minimum profile for their resource. The API relies on the RAS to enforce grant protection. An access token's cnf describes the token's own protection. It does not establish which grant profile was used. Where multiple paths share a resource, applicability follows Section 7.¶

An implementation MAY serve existing EMA and either governed profile concurrently under these rules. Supporting the bound profile does not require accepting grants without sender constraint or advertising the intermediate profile.¶

Migration changes the configured profile after the participating roles implement its requirements. It does not relabel previously issued grants or refresh tokens.¶

5.1. Issuance Prerequisites

Relationships: The IdP MUST issue a grant only under the applicable identity, client, delegation, and target relationships (Section 3); [GUIDE] describes their configuration.¶

Downstream client: The IdP MUST derive the grant's client_id from an authoritative association between the authenticated IdP client and that client's registration at the target RAS (Section 5.1 of [ID-JAG]). This client registration association is not a Client Association. If the client uses one identifier at both servers, such as a Client ID Metadata Document (CIMD) Client Identifier URL [CIMD], the association is the identity mapping. A client-supplied downstream client identifier MUST NOT select or override that association.¶

Several IdP clients MAY map to one registration at a RAS, such as the dedicated clients of one platform's agents, or one client registered at several IdPs. The RAS then cannot tell those clients apart: its client policy, its audit, and any restriction keyed on client_id apply to all of them, while a restriction of an agent follows the agent (Section 6.3). Every holder of that registration's credentials can redeem a grant that names it, and can use a refresh token bound only to that registration (Section 8.2), so only a grant or refresh token also bound to a key stays with the key that obtained it.¶

An IdP client MAY also map to a different registration at a RAS for self-acting grants than for delegated grants, so that the client registration tells the two token populations apart (Section 7.1). The association then names a registration for each acting relationship, and a grant's client_id is the registration for its own. The client still holds both acting relationships at the IdP; Section 12.7 describes the separation that limits an agent refused for a user.¶

5.2. Token Exchange Request

Both grants are requested with a token exchange request [RFC8693] to the IdP token endpoint. The client authenticates as the configured client and supplies any proof required by Section 4.4. Both requests carry these REQUIRED parameters:¶

Resource: A client requiring access to multiple resources MUST obtain a separate grant for each resource. The IdP MUST reject multiple resource parameters with invalid_target. The resource URI conveys the Target Tenant through the configured resource-to-tenant association, not the IdP's Governance Tenant.¶

Scope and authorization details: authorization_details MAY accompany the required non-empty scope and is processed under ID-JAG. The IdP MUST constrain all granted scope and authorization_details to the requested resource. If requested authorization details cannot be confined to it, the IdP MUST reject the request with invalid_authorization_details under Section 6 of [RFC9396] rather than authorize additional resources.¶

Section 5.6.1 and Section 5.7.1 add the parameters of each grant.¶

5.3. Agent Resolution

The IdP resolves the Agent Principal from validated inputs through an approved Identity Binding. For delegated access, it also resolves the user (Section 5.6.3). The RAS then correlates both with its local principals (Section 6.3, Section 6.4.2).¶

5.4. Issuance Authorization

Validated identity does not grant authority. After resolution under Section 3.2, Section 5.3, and, for delegated access, Section 5.6.3, the IdP MUST authorize issuance under current assignments and policy for the resolved agent, authenticated client, acting relationship, Governance and Target Tenants, RAS, resource, and requested authority. The authority asserted in a delegated grant MUST be bounded by both:¶

• The authority the IdP is authorized to assert for the user.¶

• The authority permitted by the agent's delegation authorization (Section 3.6.2).¶

For a self-acting grant, the asserted authority MUST be bounded by the Agent Authorization (Section 3.6.1).¶

Issuance and denial follow these rules:¶

• The IdP MAY narrow scope, reflecting the result in the grant and response under [RFC8693]. If no scope can be granted for delegated issuance, it MUST reject with actor_unauthorized when no applicable Delegation Authorization covers the agent, user, client, and target, or when policy categorically prohibits the agent for the requested scope, and otherwise with invalid_scope, as when an applicable authorization's scope ceiling excludes the request (Section 6.6.2 of [ACTOR-PROFILE]). For self-acting issuance, it MUST return the errors of Section 5.8.¶

• The IdP MUST NOT issue by dropping a required actor or binding, substituting an external identifier for the Agent Principal, or weakening proof requirements.¶

• Denied delegation MUST NOT fall back to self-acting access.¶

Before issuance, the IdP MUST apply current binding and authorization policy and reject an inactive agent or withdrawn binding once the change has been applied. The IdP MUST apply such a change within a configured freshness limit on cached policy data.¶

If IdP approval requires a downstream lifetime condition that the selected composition cannot enforce, the IdP MUST reject issuance with actor_unauthorized for delegated issuance or invalid_target for self-acting issuance. It MUST NOT discard that condition or treat a shorter grant lifetime as enforcing it. Revocation follows Section 12.8.¶

5.5. Common Grant Claims, Lifetime, and Response

Each grant carries these claims in addition to those of its own section (Section 5.6.5, Section 5.7.2):¶

Lifetime: A grant has these limits:¶

• Configured limit: The grant lifetime SHOULD be at most five minutes and MUST NOT exceed the configured lifetime limit.¶

• Agent-resolution input: The grant MUST NOT outlive the validated resolution credential, using the bound in the following table or in the input's profile. The dedicated-client assertion is the exception: it MUST be valid when the request is authenticated, but it authenticates one transaction and does not cap the grant.¶

The ID-JAG is also limited by its subject credential (Section 5.6.5).¶

Response: The response follows Section 4.3.4 of [ID-JAG]; for a WAG, issued_token_type is the WAG token type. For a bound grant, the client MUST retain the DPoP key for redemption and SHOULD inspect the grant to confirm that cnf.jkt identifies that key (Section 9.11.1.1 of [ID-JAG]).¶

5.6. Delegated Issuance: ID-JAG

5.7. Self-Acting Issuance: WAG

Self-acting issuance is one token exchange with two resolution modes. The relationship and downstream client rules of Section 5.1 and the client authentication and algorithm rules of Section 4.5 apply. The IdP MUST:¶

1. Authenticate the client and validate the resolution input under Section 5.3.1 and Section 5.3.5, as presented under Section 5.7.1.¶

2. Resolve the Agent Principal through an active Identity Binding (Section 5.3.6) from the configured input: the workload credential presented as the subject token, or the authenticated client identity.¶

3. Verify the Client Association for self-acting issuance (Section 5.3.6).¶

4. Authorize issuance under Section 5.4, applying Agent Authorization (Section 3.6.1) for the requested RAS, resource, and authority. No user is involved.¶

5. Apply Section 4.4 and issue the WAG under Section 5.7.2.¶

Failures: Section 5.8.¶

The client redeems the WAG under Section 6.1, and the RAS processes it under Section 6.5; Appendix A.1.6 shows the messages.¶

5.8. Issuance Errors

In addition to Section 4.7, the IdP uses these errors:¶

Subject and agent-resolution credential failures use invalid_request, as Section 2.2.2 of [RFC8693] requires and Section 4.3.4.3 of [ID-JAG] profiles. A valid credential that resolves no active Identity Binding, Agent Principal, or Governance Tenant, or no user, uses invalid_grant (Section 4.7).¶

Self-acting issuance adds these errors:¶

6.1. Redemption Request

The client redeems either grant at the RAS token endpoint: an ID-JAG as in Section 4.4 of [ID-JAG], and a WAG as in [WAG]. A grant containing cnf is redeemed with the grant type urn:ietf:params:oauth:grant-type:jwt-dpop ([JWT-DPOP-GRANT]), and a grant without cnf with the JWT bearer grant type, urn:ietf:params:oauth:grant-type:jwt-bearer. The request includes the proof required by Section 4.4 and the applicable access-token protection. These additional parameters are REQUIRED unless marked OPTIONAL:¶

A grant containing cnf presented with jwt-bearer is rejected with invalid_grant, whether or not the request carries a DPoP proof (Section 5.2 of [JWT-DPOP-GRANT]).¶

6.2. Common Grant Validation

Both grants use these checks. Section 6.4.1 and Section 6.5 each apply them at the step that names them:¶

1. Proof and client: Enforce Section 4.4, including the configured minimum profile even when cnf is absent, and independently authenticate the client identified by client_id.¶

2. Authority:¶

   • Resource claim: Require resource to be one URI, encoded as a JSON string or a single-element JSON array (Section 3.1 of [ID-JAG]), and normalize it to that URI. Reject a missing or invalid value, an empty array, or a multi-element array with invalid_grant.¶

   • Requested resource: The RAS MUST reject multiple resource parameters, or a requested resource different from that URI, with invalid_target under Section 2 of [RFC8707].¶

   • Scope: Require the grant's scope claim to be a non-empty string. Reject a missing, empty, or non-string claim with invalid_grant. A supplied request scope MUST be a non-empty subset of that claim, or the RAS MUST return invalid_scope.¶

   • Authorization details: Apply ID-JAG's processing for authorization_details. Reject the grant with invalid_grant if its authority extends beyond that resource.¶

Grant replay: The RAS accepts a grant when every check required for issuance has passed and it issues an access token, or when every check required for admission to deferral has passed and it records a pending governed redemption ([OVERSIGHT]). A grant is accepted only once when it has no enforced grant-level sender constraint, when the RAS admits it to deferral, or when it is bound and no explicit policy lets the RAS accept it again. For such a grant, the RAS MUST record its (iss, jti) as accepted atomically with that commitment, so that of concurrent presentations at most one is accepted. A request rejected before acceptance MUST NOT record the grant as accepted or change an existing record, so a client can correct the request, such as a missing proof or a wrong resource, and present the same grant again. For a grant without an enforced grant-level sender constraint, the RAS MUST reject a grant whose validated (iss, jti) it has already accepted while that grant remains acceptable. A proof used only for client authentication or access-token binding is not such a constraint. The RAS MAY accept a bound grant again under explicit policy, each time with a fresh proof that matches its cnf.jkt (Section 4.4). This applies to unbound ID-JAGs the single-use option of Section 4.4.4 of [ID-JAG] in place of re-submission, and settles for the WAG the replay question that Section 9 of [WAG] leaves open. The retention rule of Section 4.6 applies to accepted identifiers.¶

6.3. Agent Principal Correlation

The Agent Principal identity is the pair of IdP issuer and agent identifier, carried as (act.iss, act.sub) in an ID-JAG and as (iss, sub) in a WAG. The RAS MUST:¶

• Resolve that qualified identity independently of any user identity; a bare subject, display name, or OAuth client identifier MUST NOT replace it.¶

• Deny authorization that depends on a missing agent record, whether that record is provisioned in advance or created just in time under Section 6.3.1.¶

A changed Identity Binding or local agent link MUST NOT transfer an existing delegation to a different agent.¶

The IdP or an authorized directory connector can provision local agent principals, keyed by the same pair. No provisioning protocol is required ([GUIDE]). Once deactivation is applied, the RAS enforces Section 8.3.¶

6.4. Delegated Redemption: ID-JAG

6.5. Self-Acting Redemption: WAG

Processing: The RAS MUST:¶

1. Grant: Validate the grant under [RFC7523], with the claims of Section 5.7.2. Require the JWT typ header parameter oauth-wag+jwt (Section 6.1 of [WAG]), so that an ID-JAG or another JWT from the same issuer cannot be accepted as a WAG. Require iss to be a configured governing IdP for the asserted agent namespace, and at a multi-tenant issuer apply the tenant rule of Section 3.3. Reject a WAG that contains act with invalid_grant.¶

2. Proof and client: Apply the proof and client checks of Section 6.2.¶

3. Replay: Apply the grant replay rule of Section 6.2.¶

4. Authority: Apply the authority checks of Section 6.2.¶

5. Correlation: Resolve the pair (iss, sub) under Section 6.3 to one local agent principal in the authorized Target Tenant. The RAS MUST have that authorized correlation before issuance. It is provisioned in advance or, where resource policy permits, created just in time from the WAG (Section 6.3.1), so a RAS can accept a previously unseen agent's first WAG as Section 3 of [WAG] describes; creating the record does not authorize the agent.¶

6. Policy: Apply current RAS policy for the agent, client, tenant, and resource. A valid grant sets an authority ceiling; it does not require issuance.¶

7. Output: Issue an access token under Section 6.6 and Section 6.7, with the local agent principal as sub and no act. The RAS MUST NOT issue a refresh token for a WAG redemption.¶

6.6. Access Token Issuance and Response

After validation and authorization, the RAS MUST issue an access token with these claims under [RFC9068], or equivalent context through Section 6.8:¶

• Identity: For delegated access, the resolved user as subject and the validated act unchanged under Section 6.4.3. For self-acting access, the local agent principal as subject and no act (Section 6.5).¶

• Authority: Redeemed resource as audience and non-empty authorized scope (otherwise invalid_scope), without broadening authority.¶

• Protection: The binding selected under Section 6.7.¶

• Tenant: By default, the tenant-specific resource URI, which becomes the audience under Section 3 of [RFC8707]. A deployment MAY instead carry the Target Tenant in a configured claim that names it, or in authoritative token context. The grant's tenant, an issuer tenant (Section 3.3), is not that claim.¶

• Authorization details: Effective authorization_details, when used, in the JWT claim or introspection member under Section 9 of [RFC9396]. Narrowing or translating authorization MUST NOT discard restrictions in those details or expand the approved authority.¶

• Expiration: Within RAS-local lifetime policy under Section 3.6.3 and any applicable refresh-authorization limit.¶

Response: The response follows Section 4.4.2 of [ID-JAG]. The client MUST reject an output that does not satisfy its configured protection requirement.¶

Instance context: When the client authenticates at redemption with a Client Attestation validated under [INSTANCE], the RAS MAY include instance context for that presenting instance under Section 7 of [INSTANCE]. The RAS MUST NOT copy or remap instance context from the ID-JAG or WAG. Instance context identifies an execution of the client; it is not an actor, and it does not replace act, sub, or client_id.¶

Whether the response also carries a refresh token, and how that token is bound and used, follows Section 8.2.¶

6.7. Access-Token Protection

Selection: The RAS MUST issue a sender-constrained access token unless the resource is explicitly configured to permit bearer tokens. The permitted protection is selected through trusted client and resource configuration before issuance, not by a request flag. A validation failure MUST NOT trigger a weaker mode.¶

• DPoP or bearer: Where the effective client and resource configuration leaves a choice only between DPoP and bearer tokens, the RAS MUST bind the access token to the key of a valid DPoP proof presented at redemption. Under that configuration, the RAS issues a bearer token only when no proof is presented.¶

• Mutual TLS: Where the effective client and resource configuration selects mutual TLS, mutual TLS applies regardless of any DPoP proof, including the grant proof required below.¶

A proof never selects a protection that configuration does not permit. When a grant without cnf is redeemed without the proof that the access-token protection of the grant's resource requires, a DPoP proof or, for mutual TLS, the client certificate, the RAS MUST reject the request with invalid_grant (Section 9.11.1.2.4 of [ID-JAG]), for a WAG as for an ID-JAG. That refusal is one of the grant's checks, reported before replay and authority failures (Section 6.9.1). The RAS selects access-token protection only after the proof checks succeed, so a bound grant redeemed without its proof fails as Section 4.4 specifies, with invalid_grant or invalid_dpop_proof, whatever protection the resource requires.¶

For mutual TLS with a bound grant, the client MUST also prove possession of the grant's DPoP key in the same redemption request. Certificate possession alone does not redeem the grant. The access token then carries cnf.x5t#S256 but not cnf.jkt, as Section 5 of [RFC9449] allows for access tokens that are not DPoP-bound. Receipt of the grant proof does not override the configured access-token protection. A native mutual-TLS-bound grant is future work (Appendix B.3).¶

Enforcement: The RAS MUST NOT copy the grant's cnf into an access token whose binding will not be enforced. Clients and APIs MUST NOT treat a constrained token as an unconstrained bearer token or bypass an unrecognized confirmation method.¶

6.8. Optional Opaque Access Tokens and Introspection

The RAS MAY issue an opaque access token instead of a JWT when the API obtains equivalent context through token introspection [RFC7662]. For an active token:¶

• Identity and authority: The response MUST carry sub, aud, scope, client_id, and, for delegated access, the validated act object unchanged, as the act introspection member registered by Section 7.5 of [RFC8693].¶

• Context: The response MUST preserve the Target Tenant representation and any effective authorization_details required by Section 6.6.¶

• Protection: For a bound token, the response MUST carry cnf with jkt under Section 6.2 of [RFC9449] or x5t#S256 under Section 3.2 of [RFC8705].¶

An introspection call that does not return a JSON object with a boolean active member does not complete token validation. That includes a transport failure, a timeout, and an error response from the introspection endpoint (Section 2.3 of [RFC7662]), including one that rejects the API's own credentials: none says anything about the token, so Section 7.6 applies. A response with active set to false, or an active response that fails Section 7.2, establishes that the token is invalid. A cached active response used within the limits of Section 7.2 completes the check.¶

6.9. Redemption Errors

In addition to Section 4.7 and the checks of Section 6.2, the RAS uses these errors:¶

7.1. Profile Applicability

This profile defines no in-band discriminator.¶

• The RAS and API MUST establish profile applicability through trusted issuer, client, and resource configuration or authoritative token-issuance context.¶

• The RAS MUST NOT issue governed and ordinary tokens for the same client and resource unless the API can distinguish them through validated claims or authenticated introspection context.¶

• The RAS MUST issue tokens such that the API can determine, from trusted token context, which adoption profile and acting relationship authorized them.¶

The API MUST reject ambiguous applicability and reject missing or malformed act for a configured governed delegated population. Self-acting tokens carry no act (Section 7.4). An ordinary act claim alone does not establish governed issuance.¶

Separate client registrations, audiences, or issuers for the delegated and self-acting populations satisfy these rules; a client registration association can name a separate registration for a client's self-acting grants (Section 5.1). The absence of act alone does not: a delegated token lacking act would otherwise be accepted as self-acting.¶

Conformance does not by itself provide a portable discriminator for every mixed-token deployment (Section 10.2).¶

7.2. Token Validation

For tokens subject to this profile, the API MUST validate access tokens under [RFC9068], or obtain the same context under Section 6.8, and MUST enforce the following requirements:¶

• Protection: Enforce the configured resource mode (Section 6.7) and all token confirmation claims. Validate DPoP under [RFC9449], certificate binding under [RFC8705], or permitted bearer use under [RFC6750].¶

• Authority: Require non-empty scope with its defined type. Enforce any effective authorization_details under [RFC9396], using the API's defined semantics for their combination with scope.¶

• Tenant: Resolve exactly one authorized Target Tenant from token context, as represented under Section 6.6. A request parameter alone cannot establish it. Verify that it matches the tenant of the requested operation. Missing, ambiguous, or conflicting tenant context MUST result in denial.¶

Introspection caching: A cached active response MUST NOT be used beyond exp or the freshness limit of the resource's disablement policy. Without exp, the API MUST introspect again for subsequent requests rather than reuse an active response. This narrows Section 4 of [RFC7662] so cached authorization cannot outlive an expiration unknown to the API.¶

Instance context: An API that uses instance context applies Section 7.5 of [INSTANCE]. It MUST NOT treat instance context as satisfying the actor gate or the agent's own permissions. Attributing a request to an instance requires the sender constraint of Section 7.3 of [INSTANCE].¶

7.3. Delegated Access

For delegated tokens, the API MUST also:¶

• Identity: Require one act object with non-empty iss and sub and no nested act. Trust configuration MUST authorize the RAS to assert that IdP-qualified agent identity; act.iss need not equal the access-token issuer.¶

• Authority: Enforce user permissions and the actor gate under Section 3.6.4 and Section 8 of [ACTOR-PROFILE].¶

7.4. Self-Acting Access

For self-acting tokens, the API enforces the agent's own permissions together with the requirements of Section 7.2. No actor gate applies, and a governed self-acting token has no act.¶

7.5. Optional Policy Services

If the API delegates authorization evaluation to a policy decision service, it MUST:¶

• Preserve the distinction between the user, the issuer-qualified Agent Principal, and the OAuth client.¶

• Supply the tenant and token constraints needed to evaluate the requested operation.¶

• Take the user, the Agent Principal, the OAuth client, the tenant, and the token constraints that it supplies only from the access token validated under Section 7.2, or from an authenticated introspection response (Section 6.8), and from trusted configuration, including the API's own resolution of those identities to local principals. Attributes derived from the request, such as from a tool call's arguments, never supply or override them.¶

For a self-acting token, the local principal stands for the Agent Principal. An API that relies on the policy service for the actor gate MUST obtain from the decision whether the actor gate denied the request, or evaluate the gate itself, so that it can report the failure that Section 7.6 selects. [AUTHZEN] is one optional evaluation interface. This profile defines no mapping to it. A policy permit does not override the token's constraints.¶

7.6. Error Responses

Challenges and scope errors use the selected scheme: DPoP under Section 7.1 of [RFC9449], or Bearer under [RFC6750] for bearer and mutual-TLS tokens.¶

When a request fails more than one check, the API MUST report the failure that comes first in this table, whatever order it evaluates the checks in:¶

Row 3 applies only when the API has identified the requested operation, its target, and its tenant without the invalid argument. A failure to present the access token or proof belongs to row 1, and a request whose operation, target, or tenant the API cannot identify is outside this table (Section 12.3). A request that names a target that does not exist is within this table: the target's absence is not a failure in it, so it does not displace a failure the table selects. An invalid argument is established from the request itself; it is not a check that cannot complete. For a row-3 failure, the API MUST NOT perform the operation, and the response MUST NOT convey actor_unauthorized or insufficient_scope.¶

Actor denial MUST NOT use insufficient_scope, and the API MUST NOT return actor_unauthorized for any failure other than an actor-gate denial. The API MUST NOT expose actor-specific rejection details outside the trust domain.¶

The last row is this profile's restriction. Section 3 of [RFC6750] requires a challenge when a token does not enable access but does not prescribe this response; neither error code would offer a remedy that can succeed. The challenge uses the selected scheme without an error attribute, and a Bearer challenge carries realm. A response body is application-specific but MUST NOT convey actor_unauthorized or insufficient_scope.¶

If a check cannot complete, for example because a policy service or the introspection endpoint (Section 6.8) is unreachable or returns a response the API cannot interpret, the API MUST NOT perform the operation. If it has established a failure and no check that did not complete comes earlier in this table, it reports that failure as the table selects. Otherwise it MUST NOT report a denial from this table: it responds with HTTP status code 503 (Service Unavailable) (Section 15.6.4 of [RFC9110]) and SHOULD include a Retry-After header field (Section 10.2.3 of [RFC9110]). Evaluation order therefore does not change the response.¶

8.1. Client Token Reuse

The client associates each cached grant, access token, and refresh token with its authorized context:¶

• Agent Principal and, for delegated access, user;¶

• Governance and Target Tenants;¶

• OAuth client registrations and target RAS;¶

• resource, authority, and applicable profile; and¶

• proof binding.¶

The client MUST reuse a token or grant only when that context authorizes the operation. A shared client identifier or matching scope alone MUST NOT permit reuse across agents, users, or tenants.¶

If the client cannot establish that association, it MUST obtain a token or grant for the current context (Section 10.3).¶

8.2. Optional RAS Refresh Tokens

Issuance: The RAS SHOULD NOT issue refresh tokens, retaining Section 4.4.4 of [ID-JAG], but MAY do so for authorized long-running work under explicit policy. A WAG redemption never yields a refresh token (Section 6.5).¶

Binding: The RAS MUST bind each refresh token to the authenticated client and apply the first applicable additional sender-binding rule below. Bindings required by the client-authentication method, such as Section 10.3 of [ATTEST], apply in every row. Refresh-token rotation does not replace them.¶

Without DPoP, certificate, or authentication-method binding, the RAS requires explicit policy permitting client-bound refresh without sender constraint and uses rotation under Section 4.14 of [RFC9700].¶

Resource: A refresh request MAY include one resource parameter under Section 2.2 of [RFC8707] solely to identify the retained resource. If omitted, the RAS MUST use that resource. If supplied, its value MUST match the retained resource exactly. The RAS MUST reject multiple values or a different resource with invalid_target.¶

Processing: On every refresh, the RAS MUST:¶

1. Client and proof: Authenticate the bound client and enforce the retained authentication-method binding and any additional sender binding under RFC 9449 or RFC 8705. Dropping or replacing a sender binding requires a new grant.¶

2. Authorization context: Preserve the user, qualified actor, the grant's tenant at a multi-tenant issuer, Target Tenant, resource, and authorization ceiling, including authorization_details. Apply current trust in the issuer and that tenant (Section 3.3), current local user and actor policy, and Section 6 of [RFC9396].¶

3. Profile: Enforce current minimum-profile policy against the profile under which the grant was accepted. Reject with invalid_grant if it no longer qualifies. Adding a proof does not upgrade that authorization.¶

4. Lifetime: Enforce a finite absolute authorization expiration set at issuance under local policy and an inactivity limit under [RFC9700]. Rotation, refresh, or repeated redemption of the same ID-JAG MUST NOT reset the absolute expiration. Access beyond it requires a new ID-JAG and therefore a fresh IdP decision. That new ID-JAG starts a new authorization period and leaves the previous expiration unchanged.¶

5. Output: Issue access tokens under Section 6.6 and Section 6.7, expiring no later than the absolute authorization expiration.¶

8.3. Applied Disablement and Revocation

When a principal disablement, correlation removal, or local restriction is applied at the RAS, the RAS MUST:¶

• Check current locally applied eligibility at grant redemption and refresh, in addition to grant validation and the actor gate.¶

• Invalidate authorization derived from grants for that qualified agent and Target Tenant, including refresh tokens, when the principal is disabled or its correlation is removed. The RAS retains enough association for this from the time it issues that authorization.¶

• Not let refresh bypass a principal restriction or restore revoked authorization; reactivation permits new decisions only.¶

9.1. Conformance Claims

This profile does not establish trust in previously unknown agent issuers or automatically create Identity Bindings from presented credentials.¶

Unless explicitly limited to bound grants or a named profile, the requirements of this document apply to both governed adoption profiles. Conformance claims MUST identify the supported profile by its URI (Section 9.2), the realization, the implemented role, supported inputs, and any claim of generic shared-client interoperability. An implementation supports delegated access, self-acting access, or both.¶

The IdP, RAS, and client MUST implement their respective requirements in:¶

• Section 3, Section 4, Section 5.3, Section 9, and Section 12; and¶

• the parts of Section 5, Section 6, Section 7, and Section 8 that apply to each supported realization.¶

An input defined in another input profile, such as [INPUTS], adds that profile's requirements for implementations that claim it.¶

Each realization has this mandatory interoperability path:¶

• Issuance: The client and IdP MUST implement dedicated-client resolution using RFC 7523 private_key_jwt authentication (Section 5.3.2). For delegated access, they MUST also implement ID Token subjects.¶

• Redemption: The client and RAS MUST implement private_key_jwt for redemption. DPoP support and use are REQUIRED for bound governed agent access; governed agent access follows Section 4.4.¶

• API: The API MUST implement Section 7, with Section 7.4 for self-acting access.¶

Existing platform JWTs, SAML subjects, IdP refresh-token subjects, and the inputs of other input profiles, such as [INPUTS], are OPTIONAL capabilities. Claiming an input requires that input's rules, not support for another input. An implementation that claims generic shared-client interoperability MUST support the existing platform JWT input (Section 5.3.3): an IdP by accepting it, and a client by presenting it. Implementations that support only different native inputs do not interoperate on a shared client, and their conformance claims show this.¶

ID-JAG requires support for Identity Assertions (Section 4.3 of [ID-JAG]). Requiring ID Token subjects specifically gives independent implementations a common subject-token format. This is an implementation baseline, not a requirement to deploy one client per agent: deployments MAY use mutually supported optional inputs (Section 10.1).¶

9.2. Authorization Server and Client Metadata

The governed profiles have distinct identifiers:¶

• Governed agent access: urn:ietf:params:oauth:grant-profile:id-jag-governed-agent¶

• Bound governed agent access: urn:ietf:params:oauth:grant-profile:id-jag-agent-federation¶

• Self-acting governed agent access: urn:ietf:params:oauth:grant-profile:wag-governed-agent¶

• Self-acting bound governed agent access: urn:ietf:params:oauth:grant-profile:wag-agent-federation¶

Enterprise access uses the base urn:ietf:params:oauth:grant-profile:id-jag identifier under ID-JAG; that identifier alone makes no governed-agent conformance claim.¶

These URIs identify RAS and client processing. No URI claims a credential class, continuation support, a particular workload-evidence protection, or access-token protection; these are capabilities and configured minimums.¶

10.1. Identity Provider

• Bindings and associations: For a dedicated client, deployments can administer the Identity Binding and the Client Association in one registration or policy object; they remain separate checks (Section 5.3.6).¶

• Dedicated clients and user sign-in: An ID Token's audience identifies the authenticated IdP client (Section 5.6.2). A dedicated deployment therefore needs a user authorization flow for each agent's client registration, though an existing IdP session may avoid another login prompt. A platform that keeps its shared single sign-on (SSO) client instead uses the existing platform JWT (Section 5.3.3) or an optional input.¶

10.2. RAS and API

• Actor gate: The actor gate (Section 3.6.4) can be implemented through an agent registration, tenant assignment, consent policy, or another explicit rule.¶

• Attribution: Audit records that identify both the user and the issuer-qualified actor, rather than the client identifier alone, preserve attribution.¶

• Mixed token populations: Where one issuer serves ordinary, delegated, and self-acting access to one API, the RAS can use a separate client registration or audience for each population, and the API is configured with that mapping (Section 7.1). A deployment that needs one registration and one audience for several populations needs an additional bilateral contract.¶

10.3. Client

• Cached tokens: The association of Section 8.1 can use trusted request and configuration context; clients need not parse opaque tokens. A credential change alone need not invalidate cached tokens when the governed principal and authorization context remain the same.¶

• Recovering from errors: An error establishes only what the sections that assign it define:¶

  • invalid_client: a consumed client assertion is replaced by one with a fresh jti, as the retry rule of Section 5.3.2 requires. An unknown client, a wrong key, or an unsupported method needs configuration, not a retry.¶

  • invalid_request at the IdP: a malformed request needs correction. An invalid subject credential or agent-resolution input gets the same code, so a client whose unchanged request previously succeeded can make one recovery attempt with a fresh subject credential and agent-resolution input of the same identity, client, and credential class (Section 4.3.4.3 of [ID-JAG]).¶

  • invalid_grant at the IdP: a valid credential resolved no user, or no active Identity Binding, Agent Principal, or Governance Tenant; renewal cannot repair it.¶

  • invalid_grant at the RAS: a rejected request does not consume the grant (Section 6.2). After correcting what it can detect itself, such as a missing proof, including one that the resource's access-token protection requires, or a grant addressed to another server, a client can present the same grant again. Otherwise it can make one recovery attempt with a new grant for the same identity and client (Section 4.4.4 of [ID-JAG]). The code does not say which check failed (Section 12.3), and renewal cannot repair a disabled agent, a missing proof, a resource the RAS does not govern, or a malformed grant.¶

  • invalid_scope: the client corrects the requested scope using authority it knows is permitted. Reducing a request helps only if what remains is permitted.¶

  • access_denied at the RAS: the grant is valid, but RAS policy other than the actor gate refuses it; a new grant does not help (Section 4.4.3 of [ID-JAG]).¶

  • invalid_target: covers an unresolved target, or a tenant unresolved at the IdP, a missing client registration association, and the refusals of self-acting issuance, including an unenforceable approval condition.¶

  • actor_unauthorized: another actor credential or grant path might succeed (Section 9 of [ACTOR-PROFILE]); the same request will not. Self-acting access in place of a refused delegation is not such a path (Section 5.4, Section 12.7).¶

  • At an API, insufficient_scope calls for a token with more authority, which can need a new governed grant; a 403 whose challenge has no error attribute has no token-level remedy; a 503 can be retried after any Retry-After interval; and the rejection of an invalid argument calls for a corrected request (Section 7.6).¶

  Apart from the invalid_client, invalid_request, and invalid_grant attempts above and a 503, a client does not retry the unchanged request automatically. A later change in policy or authorization makes a new request a new decision. Section 4.8 forbids retrying at a lower profile, Section 5.3.5 forbids falling back from rejected evidence to authentication context, and Section 5.4 forbids falling back from delegated to self-acting access.¶

11.1. Conformance Reference Implementation

• Organization: the document author.¶

• Description: a test-only IdP, RAS, and API, with an executable suite of positive and negative cases that plays the client: https://github.com/mcguinness/agent-principal-profiles/tree/main/conformance.¶

• Maturity: prototype. State is in memory, there is no TLS, and keys are generated at start; it exists to run the suite.¶

• Coverage: delegated access on the mandatory interoperability path (Section 9.1): dedicated-client resolution with private_key_jwt and ID Token subjects; both delegated adoption profiles, with grants redeemed under jwt-bearer or jwt-dpop; DPoP-bound and, where a resource permits them, bearer access tokens; DPoP nonces; the actor gate at the RAS and the API; tenant-pair authorization at the IdP; optional just-in-time correlation; the error selection order and optional policy services at the API; introspection of opaque tokens; the existing platform JWT input for a shared client, with a dedicated-issuer credential class and exact issuer-and-sub bindings; WAG issuance from client authentication and WAG redemption, with a separate self-acting registration; and the deferred redemption of [OVERSIGHT] at the RAS, for an ID-JAG. It does not implement presented-evidence WAG issuance, deferred WAG redemption, platform JWT selectors, the binding of key-bound platform JWTs (it refuses them), the inputs of [INPUTS], Client ID Metadata Documents, mutual TLS, refresh tokens outside a deferred redemption, [CONTINUATION], [AGENT-LIFECYCLE], or [AGENT-MANAGEMENT].¶

• Version compatibility: the editor's copy of this document and its companions; no revision has been submitted.¶

• Licensing: a Contribution under BCP 78, BCP 79, and the IETF Trust Legal Provisions; see the repository's LICENSE.md.¶

• Interoperability: not yet tested with another implementation. The suite can test a RAS and API without a governed IdP, signing grants itself.¶

• Contact: the document author.¶

• Last update: November 2026.¶

12.1. Unbound Grant Theft

Governed agent access without grant binding adds agent authorization to existing enterprise access. It still leaves a stolen grant redeemable by an attacker who can authenticate as the grant's designated client, particularly a shared client. Single use (Section 6.2) limits such a grant to one redemption; it does not prevent the first. Binding only the resulting access token does not prevent that redemption. Explicit acceptance policy, short grant lifetimes, credential confidentiality, and the no-fallback rules in Section 4.8 limit this exposure. They do not provide proof of possession of an issuer-authorized grant key.¶

12.2. Credential and Token Confusion

Credential classification and mutually exclusive validation follow Section 5.3.5 and Section 3.12 of [RFC8725]. Signature validity alone establishes neither a credential's intended use nor permission to resolve or exercise an agent.¶

Both grants are JWTs redeemed with the same JWT grant types, so the RAS tells them apart by explicit type: oauth-id-jag+jwt for an ID-JAG (Section 3.1 of [ID-JAG]) and oauth-wag+jwt for a WAG (Section 6.5).¶

12.3. Error Disclosure

Distinguishing invalid_grant from actor_unauthorized (Section 5.8) reveals that an actor was resolved but denied, but not which binding-resolution check failed. That disclosure reaches even a holder of stolen bearer evidence who passes the request's other authentication. At the RAS, actor_unauthorized (Section 6.9) tells an authenticated client holding a valid grant that the actor gate refused its agent, and access_denied that other policy refused the grant, not why; an uncorrelated or ineligible agent gets invalid_grant, as at the IdP.¶

An API that answers differently depending on whether a route, target, or tenant exists discloses that existence. Within a namespace the API protects, where it knows which access-token validation applies, the API SHOULD validate the access token, its proof, and the token's applicability to the API before returning an error whose status or content depends on that existence. This does not require validation before every rejection: a rejection that is the same for every request in the namespace, such as of an unsupported media type, discloses nothing, and the API can need to route a request to select the validation that applies, or parse it to obtain the credential. Beyond this recommendation, how the rejection of a request the API cannot identify ranks against the failures of Section 7.6, including a token validation that cannot complete, is not specified.¶

A request that names a target that does not exist is not a request the API cannot identify. Section 7.6 applies to it, so the API reports a failure that table selects, such as an actor-gate denial, before the target's absence, and a caller that would be denied does not learn whether the target exists. For the failures that table covers, its responses take precedence over the 404 (Not Found) that Section 15.5.4 of [RFC9110] permits a server to send to hide a forbidden resource.¶

12.4. Bearer Workload Evidence

Bearer evidence establishes the credential authority's assertion of the workload identity. It does not cryptographically bind the current presenter to that workload. An attacker who holds acceptable bearer workload evidence can therefore impersonate the workload and obtain a grant, bound to a grant proof key of its choice, if it also passes:¶

• client authentication;¶

• Client Association; and¶

• either the user-credential and delegation checks or the agent-authorization check.¶

Short evidence lifetimes limit this exposure; sender-constraining the output does not prevent it (Section 5.3.4).¶

12.5. Dedicated-Client Key Compromise

In dedicated-client resolution, compromise of the client's authentication key permits an attacker to authenticate as the resolution source for its bound Agent Principal. No independent workload credential is required.¶

For delegated access, the attacker still needs an acceptable user subject credential and has to satisfy Client Association and delegation authorization. For self-acting access, the key alone suffices wherever a Client Association and Agent Authorization already permit the client.¶

Grant binding does not prevent this impersonation at issuance. Unless policy independently constrains the grant proof key, the attacker can obtain a grant bound to an attacker-controlled DPoP key. The proof protects that grant against theft; it does not establish legitimate runtime provenance.¶

Runtime or workload provenance requires an agent-resolution input whose verified claims and trusted issuance policy establish it. Dedicated-client resolution alone does not. A normalized Agent Principal identity does not imply uniform runtime assurance. Authentication-key revocation and binding disablement affect subsequent issuance under Section 5.4 and Section 12.8.¶

12.6. Credential Authority and Key Isolation

A compromised credential authority can assert identities within its trusted scope. Exact bindings, tenant boundaries, and issuer-scoped key lookup (Section 4.6) limit that scope. Neither kid alone nor a union of unrelated issuers' keys establishes the assertion's source.¶

A RAS that trusts one tenant of a multi-tenant issuer relies on that issuer to keep its tenants apart: a grant's tenant is only as trustworthy as the issuer that signs for every tenant (Section 3.3). Trust in one tenant does not extend to the issuer's others, but a compromise of the issuer's signing key reaches them all.¶

Just-in-time correlation (Section 6.3.1) creates RAS state for each previously unseen agent that a trusted issuer asserts, as Section 10 of [WAG] notes. A RAS that enables it can cap the records created per issuer, or per issuer and tenant, and remove records that never become eligible. A created record authorizes nothing, so the exposure is state, not access.¶

A holder of a shared private key can present any credential issued for that key. Agent isolation therefore depends on issuance controls and key custody as well as identity mapping. Sharing the grant proof key across components widens its exposure ([GUIDE]).¶

12.7. Misuse by an Authorized Agent

This profile establishes which agent acts, for whom, and under what authorization. It does not establish that the agent uses that authority as intended. Content the agent processes, such as a document, a tool result, or another agent's output, can carry instructions that lead it to request or use authority it holds for a purpose its user or owner did not intend (prompt injection). The resulting requests are authenticated and authorized, so the checks of this profile pass.¶

The profile limits that exposure without detecting it:¶

• A grant carries one resource and the authority that the Delegation or Agent Authorization permits (Section 5.2). For delegated access, the RAS and the API enforce the actor gate (Section 3.6.4); for self-acting access, they enforce the agent's own permissions. Narrow authorizations limit what an induced request can obtain.¶

• Detection alone changes no authorization state: the agent can keep obtaining grants until its authorization is withdrawn or it is disabled. After further issuance and renewal are blocked, token lifetimes and revocation enforcement determine how long previously issued authority remains usable (Section 12.8).¶

• Every grant names the Agent Principal, and every access token carries it or the local principal correlated with it, so a resource domain can attribute, investigate, and disable one agent without affecting other agents behind the same client.¶

• [CONTINUATION] bounds each onward grant by the chain authorization and the continuing client's Continuation Association, and [OVERSIGHT] lets policy require a person's decision before sensitive authority issues.¶

Holding both acting relationships widens that exposure. An agent refused for a user, at the IdP, the RAS, or the API, can hold self-acting authority over the same resource. The IdP refuses self-acting access as a fallback from a denied delegation (Section 5.4), but it cannot link a later self-acting request to a refusal elsewhere, and a self-acting token carries no user whose permissions the API could apply. A client that holds both kinds of Client Association can therefore serve a user with the agent's own authority. A rule on clients would bind only clients that follow it. The control is separation at the IdP: a client that acts for users holds no self-acting Client Association, and self-acting work uses another IdP client with its own Client Association. A separate RAS registration for one IdP client's self-acting grants (Section 5.1) tells the token populations apart but leaves both acting relationships with that client, so it is not this separation.¶

It does not distinguish an induced request from an intended one, inspect content, or constrain how authority is used within its scope. Those controls belong to the agent's runtime, its platform, and resource policy, including decisions on individual actions. Evidence about an agent's software or configuration can inform policy; it does not establish that the agent behaves safely.¶

12.8. Authorization Changes and Revocation

Cross-system disablement needs a provisioning and signaling contract. [AGENT-LIFECYCLE] profiles one; conformance to this document does not require it. Issued authority can outlast disablement:¶

• Without a signal or online check, issued tokens remain usable until expiration.¶

• Without a bound on propagation, the remaining lifetime of existing grants, refresh authorizations, and access tokens determines the possible continuation window. The five-minute ID-JAG recommendation is not a global stopping guarantee.¶

• Even after disablement is applied, cached introspection results or offline JWTs can remain usable until their acceptance limits.¶

• Current active state alone cannot recover a missed disable-and-reenable transition or invalidate every old grant.¶

Deployments benefit from documenting their maximum disablement delay, including propagation and cache freshness.¶

Administrative actions have different effects, and none is evidence that another has occurred. The following table summarizes each effect after the change is applied at the enforcing server; it defines no new propagation mechanism:¶

The RAS requirements for applied changes are in Section 8.3. The provisioning that feeds them is a deployment choice.¶

The withdrawal of a delegation, Identity Binding, or Client Association can be propagated to derived authorization only when the IdP has retained the identifiers of the ID-JAGs it issued under that relationship. The agent identity alone cannot identify that set. Propagation can use grant-derived revocation in [AGENT-LIFECYCLE] or an equivalent signal.¶

Account-linking errors can grant access to another user's account. Section 5.6.3 and Section 6.4.2 state the checks required before authorization. Proof of key possession does not establish account ownership, and link removal does not revoke outstanding tokens.¶

12.9. External Approval

External approval MUST NOT replace credential validation, identity resolution, Client Association, or delegation authorization. A resource-local approval can satisfy an additional policy condition within the presented token's authority. It MUST NOT expand that authority or override token validity or tenant restrictions. Access beyond that authority requires new authorization through an applicable protocol. Approval before issuance or redemption follows [OVERSIGHT]; other asynchronous approval composition is deferred under Appendix B.3.¶

14.1. ID-JAG Grant Profile URIs

This document requests registration in the "OAuth URI" registry established by [RFC6755]:¶

• URN: urn:ietf:params:oauth:grant-profile:id-jag-agent-federation¶

• Common Name: ID-JAG Bound Governed Agent Access grant profile¶

• Change Controller: IETF¶

• Specification Document: Section 9.2 of this document.¶

This document also requests:¶

• URN: urn:ietf:params:oauth:grant-profile:id-jag-governed-agent¶

• Common Name: ID-JAG Governed Agent Access grant profile¶

• Change Controller: IETF¶

• Specification Document: Section 9.2 of this document.¶

14.2. WAG Grant Profile URIs

This document also requests:¶

• URN: urn:ietf:params:oauth:grant-profile:wag-agent-federation¶

• Common Name: WAG Bound Governed Agent Access grant profile¶

• Change Controller: IETF¶

• Specification Document: Section 9.2 of this document.¶

• URN: urn:ietf:params:oauth:grant-profile:wag-governed-agent¶

• Common Name: WAG Governed Agent Access grant profile¶

• Change Controller: IETF¶

• Specification Document: Section 9.2 of this document.¶

Section 11 of [WAG] registers the WAG token type urn:ietf:params:oauth:token-type:wag, the media type oauth-wag+jwt used as the JWT type, and urn:ietf:params:oauth:grant-profile:wag. This document requests no registration for them.¶

15.1. Normative References

[WISE]

Lombardo, J., Sneeggen, D., and S. O'Dell, "OpenID WISE Profile Specification 1.0, draft 03", 28 September 2026, <https://openid.github.io/ssf-wise-profile/>.

[ATTEST]

Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-12, 12 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-12>.

[INSTANCE]

McGuinness, K., "OAuth 2.0 Client Instance Identifiers", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-01>.

[ACTOR-PROFILE]

McGuinness, K., "OAuth Actor Profile for Delegation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-profile-01, 8 October 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-profile-01>.

[ID-JAG]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-06, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-06>.

[JWT-DPOP-GRANT]

Parecki, A., "OAuth 2.0 JWT Authorization Grant with DPoP Binding", Work in Progress, Internet-Draft, draft-parecki-oauth-jwt-dpop-grant-02, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-parecki-oauth-jwt-dpop-grant-02>.

[RFC10070]

Jones, M.B., Campbell, B., Mortimore, C., and F. Skokan, "Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants", RFC 10070, DOI 10.17487/RFC10070, November 2026, <https://www.rfc-editor.org/rfc/rfc10070>.

[CIMD]

Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf-oauth-client-id-metadata-document-03, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-03>.

[OPENID]

OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", 15 December 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[RFC6749]

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

[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/rfc/rfc6750>.

[RFC6901]

Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/rfc/rfc6901>.

[RFC7517]

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

[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/rfc/rfc7519>.

[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/rfc/rfc7523>.

[RFC7662]

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

[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/rfc/rfc8414>.

[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/rfc/rfc8693>.

[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/rfc/rfc8705>.

[RFC8707]

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

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[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/rfc/rfc9068>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[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/rfc/rfc9449>.

[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/rfc/rfc9700>.

[INPUTS]

McGuinness, K., "Agent Resolution Inputs for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-inputs, 9 October 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-inputs.html>.

[BCP14]

Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

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

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

15.2. Informative References

[AGENT-MANAGEMENT]

McGuinness, K., "SCIM Profile for Agent Principal Management", Work in Progress, Internet-Draft, draft-mcguinness-scim-agent-federation, 18 September 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-scim-agent-federation.html>.

[AIMS]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-01>.

[AGENT-LIFECYCLE]

McGuinness, K., "Agent Principal Lifecycle Profile for SCIM and OAuth", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-lifecycle, n.d., <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-lifecycle.html>.

[EMA]

Model Context Protocol, "Enterprise-Managed Authorization", n.d., <https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx>.

[AUTHZEN]

OpenID Foundation, "Authorization API 1.0", n.d., <https://openid.net/specs/authorization-api-1_0.html>.

[AROP]

McGuinness, K., "AuthZEN Access Request OAuth Profile - Draft 1", n.d., <https://github.com/openid/authzen/blob/main/profiles/authzen-access-request-oauth/authzen-access-request-oauth-profile-1_0.md>.

[AWS-TOKEN-CLAIMS]

Amazon Web Services, "Understanding token claims", n.d., <https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_token_claims.html>.

[AWS-AGENTCORE-OBO]

Amazon Web Services, "On-behalf-of token exchange with AgentCore Identity", n.d., <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.html>.

[ICA]

McGuinness, K. and A. Parecki, "Identity Continuation Assertion for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-mcguinness-oauth-id-continuation-assertion-02, 8 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-id-continuation-assertion-02>.

[ID-CHAINING]

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

[OVERSIGHT]

McGuinness, K., "Human Oversight Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-oversight, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-oversight.html>.

[CONTINUATION]

McGuinness, K., "Identity Continuation Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-continuation, 14 October 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-continuation.html>.

[RFC6755]

Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/rfc/rfc6755>.

[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/rfc/rfc7521>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[WAG]

Carleton, P., Steele, N., Parecki, A., Schwenkschuster, A., and B. Campbell, "Workload Authorization Grant", Work in Progress, Internet-Draft, draft-carleton-workload-authz-grant-02, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-carleton-workload-authz-grant-02>.

[SPIFFE-CONCEPTS]

SPIFFE, "SPIFFE Concepts", n.d., <https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/>.

[ENTITY-PROFILES]

Mora, S. C., Dingle, P., and K. McGuinness, "OAuth 2.0 Entity Profiles", Work in Progress, Internet-Draft, draft-mora-oauth-entity-profiles-02, 16 October 2026, <https://datatracker.ietf.org/doc/html/draft-mora-oauth-entity-profiles-02>.

[GUIDE]

McGuinness, K., "Implementer's Guide for Agent Principal Federation", <https://github.com/mcguinness/agent-principal-profiles/blob/main/IMPLEMENTERS-GUIDE.md>.

[SPIFFE-OAUTH]

Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-03, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-03>.

A.1. Walkthrough: Dedicated Client

This non-normative walkthrough exercises the common dedicated-client input, bound governed agent access, and DPoP-protected API access. Key coordinates, thumbprints, token hashes, and compact JWTs are labeled placeholders, not cryptographic test vectors.¶

The dedicated client is analysis-client at the IdP and analysis-api at the RAS. In the IdP's client-registration context, an Identity Binding maps (analysis-client, analysis-client) to agent-42. A separate Client Association permits use of that binding, and delegation authorization permits the agent to act for Alice. Alice's ID Token has audience analysis-client; subject resolution produces alice-ras for the RAS and user-108 at the resource.¶

The exchange starts at 12:01:03 UTC on September 17, 2026. The shared walkthrough in [AGENT-LIFECYCLE] uses the same identities, Target Tenant acme-data, and grant issuance time to add SCIM provisioning, introspection, disablement, and reactivation. This document alone does not imply those checks.¶

{
  "iss": "analysis-client",
  "sub": "analysis-client",
  "aud": "https://idp.example/",
  "iat": 1789646463,
  "exp": 1789646523,
  "jti": "analysis-auth-1"
}

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: IDP_DPOP_PROOF

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth
%3Atoken-type%3Aid-jag
&client_id=analysis-client
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=CLIENT_ASSERTION
&subject_token=ALICE_ID_TOKEN_FOR_ANALYSIS_CLIENT
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth
%3Atoken-type%3Aid_token
&audience=https%3A%2F%2Fras.example%2F
&resource=https%3A%2F%2Fapi.example%2Ftenants%2Facme-data%2F
&scope=files.read

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token": "ID_JAG",
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "token_type": "N_A",
  "expires_in": 300,
  "scope": "files.read"
}

{
  "iss": "https://idp.example/",
  "sub": "alice-ras",
  "aud": "https://ras.example/",
  "iat": 1789646463,
  "exp": 1789646763,
  "jti": "grant-1",
  "client_id": "analysis-api",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "files.read",
  "act": {"iss":"https://idp.example/", "sub":"agent-42"},
  "cnf": {"jkt":"JKT_K"}
}

POST /token HTTP/1.1
Host: ras.example
Content-Type: application/x-www-form-urlencoded
DPoP: RAS_DPOP_PROOF

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-dpop
&client_id=analysis-api
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=RAS_CLIENT_ASSERTION
&assertion=ID_JAG
&resource=https%3A%2F%2Fapi.example%2Ftenants%2Facme-data%2F

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token": "API_ACCESS_TOKEN",
  "token_type": "DPoP",
  "expires_in": 600,
  "scope": "files.read"
}

{
  "iss": "https://ras.example/",
  "sub": "user-108",
  "aud": "https://api.example/tenants/acme-data/",
  "iat": 1789646464,
  "exp": 1789647064,
  "jti": "access-1",
  "client_id": "analysis-api",
  "scope": "files.read",
  "act": {"iss":"https://idp.example/", "sub":"agent-42"},
  "cnf": {"jkt":"JKT_K"}
}

GET /tenants/acme-data/files/report-7 HTTP/1.1
Host: api.example
Authorization: DPoP API_ACCESS_TOKEN
DPoP: API_DPOP_PROOF

{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "K_X",
    "y": "K_Y"
  }
}

{
  "jti": "api-proof-1",
  "htm": "GET",
  "htu": "https://api.example/tenants/acme-data/files/report-7",
  "iat": 1789646468,
  "ath": "ATH_ACCESS_TOKEN"
}

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: IDP_DPOP_PROOF

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Awag
&client_id=analysis-client
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=CLIENT_ASSERTION_3
&subject_token=CLIENT_ASSERTION_3
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&audience=https%3A%2F%2Fras.example%2F
&resource=https%3A%2F%2Fapi.example%2Ftenants%2Facme-data%2F
&scope=files.read

{
  "iss": "https://idp.example/",
  "sub": "agent-42",
  "aud": "https://ras.example/",
  "iat": 1789646580,
  "exp": 1789646880,
  "jti": "wag-1",
  "client_id": "analysis-api",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "files.read",
  "cnf": {"jkt":"JKT_K"}
}

A.2. Input Variants

This non-normative variant changes only the agent-resolution input of Appendix A.1; the message sequence is unchanged, and the resulting actor is the IdP issuer and agent-42. Unlike the dedicated client, it sends actor-token parameters. [INPUTS] gives variants for its inputs.¶

The variant uses IdP client_id platform-sso, and:¶

• Proof key: In the bound profile, K signs the issuance DPoP proof.¶

• Lifetime: The input bounds the grant lifetime under Section 5.5.¶

• Client Association: It needs a separate Client Association for platform-sso (Section 5.3.6).¶

• Negative tests: The dedicated-client negative tests apply, except that replay rules follow the input specification.¶

One Agent Principal can carry a binding for each platform it runs on (Section 5.3.6), each keyed by its own issuer and selectors:¶

 Agent Principal: agent-42

 B1  JWT-SVID, orchestrated runtime                     enabled
     trust domain  platform.example
     SPIFFE ID     spiffe://platform.example/accounts/acme/
                     agents/workload-7

 B2  platform JWT, managed container service            enabled
     issuer        https://sts.amazonaws.com/
     sub           arn:aws:iam::123456789012:role/AgentRuntime
     selector      /https:~1~1sts.amazonaws.com~1/aws_account
                     = 123456789012

 B3  dedicated client, private_key_jwt                 disabled
     assertion iss  https://idp.example/clients/c1
     assertion sub  https://idp.example/clients/c1

B1 and B2 both resolve to agent-42, which the issued grant names (Appendix A.2.1 shows B2; B1 uses the JWT-SVID input of [INPUTS]). Disabling B3 stops new issuance through B3 only; an association naming B1 and B2 still authorizes them, subject to the remaining checks.¶

B.1. Differences from Base Specifications

This profile fills the gaps of Section 4.1.1 as follows. The referenced sections define each requirement.¶

For self-acting access, this profile composes [WAG] as follows (Section 4.2):¶

B.2. Upstream Dependencies

B.3. Excluded Compositions

This document does not define the following compositions:¶