OAuth 2.0 Client Instance Assertion

4.1. Permitted Grant Types

The client_instance_assertion parameter MAY be presented on the following token endpoint grant types:¶

• authorization_code ([RFC6749])¶

• client_credentials ([RFC6749])¶

• refresh_token ([RFC6749])¶

• urn:ietf:params:oauth:grant-type:jwt-bearer ([RFC7523])¶

The client_instance_assertion parameter MUST NOT be presented on the token-exchange grant ([RFC8693]); on token-exchange grants the assertion is presented as actor_token per Section 4.2. An AS MUST reject a token-exchange request that includes client_instance_assertion.¶

This document does not define behavior for the implicit grant or for the device authorization grant; specifying those is left to future work.¶

4.2. Token-Exchange Presentation

When the grant is token-exchange ([RFC8693]), the Client Instance Assertion is presented as the actor_token parameter with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt. This is the conventional [RFC8693] path; the AS validates the assertion under the same rules as for the client_instance_assertion parameter (Section 8.2).¶

The two parameter names are wire-syntax siblings, not distinct artifacts: the assertion format (Section 7), validation procedure, sender-constraint binding, and access-token representation are identical. The grant determines which parameter name carries the assertion.¶

In the delegation case under token-exchange, the assertion represents the actor distinct from the subject named in subject_token, which is the conventional [RFC8693] use of actor_token. The self-acting case (Section 8.6.3) does not arise on token-exchange, where [RFC8693] requires a distinct subject.¶

5.1. Architecture

Three roles cooperate to authenticate a client instance:¶

A high-level flow:¶

+-----------+ instance assert.+------------+
|  Client   |<----------------|  Instance  |
|  Instance |                 |   Issuer   |
+-----------+                 +------------+
      |
      | token request:
      |  - client authentication (e.g., private_key_jwt)
      |  - client_instance_assertion (instance JWT)
      |    [on token-exchange grants: actor_token /
      |     actor_token_type =
      |     urn:...:client-instance-jwt]
      v
+--------------------+
| Authorization      |  -> resolves client metadata
| Server             |  -> validates the assertion
|                    |  -> issues access token with act or sub
+--------------------+

The client identifier (the CIMD URL or RFC 7591 client_id) is the OAuth client identifier; the instance issuer identifier is the JWT iss of the instance assertion. They are distinct trust anchors: the AS authenticates the client using its registered client authentication method (typically private_key_jwt with keys from the client's registered jwks_uri) and authenticates the instance through the instance assertion.¶

When the client registers token_endpoint_auth_method client_instance_assertion (Section 8.3), these two trust anchors collapse onto a single artifact: the instance assertion both authenticates the client (via the client metadata endorsement of its issuer) and identifies the instance. In that mode the request carries no separate client_assertion. See Section 8.3 for the token request and validation procedure.¶

5.2. Client Registration Models

This profile applies to OAuth clients regardless of how their metadata is registered with the AS. For most existing OAuth deployments, this means RFC 7591-style static registration administered by the AS operator (whether via the dynamic registration endpoint or pre-registered out of band); CIMD is the more recent option that adds public discovery and cross-organization auditability where those are required. The descriptor format and processing rules are identical in both cases.¶

Static registration ([RFC7591]):

The client_id is opaque or AS-assigned. Metadata is registered via the dynamic registration endpoint or out of band, and stays internal to the AS. Updates take effect when the registration store is updated. This model integrates with existing RFC 7591-based registration toolchains and is the typical mode for closed or managed deployments where the trust relationship does not need to be publicly discoverable.¶

Client ID Metadata Document ([CIMD]):

The client_id is an HTTPS URL that dereferences to a metadata document. The AS fetches the document on demand and caches it; updates take effect after the cache window expires (or upon explicit re-fetch). This model suits cross-organization deployments where the trust relationship between the OAuth client and its instance issuers must be auditable in a publicly resolvable document, and is operationally easier for cross-organization SPIFFE federation (Section 5.3.4) because the foreign organization can publicly publish its bundle endpoint and instance descriptors. Under static registration, equivalent federation requires manual coordination of registration between organizations.¶

The descriptor format (Section 6.1.1), the instance-assertion auth mode (Section 8.3), the SPIFFE compatibility features (Section 8.8), and the AS processing rules (Section 8.2) all apply uniformly to both models. The only deployment-time differences are how metadata updates propagate (cache TTL versus admin update) and whether the trust relationship is publicly discoverable.¶

5.3. Trust Delegation Model

This profile defines a three-party trust delegation between the client, the instance issuer, and the AS. The client delegates attestation of its runtime instances to one or more instance issuers; the AS relies on that delegation as expressed in the client's registered metadata.¶

6.1. Client Metadata Extensions

This document defines client metadata parameters describing the trust relationship between a client and the instance issuers that authenticate its runtime instances. These parameters are registered in the OAuth Dynamic Client Registration Metadata registry (Section 13.4) and apply to clients regardless of how their metadata reaches the AS:¶

• For clients identified by a Client ID Metadata Document [CIMD], these parameters appear in the CIMD document and the AS resolves them by dereferencing the CIMD URL.¶

• For clients registered via OAuth Dynamic Client Registration [RFC7591] (or admin-registered with RFC 7591-shaped metadata), these parameters appear in the registered client metadata stored by the AS.¶

The descriptor format and processing rules are identical in both cases. Section 5.2 discusses the trade-offs between the two registration models.¶

{
  "client_id": "https://app.example.com/agent",
  "jwks_uri": "https://app.example.com/agent/jwks.json",
  "token_endpoint_auth_method": "private_key_jwt",
  "instance_issuers": [
    {
      "issuer": "https://workload.app.example.com",
      "jwks_uri": "https://workload.app.example.com/jwks.json",
      "subject_syntax": "spiffe",
      "trust_domain": "app.example.com",
      "spiffe_id": "spiffe://app.example.com/agent/*",
      "signing_alg_values_supported": ["ES256"]
    }
  ]
}

6.2. Authorization Server Metadata

This document defines the following AS metadata parameters for [RFC8414] (see Section 13.6):¶

client_instance_assertion_supported:

A boolean indicating whether the AS supports the client_instance_assertion request parameter (Section 4) on the grants listed in Section 4.1. An AS implementing this profile MUST publish this parameter set to true. Clients use it to decide whether to assemble token requests carrying a Client Instance Assertion on non-token-exchange grants. This signal is intentionally coarse: it does not describe grant-specific enablement, raw JWT-SVID support, accepted sender-constraint methods, refresh-token behavior, or client-specific registration policy. Clients may still need registration-time or deployment agreement with the AS for those details.¶

actor_token_types_supported:

A JSON array of actor_token_type values supported by the AS on the token-exchange grant ([RFC8693]). An AS implementing this profile that supports the token-exchange presentation (Section 4.2) MUST publish this parameter and include urn:ietf:params:oauth:token-type:client-instance-jwt in it. Other values MAY appear and are processed under their own specifications; their trust resolution is not via instance_issuers.¶

In addition, an AS that supports Section 8.3 MUST advertise client_instance_assertion in token_endpoint_auth_methods_supported ([RFC8414]).¶

Example AS metadata document (abridged):¶

{
  "issuer": "https://as.example.com",
  "token_endpoint": "https://as.example.com/token",
  "client_instance_assertion_supported": true,
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_instance_assertion",
    "attest_jwt_client_auth"
  ],
  "actor_token_types_supported": [
    "urn:ietf:params:oauth:token-type:client-instance-jwt"
  ],
  "dpop_signing_alg_values_supported": ["ES256", "RS256"]
}

7.1. Issuer Obligations

The instance issuer is the trust authority for the assertion and MUST, before minting an instance assertion under this profile:¶

• Authenticate the runtime instance (e.g., via attestation, platform-level identity, or possession of an instance key); and¶

• Verify, under issuer-side policy, that the runtime is permitted to claim the client_id named in the token. This typically means the runtime is operationally part of the client's deployment. An instance issuer MUST refuse to mint an instance assertion whose client_id claim names a client for which the runtime has not been authorized, by issuer-side policy, as a member.¶

An instance issuer MUST NOT reassign an active or audit-relevant sub value to a different runtime. Issuers SHOULD use stable, non-reassigned subjects, or include sufficient generation or session uniqueness in sub to distinguish runtime incarnations. If subject reassignment is unavoidable, the client, issuer, and AS audit logs need enough lifecycle metadata to distinguish the old and new runtimes.¶

How the issuer internally authenticates the runtime is out of scope. Common deployment patterns (adapter, raw JWT-SVID compatibility, X.509-SVID binding) are described in Section 10.¶

7.2. JWT Claims

The following claims are defined for client instance assertions.¶

iss (REQUIRED):

The instance issuer identifier. MUST exactly match an issuer member of an instance_issuers descriptor in the client's registered metadata.¶

sub (REQUIRED):

The identifier of the client instance, in the syntax declared by the descriptor's subject_syntax (default: arbitrary StringOrURI). Sub-uniqueness considerations for self-acting tokens are addressed in Section 8.6.3.¶

aud (REQUIRED):

The intended audience, identifying the AS. The AS validates aud per [RFC7523] Section 3, accepting its own issuer identifier or token endpoint URL; if multiple values are present, at least one MUST match.¶

Each AS SHOULD specify a single canonical aud format (typically its issuer identifier) and document it; instance issuers SHOULD use that canonical form. Where instance assertions are scoped per AS, instance issuers SHOULD mint an AS-specific instance assertion rather than a multi-aud JWT, to limit the replay surface.¶

client_id (REQUIRED unless the SPIFFE compatibility conditions of Section 8.8.1 are met):

The client_id of the client to which this instance belongs. This claim uses the JWT client_id claim defined in [RFC8693] Section 4.3.¶

The claim binds the actor token to a specific client and is not part of the actor's identity (per [ACTOR-PROFILE], client_id identifies an OAuth client, not an actor). When present, the AS MUST reject the token if this value does not exactly equal the client_id of the authenticated client.¶

When omitted under Section 8.8.1, the binding is established structurally by the matched descriptor's SPIFFE scope (spiffe_id when present, otherwise trust_domain) rather than by a JWT claim, and a SPIFFE JWT-SVID may be presented as the Client Instance Assertion directly without re-minting.¶

exp (REQUIRED):

Expiration time. Issuers SHOULD set short lifetimes (e.g., five minutes or less); see Section 12.5.¶

iat (REQUIRED):

Issued-at time.¶

jti (REQUIRED):

A unique identifier used for replay prevention; see Section 12.5.¶

sub_profile (RECOMMENDED):

One or more OAuth Entity Profile names [ENTITY-PROFILES] classifying the actor. [ENTITY-PROFILES] defines this claim as OPTIONAL; this profile elevates it to RECOMMENDED so resource servers can apply actor-class-aware policy without bespoke configuration.¶

Its syntax (a space-delimited string of profile names) is the one defined by [ACTOR-PROFILE]. This document registers the value client_instance (Section 13.8). Issuers MAY include additional values registered with the "Actor Profile" usage location in the OAuth Entity Profiles registry, or privately defined collision-resistant values, per [ACTOR-PROFILE].¶

cnf (REQUIRED unless the token is a raw JWT-SVID accepted under Section 8.8.1):

A confirmation claim [RFC7800] carrying a key bound to this instance. The cnf value MUST contain exactly one of jkt (a JWK SHA-256 thumbprint per [RFC9449] Section 3.1) or x5t#S256 (an X.509 certificate SHA-256 thumbprint per [RFC8705] Section 3.1) as the binding member; other confirmation methods registered under [RFC7800] MAY appear alongside but are not the binding and do not change this profile's sender-constraint verification requirement.¶

The instance issuer MUST mint cnf from a key the named runtime instance demonstrably possesses (e.g., an instance-attested key, a per-instance workload key, or a Demonstration of Proof-of-Possession (DPoP, [RFC9449]) public key presented to the issuer at attestation time). Binding rules and AS verification are defined in Section 8.5.¶

Raw JWT-SVID compatibility is the only exception to this claim requirement, because the AS validates the SVID without re-minting; see Section 8.8.1 and Section 8.5.¶

nbf (OPTIONAL):

Not-before time. If present, the AS MUST reject the token before this time.¶

When validating exp, nbf, and iat, ASes SHOULD permit a small clock skew tolerance, typically no more than 60 seconds, applied symmetrically. This bound is consistent with the short-lifetime recommendation in Section 12.5 and prevents brittle inter-clock failures across deployments.¶

A Client Instance Assertion MUST NOT contain an act claim. The assertion is a direct identity assertion of a single party (the instance); per [ACTOR-PROFILE], an assertion that carries an act claim represents a delegation chain rather than a direct identity, and the AS MUST reject such a token with invalid_grant (Section 8.6.4, Section 8.9).¶

Additional claims MAY be present and MUST be ignored if not understood, except where this document or [ACTOR-PROFILE] specifies processing rules. Future profiles requiring AS understanding of a new claim SHOULD use the JWS crit header parameter ([RFC7515] Section 4.1.11) to mark it must-understand; ASes MUST reject assertions whose crit header is malformed or includes claims they do not implement, per [RFC7515] Section 4.1.11.¶

7.3. Signing and JOSE Header

A Client Instance Assertion MUST be signed using an asymmetric JWS [RFC7515] algorithm; none and symmetric (HMAC-based) algorithms (HS256, HS384, HS512) MUST NOT be used and ASes MUST reject assertions signed with them. The descriptor's signing_alg_values_supported (Section 6.1.1), when present, MUST contain only asymmetric algorithm identifiers. Implementations SHOULD follow the JWT BCP guidance in [RFC8725].¶

ASes and instance issuers implementing this profile MUST support ES256 ([RFC7518]). This is the mandatory-to-implement baseline for interoperability. ASes and instance issuers SHOULD additionally support RS256 and MAY support other asymmetric JWS algorithms ([RFC7518], [RFC8037]) as deployment requirements dictate.¶

Issuers SHOULD include a kid in the JWS protected header; ASes SHOULD use kid for key selection.¶

Issuers minting a Client Instance Assertion under this profile MUST set the JWS typ (type) protected header parameter to client-instance+jwt per [RFC8725] Section 3.11, and ASes MUST reject such assertions whose typ is anything else. Explicit typing prevents JWT confusion attacks where a token of a different type (for example, a WIMSE workload identity credential [WIMSE-CREDS], a JWT-SVID outside the SPIFFE compatibility mode, or an OAuth JWT access token [RFC9068]) is mistaken for a Client Instance Assertion.¶

The only exception is the SPIFFE compatibility mode in Section 8.8.1, where a raw JWT-SVID is intentionally presented without re-minting. In that mode, the AS MUST validate the token as a JWT-SVID according to [SPIFFE-CLIENT-AUTH] and Section 8.8.2, and MUST NOT require the JWS typ header to be client-instance+jwt.¶

Verification keys are obtained from the descriptor's jwks_uri, jwks, or spiffe_bundle_endpoint for the issuer that matches the iss claim; the AS MUST verify alg against signing_alg_values_supported when present.¶

7.4. Example Assertion

A decoded re-minted Client Instance Assertion (JWS protected header and JWT payload):¶

{ "alg": "ES256", "kid": "4vC8agycHu6rnkE...", "typ": "client-instance+jwt" }

{
  "iss":         "https://workload.app.example.com",
  "sub":         "spiffe://app.example.com/agent/session-abc",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770000000,
  "exp":         1770000300,
  "jti":         "1a2b3c4d-5e6f",
  "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
}

8.1. Token Request

A client presents a Client Instance Assertion at the token endpoint using the parameter appropriate to the grant:¶

• On the grants listed in Section 4.1, the assertion is presented as the client_instance_assertion request parameter (Section 4).¶

• On the token-exchange grant ([RFC8693]), the assertion is presented as the actor_token parameter with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt (Section 4.2).¶

The following example shows a client credentials grant carrying a Client Instance Assertion. The client authenticates with private_key_jwt; line breaks are for readability:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to the instance's key>

grant_type=client_credentials
&scope=repo.write
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6...
&client_instance_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6...

8.2. Authorization Server Processing

When evaluating a token request for this profile, an AS implementing this document MUST perform the following checks and steps in addition to grant-type-specific processing.¶

In this section the term "presented assertion" means the client_instance_assertion parameter (Section 4) on the grants in Section 4.1, or the actor_token parameter (with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt) on the token-exchange grant (Section 4.2). Processing is identical regardless of which parameter carried the assertion.¶

Before the steps below, the AS MUST reject the request with invalid_request if any of the following pre-conditions hold:¶

• On a token-exchange request, exactly one of actor_token and actor_token_type is present;¶

• On a token-exchange request, actor_token_type is urn:ietf:params:oauth:token-type:client-instance-jwt but actor_token is absent or is present but is not a syntactically valid JWT;¶

• On a token-exchange request, client_instance_assertion is present (it is not permitted on this grant per Section 4.1);¶

• On any grant other than token-exchange, actor_token is present with actor_token_type equal to urn:ietf:params:oauth:token-type:client-instance-jwt (the Client Instance Assertion MUST be carried as client_instance_assertion on grants in Section 4.1; on grants outside Section 4.1, this profile does not define a presentation path);¶

• On any grant not listed in Section 4.1, client_instance_assertion is present;¶

• On any grant listed in Section 4.1, client_instance_assertion is present but is not a syntactically valid JWT.¶

1. Authenticate the client. Authenticate the client using its registered token_endpoint_auth_method per [RFC6749] and, if applicable, [RFC7523]. The client_id identifies the OAuth client. When the registered method is client_instance_assertion, follow Section 8.3 instead of presenting a separate client-controlled credential.¶

2. Match the token type. On a token-exchange request, if actor_token_type is not urn:ietf:params:oauth:token-type:client-instance-jwt, processing under this document does not apply; the AS processes the request per [RFC8693], including handling other registered actor_token_type values under their own specifications. If the AS does not support urn:ietf:params:oauth:token-type:client-instance-jwt for the requested grant, it MUST reject the request with unsupported_token_type (Section 8.9). On the grants in Section 4.1, presence of client_instance_assertion selects processing under this document.¶

3. Resolve client metadata. Retrieve the client metadata for the authenticated client_id. For clients identified by [CIMD], dereference the CIMD document subject to its caching rules. For clients registered via [RFC7591] or pre-registered with the AS, read the stored metadata. The remaining steps operate on the resolved metadata regardless of source.¶

4. Locate the instance issuer descriptor. Parse the presented assertion as a JWT and read its iss claim. Find the descriptor in instance_issuers whose issuer member exactly equals iss. If no descriptor is found, or instance_issuers is absent, reject the request with invalid_grant (Section 8.9).¶

5. Verify the signature. Using the descriptor's jwks_uri, jwks, or spiffe_bundle_endpoint, verify the JWS signature per [RFC7515], Section 7.3, and, when applicable, Section 8.8.2.¶

6. Validate JWT claims. Validate iss, sub, aud, exp, iat, nbf, and jti per Section 7.2 and [RFC7523] Section 3, subject to the raw JWT-SVID exceptions in Section 8.8.1. Enforce subject_syntax, trust_domain, spiffe_id, and signing_alg_values_supported when present in the descriptor. If subject_syntax is "spiffe" and spiffe_id is absent, require trust_domain and treat the descriptor as delegating the whole trust domain. Validate the JWS typ per Section 7.3 and reject unrecognized crit header parameters per Section 7.2.¶

7. Verify client_id binding. If the instance assertion contains a client_id claim, it MUST exactly equal the authenticated client_id; reject with invalid_grant otherwise. "Exactly equal" means octet-for-octet equality on the UTF-8 encoding of the two values: ASes MUST NOT apply case folding, Unicode normalization, percent-decoding, URI canonicalization, or other string-equivalence transformations before comparison. The same octet-equality rule applies wherever this document requires iss, sub, client_id, aud, or spiffe_id values to "match" or "exactly equal" another value, except where a specifically cited matching rule (for example, the SPIFFE "/*" wildcard rule in Section 6.1.1) defines a different comparison. If the instance assertion has no client_id claim, the AS MUST verify that the matched descriptor satisfies the SPIFFE compatibility conditions (Section 8.8.1); if not, reject with invalid_grant. When the descriptor satisfies those conditions, the AS MUST verify that the presented assertion's sub falls under the descriptor's SPIFFE scope: spiffe_id when present, otherwise the descriptor's trust_domain; if not, reject with invalid_grant.¶

8. Verify proof-of-possession of the cnf key. Verify possession of the assertion's cnf key per Section 8.5; reject with invalid_request if verification fails. For raw JWT-SVIDs accepted under Section 8.8.1, establish the binding key per Section 8.8.3 instead.¶

9. Apply replay checking. After client_id binding and PoP verification succeed, apply the replay check per Section 12.5; reject with invalid_grant if a previously seen (iss, jti) tuple is found. For raw JWT-SVIDs, this replay check applies only when jti is present. The replay check follows client_id binding so that an attacker cannot burn a legitimate client's jti by presenting the assertion under a mismatched client_id. The replay check follows PoP verification so that the cnf-bound reusable-mode optimization in Section 12.5 can be applied.¶

10. Enforce delegation policy. Apply the AS's local maximum delegation depth per [ACTOR-PROFILE].¶

11. Check authorization-time consistency. For grants that originate from a prior authorization step (notably authorization_code), apply the rules of Section 8.4.¶

12. Bind the instance to the issued access token. If issuance succeeds, represent the instance in the access token per Section 8.6 and apply the sender-constraint binding per Section 8.5, using the key whose possession was verified in step 8. Reflect any prior actor chain present in input tokens by nesting per [ACTOR-PROFILE]; chain merging rules are given in Section 8.6.4.¶

If validation succeeds, the AS issues an access token (and optionally a refresh token) per the requested grant.¶

8.3. Client Authentication via Instance Assertion

A client MAY register the token_endpoint_auth_method value client_instance_assertion in its registered metadata (whether published as a CIMD document or stored at the AS) to indicate that the AS authenticates the client implicitly from a presented Client Instance Assertion, without requiring a separate client_assertion or other credential controlled by the client itself.¶

This mode is the natural choice for workload-only deployments (for example, agentic services, autoscaled microservices, or ephemeral functions) where there is no human user authorizing operations and the team operating the runtime is also the natural owner of the workload identity provider. For these deployments, requiring a separate client-level credential typically means provisioning a private key into every pod alongside the instance-attested assertion, which (per Section 12.7) does not meaningfully improve defense against runtime compromise. The mode is also appropriate where the client identifier is a logical CIMD URL with client-key custody centralized away from the runtime, or where the workload identity provider trusted to attest instances is the only authority the client wishes to publish.¶

The trust chain to the client is preserved: the client's listing of the instance issuer in its registered metadata is itself the endorsement, and a token signed by such an issuer naming this client_id is attributable to the client. When token_endpoint_auth_method is client_instance_assertion, every accepted instance issuer for the client is also a client authentication trust root. Clients MUST NOT enable this method unless each listed issuer is authorized for that role.¶

client_instance_assertion is a confidential-client token-endpoint authentication method: the AS authenticates the request through the client's registered endorsement of the presenting instance issuer. Clients without any registered trust relationship for the AS to evaluate cannot use it. This exclusion is scoped to this auth method only; deployments using [ATTEST-CLIENT-AUTH] for client authentication follow that specification's client-authentication model, independent of this section.¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=repo.write
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_instance_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6...

8.4. Authorization-Time Consistency

When a token request is made under the authorization_code grant ([RFC6749] Section 4.1), the user has authorized the client identified by client_id, not any specific client instance. The AS MUST ensure that the instance introduced at the token endpoint is consistent with that authorization:¶

• The client_id authenticated at the token endpoint MUST match the client_id that received the authorization_code ([RFC6749] Section 4.1.3). Combined with the client_id-binding requirement in Section 8.2, this prevents an instance assertion from another client from being attached to a code.¶

• The AS MUST NOT permit the instance identity to bypass standard authorization-code controls (single-use redemption, redirect URI matching, and any code challenge bound to the original authorization request).¶

• If the AS has any authorization-time policy that depends on the instance (for example, a per-instance allow-list), the AS MUST evaluate that policy against the instance assertion presented at /token and reject inconsistent requests with invalid_grant.¶

When the issued access token is to be DPoP-bound, clients SHOULD include the dpop_jkt parameter ([RFC9449] Section 10) on the authorization request, naming the same public key whose thumbprint will appear in the instance assertion's cnf.jkt at the token endpoint. When dpop_jkt is present, the AS binds the authorization code to that key per [RFC9449], and at the token endpoint MUST verify that the DPoP proof, the authorization code's dpop_jkt, and the instance assertion's cnf.jkt all reference the same key. This provides cryptographic continuity from /authorize to /token bound to a specific instance: only the instance that holds the named DPoP private key can redeem the resulting code, even if the code is intercepted or transferred to another runtime under the same client.¶

If dpop_jkt is absent, DPoP still sender-constrains the issued access token at the token endpoint, but this profile does not provide cryptographic continuity between the authorization endpoint and the token endpoint for that authorization code.¶

For Mutual-TLS-bound access tokens ([RFC8705]), authorization-code continuity is deployment-specific. If the AS binds the authorization request or authorization code to a client certificate seen at the authorization endpoint, then at the token endpoint the AS MUST verify that the certificate used to redeem the code and the instance assertion's cnf.x5t#S256 match the certificate bound at authorization time. Otherwise, mTLS sender-constraint is established at the token endpoint and does not by itself provide authorization- to-token endpoint continuity.¶

User consent under this profile applies to the client as a whole; consent thereby covers all instances attested by listed instance issuers. The key-bound continuity above adds cryptographic guarantees about which instance redeems a code, but does not by itself constitute per-instance consent.¶

An AS MAY require per-instance or per-key authorization policy when the authorization request includes a sender-constraining key such as dpop_jkt. Such policy is deployment-specific: dpop_jkt identifies a key, not an instance, unless the AS has an authorization-time mapping from that key to an instance identity. In those deployments, the AS can require user or administrator approval for the specific instance or key and then verify at the token endpoint that the DPoP proof, authorization code binding, and instance assertion cnf.jkt all reference the approved key.¶

ASes that record consent SHOULD record the descriptor scope under which consent was granted (in particular, the descriptor's issuer and trust_domain), and MAY refuse access tokens for the same client issued under a different descriptor scope than the one consented. This matters for clients deployed across multiple trust domains (for example, "production" vs. "staging" SPIFFE trust domains, or distinct PaaS environments) where the user's consent to one is not necessarily consent to another.¶

This document does not define a general authorization endpoint mechanism for presenting instance identity. Deployments requiring standardized per-instance consent without an authorization-time key mapping need a separate extension.¶

8.5. Sender-Constrained Access Tokens

When the AS issues an access token under this profile, whether the instance is represented in act (delegation case; Section 8.6.2) or in sub (self-acting case; Section 8.6.3), the AS MUST issue a sender-constrained access token bound to a key the instance possesses. Established mechanisms include DPoP [RFC9449] and Mutual-TLS-bound access tokens [RFC8705].¶

The AS MUST NOT issue a bearer access token under this profile. Sender-constraint is a structural prerequisite, not a preference: per-instance non-repudiation depends on binding the access token to a key the validated instance possesses. Deployments adopting this profile therefore require AS and RS support for DPoP ([RFC9449]), Mutual-TLS-bound access tokens ([RFC8705]), or both, and SHOULD verify implementation support before committing. Adoption guidance for DPoP or mTLS rollout is outside the scope of this document; deployments unable to deploy either mechanism within their adoption timeline should defer adopting this profile.¶

If the instance assertion includes a cnf claim (Section 7.2), the AS MUST:¶

• bind the issued access token to the same key by setting the access token's top-level cnf to the instance assertion's cnf value;¶

• verify possession of the cnf key at the token endpoint, matching the binding member used in cnf per [RFC7800]. For cnf.jkt, the JWK thumbprint of the DPoP proof's public key [RFC9449] MUST equal cnf.jkt. For cnf.x5t#S256, the certificate authenticated at the TLS layer [RFC8705] MUST match cnf.x5t#S256. Other confirmation methods present in cnf are not binding members for this profile and MAY be ignored unless local policy or their defining specifications require additional processing;¶

• reject the request with invalid_request if verification fails.¶

This protects the instance assertion from bearer-style replay within its validity window (Section 12.5); without it, the instance assertion would be a bearer credential whose replay is bounded only by exp and the jti cache.¶

The binding key MUST be specific to the validated client instance. A credential shared by the client as a whole, such as the client-level mTLS certificate authenticated under [RFC8705], the client's private_key_jwt key, or any other client-controlled key not provisioned per-instance, is not sufficient.¶

A re-minted Client Instance Assertion MUST contain cnf so that the binding key is supplied by the same authority that named the instance. The only profile-defined case where cnf can be absent is raw-JWT-SVID compatibility, where the AS establishes an instance-specific binding through a channel independent of the SVID; rules are in Section 8.8.3.¶

Deployments combining client-level Mutual-TLS-bound client authentication ([RFC8705]) with this profile MUST establish instance binding through a separate, instance-specific key. The typical configuration uses the client's mTLS certificate at the TLS layer for client authentication and a cnf.jkt in the instance assertion paired with DPoP [RFC9449] at the token endpoint for instance binding. Per-instance mTLS certificates issued by the instance issuer (or otherwise bound to instance attestation) are an alternative; in that case the same TLS certificate satisfies both client authentication and instance binding only if the AS treats it as belonging to the instance for binding purposes.¶

8.6. Access Token Representation

This section defines how a validated Client Instance Assertion surfaces in the issued access token. It does not restate the generic access-token claim set: JWT access tokens issued under this profile follow [RFC9068]; opaque (reference) access tokens carry the same set of claims through introspection per Section 9.1. The profile-specific surfacing rules are:¶

• The access token MUST be sender-constrained per Section 8.5 (i.e., cnf is bound to the instance's key, not bearer).¶

• The validated instance identity surfaces in act (delegation case) or top-level sub (self-acting case), per the classification and per-case rules below; sub_profile ([ACTOR-PROFILE]) signals the kind of subject in either case.¶

• Any upstream actor chain MUST be preserved by nesting per [ACTOR-PROFILE]; merge rules are in Section 8.6.4.¶

A client instance may be acting on behalf of another principal (delegation case; e.g., a user authorized the request through an authorization_code grant) or acting as itself with no other principal involved (self-acting case; e.g., a client_credentials grant). The AS MUST classify each request as delegation or self-acting before populating the issued access token's claims; the classification rules are in Section 8.6.1.¶

8.7. Refresh Tokens

When an access token is refreshed ([RFC6749] Section 6), the AS reuses the classification (Section 8.6.1) of the original grant to shape the refreshed access token; the original classification is inherited and is not re-derived from the refresh request itself.¶

Refresh tokens issued under this profile MUST be sender-constrained to the originating instance's cnf key, by the same mechanism used to sender-constrain the access token (Section 8.5). Only the originating instance can present the refresh token. A refresh request MUST NOT introduce a client instance identity if the refresh token was not originally issued under this profile.¶

A client MAY include a fresh Client Instance Assertion on a refresh request (for example, to rotate the underlying assertion before its exp) via the client_instance_assertion parameter (Section 4). When present, the assertion MUST:¶

• be bound to the same cnf key as the refresh token;¶

• have (iss, sub) matching those recorded at the refresh token's original issuance;¶

• pass the instance issuer descriptor lookup, signature verification, JWT claim validation, and client_id binding checks defined in Section 8.2; and¶

• pass the replay check defined in Section 12.5 against its own (iss, jti) tuple. The bound cnf of the refresh token prevents off-instance replay, but does not prevent an attacker with the same refresh token from replaying a captured fresh assertion across successive refreshes; the replay check closes that window.¶

If the presented assertion is a raw JWT-SVID without cnf, the AS MUST establish the binding key per Section 8.8.3 and verify that the established binding key matches the refresh token's binding. The AS MUST reject with invalid_grant any refresh request whose presented assertion is not bound to the same cnf key, or whose (iss, sub) differ from those recorded at issuance.¶

Because the refresh token is bound to the originating instance, it is implicitly invalidated when that instance terminates. This keeps act.sub (delegation) or sub (self-acting) stable across the refresh chain, matching the expectation of audit pipelines that a token's actor identity does not change after issuance.¶

For SPIFFE deployments, the cnf binding key SHOULD outlive the JWT-SVID rotation cycle (typically a few minutes in default SPIFFE implementations) when refresh tokens are issued. Deployments that bind cnf to a per-instance DPoP or mTLS key held by the workload satisfy this naturally; deployments that attempt to bind cnf to the SVID's signing key directly will lose refresh-token continuity at every rotation and SHOULD NOT use that pattern.¶

This profile does not extend refresh-token semantics to cross-instance succession; doing so would break the per-instance audit-stability invariant the profile is designed to provide. Deployments requiring cross-instance session continuity address it outside refresh-token semantics (the mechanisms are deployment choices and out of scope for this document).¶

8.8. SPIFFE Compatibility

A SPIFFE workload typically obtains a JWT-SVID from the SPIFFE Workload API. JWT-SVIDs carry iss (the trust domain), sub (the SPIFFE ID), aud, exp, and a signature, and may carry additional registered claims such as iat and jti; they do not carry an OAuth client_id claim. To allow such SVIDs to be presented as Client Instance Assertions without re-minting, this profile defines an optional SPIFFE compatibility mode driven entirely by descriptor configuration. An AS is not required to support raw JWT-SVID compatibility in order to support re-minted Client Instance Assertions with subject_syntax = "spiffe".¶

This profile uses JWT-format Client Instance Assertions. X.509-SVIDs are not presented as Client Instance Assertions; SPIFFE deployments using X.509-SVIDs authenticate at the TLS layer (per [RFC8705]) and obtain a JWT-SVID separately for presentation. The X.509-SVID certificate thumbprint MAY serve as cnf.x5t#S256 in either the re-minted assertion or the issued access token's binding.¶

The AS MUST select exactly one validation mode before accepting the assertion and MUST apply that mode's rules exclusively. Selection is determined by whether the assertion contains a client_id claim: presence selects re-minted mode unconditionally, even when the descriptor's SPIFFE conditions would otherwise have permitted raw mode. This means an OAuth-aware adapter that mints a Client Instance Assertion with a SPIFFE-formatted sub together with a client_id claim is always processed as re-minted, and the client_id value is verified per Section 8.2.¶

In raw JWT-SVID mode, the AS MUST:¶

1. match the descriptor by exact comparison of the JWT-SVID iss to the descriptor's issuer;¶

2. require subject_syntax = "spiffe";¶

3. validate the token as a JWT-SVID using SPIFFE JWT-SVID validation rules and the descriptor's spiffe_bundle_endpoint;¶

4. validate the SPIFFE JWT-SVID claims required by SPIFFE and ignore unrecognized claims unless local policy rejects them;¶

5. validate aud and exp;¶

6. validate iat if present;¶

7. validate nbf if present;¶

8. enforce the descriptor's signing_alg_values_supported when present;¶

9. apply the replay-cache rule in Section 12.5 if jti is present;¶

10. validate sub as a SPIFFE ID and enforce the descriptor's spiffe_id, or trust_domain when spiffe_id is absent; and¶

11. establish an instance-specific sender-constraint binding per Section 8.8.3.¶

In raw JWT-SVID mode, the JWT-SVID's iss claim MUST identify the SPIFFE JWT-SVID issuer for the trust domain and MUST exactly match the descriptor's issuer member. Because raw JWT-SVIDs do not require jti, an AS that accepts a raw JWT-SVID without jti MUST rely on sender-constraint and short SVID lifetimes for replay protection.¶

In re-minted assertion mode, the AS MUST:¶

1. match the descriptor by exact comparison of the assertion's iss to the descriptor's issuer;¶

2. verify the JWS signature using the descriptor key source;¶

3. validate typ = client-instance+jwt per Section 7.3;¶

4. require and validate the claims defined in Section 7.2, including client_id, exp, iat, jti, and cnf;¶

5. verify that client_id equals the authenticated client;¶

6. apply the replay-cache rule in Section 12.5;¶

7. if subject_syntax is "spiffe", validate sub as a SPIFFE ID and enforce spiffe_id, or trust_domain when spiffe_id is absent; and¶

8. verify possession of the cnf key per Section 8.5.¶

A deployment that re-mints an SVID into a Client Instance Assertion MUST include the claims required by Section 7.2 and MUST use typ = client-instance+jwt per Section 7.3.¶

8.9. Error Responses

Errors are returned per [RFC6749] Section 5.2 and [RFC8693] Section 2.2.2. This profile uses the existing OAuth error codes:¶

• invalid_request: pre-condition and request-shape failures, including missing or mismatched client_instance_assertion (or, on token-exchange grants, actor_token/actor_token_type), presence of client_instance_assertion on the token-exchange grant, malformed JWT, JWS typ mismatch (Section 7.3), sender-constraint binding failures (Section 8.5), and chain depth exceeding the AS local maximum ([ACTOR-PROFILE]).¶

• invalid_grant: failures of instance-assertion validation, including signature, JWT claim validation, descriptor lookup or shape, client_id binding, SPIFFE compatibility conditions, classification ambiguity, and a presented assertion carrying an act claim.¶

• unsupported_token_type ([RFC8693]): on a token-exchange grant, an unrecognized actor_token_type.¶

• invalid_client: when the presented assertion is the client authentication credential under Section 8.3, validation failures that would otherwise be returned as invalid_grant (assertion-validation failures) or invalid_request (sender-constraint failures, including a cnf-less assertion) are returned as invalid_client. The pre-condition failures of Section 8.2 (malformed JWT, misplaced parameter, mismatched grant/parameter) continue to be returned as invalid_request even in this mode.¶

The AS MAY return additional information via the error_description parameter; deployments MUST NOT include sensitive instance details (e.g., raw SPIFFE IDs of unrelated workloads) in error responses. To help client-developer debugging, AS implementations SHOULD include non-sensitive diagnostic context such as which validation step failed (for example, "issuer not in instance_issuers" or "cnf possession failed").¶

9.1. Introspection Responses

When the AS issues opaque (reference) access tokens under this profile, the set of profile-defined claims in the introspection response ([RFC7662]) MUST be identical to the set that would appear in the payload of a JWT access token for the same grant, including act (when applicable), sub, sub_profile, client_id, cnf, and any actor-chain members defined by [ACTOR-PROFILE]. Resource servers that consume introspection apply the same processing as for JWT access tokens described above; the representational difference is only in where the claims arrive (token payload versus introspection response).¶

The following example shows an introspection response for an opaque access token issued under the authorization_code grant (Appendix "Authorization Code with User Delegation"). The corresponding self-acting case (Appendix "Client Credentials (Self-Acting)") and token-exchange case (Appendix "Token Exchange with Prior Delegation Chain (Agent Spawns Sub-Agent)") follow the same pattern: the top-level claims and any act chain appear in the response exactly as they would in a JWT access token payload.¶

{
  "active":      true,
  "iss":         "https://as.example.com",
  "aud":         "https://api.example.com",
  "sub":         "user:alice@example.com",
  "client_id":   "https://app.example.com/agent",
  "scope":       "repo.write",
  "iat":         1770000005,
  "exp":         1770001805,
  "token_type":  "DPoP",
  "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" },
  "act": {
    "iss":         "https://workload.app.example.com",
    "sub":         "https://workload.app.example.com/inst-01",
    "sub_profile": "client_instance",
    "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
  }
}

12.1. Trust Model

The normative trust model for this profile is in Section 5.3. This subsection summarizes the security implications.¶

A client delegates the authentication of its instances to one or more instance issuers. A compromised or misconfigured instance issuer can mint instance assertions that the AS will accept as legitimate instances of the named client. Clients SHOULD list only instance issuers under their own administrative control (or contractually equivalent), and SHOULD set spiffe_id, trust_domain, and signing_alg_values_supported to bound what each issuer is allowed to assert. Deployments hosting workloads from multiple tenants under a single client_id aggregate those tenants' trust roots into a single instance_issuers list; see Section 12.8 for the resulting blast-radius considerations and the recommendation to issue per-tenant client_id values where tenants are independent trust boundaries.¶

Clients using SPIFFE SHOULD include spiffe_id; omitting it delegates the whole SPIFFE trust domain and is appropriate only when every workload in that trust domain is authorized to act as an instance of the client. After a client detaches a compromised issuer, tokens minted under the prior trust may continue to validate up to the trust-withdrawal latency bound in Section 12.2; operators SHOULD plan incident response around this window.¶

The per-client minting requirement of Section 7.1 is an operational obligation on the instance issuer, not a check the AS performs in-band. The AS verifies that a presented assertion's client_id claim matches the authenticated client, but it cannot detect an issuer that violates its obligation by minting for runtimes outside the authorized set; such assertions are accepted as valid. Clients SHOULD list only issuers whose minting policy they have audited and whose operational practice they trust to honor Section 7.1.¶

Client metadata is itself trust-affecting: an attacker who can modify it can add a new instance issuer under their control. Adding an instance_issuers entry, widening a descriptor's spiffe_id or trust_domain, changing a descriptor's key source, or enabling client_instance_assertion (as a token_endpoint_auth_method) is equivalent to adding or expanding a credential issuer for the client and SHOULD require high-assurance change control by the client operator and AS. Clients publishing CIMD metadata MUST protect the publication channel (per [CIMD]'s requirement of HTTPS) and the storage backing it; deployments using static registration MUST protect the registration store and any administrative API used to update it. ASes resolving CIMD documents inherit [CIMD]'s security considerations covering transport, intermediary caches, and DNS.¶

12.2. Trust-Withdrawal Latency

The trust-withdrawal latency, that is, the worst-case time from a client metadata change to all derived access tokens having expired, is approximately the sum of the metadata refresh interval (for CIMD, the cache TTL; for static registration, the expected lag between an admin update and AS-side propagation), the instance assertion's exp window, the AS's JWKS or SPIFFE-bundle cache TTL for the issuer, and the access token TTL. ASes SHOULD size these components together so that the resulting latency matches their incident-response target.¶

Deployments with longer latencies SHOULD support active revocation (Section 12.4) and introspection-based status checks at the resource server.¶

12.3. Instance Lifecycle

Client instances are short-lived in many deployments (containers, function invocations, agent sessions). This profile relies on three mechanisms to keep actor identity current:¶

Rotation:

Instance issuers SHOULD mint short-lived instance assertions (Section 12.5). New tokens are issued continuously as instances start, restart, or rotate keys.¶

Revocation within the validity window:

Within an instance assertion's exp window, the AS prevents reuse via the jti replay rule (Section 12.5). A specific issued access token, or all tokens associated with an instance, can be revoked only via the AS's own revocation mechanisms (Section 12.4); this profile does not define a standardized revocation endpoint or instance revocation list format.¶

Trust withdrawal:

To stop accepting instance assertions from an issuer (e.g., after a workload identity compromise), the client removes the issuer from instance_issuers, replaces or removes trust_domain, or rotates jwks at the issuer level. The AS's response is governed by Section 5.3.3: subsequent uses of access tokens whose act references the withdrawn scope are treated as no longer endorsed.¶

Refresh windows are a particular concern: an access token refreshed without a new instance assertion may carry stale instance identity long after the original instance has terminated. ASes SHOULD prefer requiring a fresh instance assertion on refresh (Section 8.7), or set short refresh intervals when instance identity is present.¶

Compromise-response latency under this profile is bounded by the shortest of: the access token TTL, the introspection cache TTL at the resource server, and the propagation time of whichever revocation signal a deployment uses (Section 12.4.2). None of these are defined by this document; deployments with strict detection-to-revocation latency requirements SHOULD tune them together and document the resulting end-to-end bound as part of operational security posture.¶

12.4. Token Revocation

This profile supports two complementary revocation models for access tokens issued under it. Both build on [RFC7009]; deployments MAY support either, both, or neither.¶

After the AS has adopted updated client metadata (Section 5.3.3), the AS SHOULD treat further use of access tokens whose validated instance identity is no longer endorsed by the client as invalid:¶

• for delegation tokens, when the act claim names a removed instance issuer or falls outside the descriptor's updated scope;¶

• for self-acting tokens, when the instance issuer recorded by the AS at issuance time has been removed, or when the access token's sub falls outside the descriptor's updated scope.¶

Where the deployment supports it, this is naturally enforced by introspection (Section 12.4.3) and short access-token lifetimes; AS implementations MAY additionally revoke such tokens per [RFC7009], including via the per-instance mechanism in Section 12.4.2. ASes MAY apply the same policy to changes in a descriptor's jwks_uri, jwks, or spiffe_bundle_endpoint keys that [CIMD] permits for changes in client-level keys.¶

12.5. Replay

Actor tokens MUST include jti, exp, and iat (Section 7.2), except for raw JWT-SVIDs accepted under Section 8.8.1.¶

After identifying the issuer and validating the signature, the AS MUST reject a token whose (iss, jti) pair has already been seen within the token's validity window, and MUST retain replay-cache entries at least until the token's exp plus any allowed clock skew. For raw JWT-SVIDs, this check applies only when jti is present; otherwise replay is bounded by sender-constraint, short SVID lifetimes, and audience restriction.¶

The replay-cache key is (iss, jti); ASes MUST NOT widen the key to include client_id. jti uniqueness is the responsibility of the instance issuer within its own iss namespace, so two different OAuth clients that list the same instance issuer share the same replay state for that issuer. The cache MUST be scoped at least to a single AS instance; distributed AS deployments share the cache or coordinate as specified below.¶

An AS MAY skip the replay check for cnf-bound assertions that have been PoP-verified at presentation, treating them as reusable within their exp window, provided the deployment documents this behavior and applies rate limits, monitoring, and audit logging. This shifts the blast radius of cnf-key compromise from one access token per assertion to the rate-limit ceiling within exp; the rate limit is therefore the bound on that threat. The MUST applies unconditionally to assertions without a verified cnf.¶

Issuers SHOULD use short lifetimes (five minutes or less). On refresh (Section 8.7), AS implementations SHOULD prefer requiring a fresh instance assertion; when a fresh assertion is presented, the AS MUST apply the replay check to its (iss, jti) per Section 8.7. Distributed AS deployments MUST share the replay cache or coordinate to prevent cross-replica replay, except on cnf-bound paths in reusable mode where cnf+PoP verification is correctness-preserving across replicas.¶

A compromised instance-issuer signing key creates a denial-of-service surface: an attacker can mint validly-signed assertions with arbitrary jti values. ASes SHOULD apply per-issuer rate limits and bounded cache caps; a sustained high rate of distinct jti values from a single issuer is a signal of compromise.¶

12.6. Audience and Confused Deputy

The aud claim binds the instance assertion to a specific AS, preventing one AS from replaying it against another ([RFC7523] Section 3). The client_id claim, which this document treats as a binding (not as actor identity), prevents an instance assertion issued for one client from being presented under a different client's authentication.¶

12.7. Trust-Root Collapse

The client_instance_assertion authentication method (Section 8.3) collapses two trust roots (client credential and instance issuer) into one. Compromise of any listed instance issuer is sufficient to mint tokens that authenticate as the client. Modes such as private_key_jwt require an attacker to possess both the instance issuer's signing key and the client's private key; that two-key property holds only when the two keys live in different security domains. Where genuine custody separation between the client credential and the instance issuer is not available, the security property of private_key_jwt paired with a Client Instance Assertion reduces to that of client_instance_assertion alone.¶

When client_instance_assertion is used, clients SHOULD constrain each instance issuer's authority through spiffe_id, trust_domain, and signing_alg_values_supported, and SHOULD list only the minimum set of instance_issuers necessary. Trust withdrawal under this auth method has immediate consequences: removing an instance issuer from instance_issuers (or narrowing its descriptor scope) invalidates client authentications that depended on that issuer's endorsement, and the AS MUST stop accepting client_instance_assertion authentications via the removed or narrowed issuer once it has applied the metadata update (Section 5.3.3).¶

12.8. Multi-Tenancy Under a Single Client

The class-and-instance model in Section 5 is a two-level model: the OAuth client (class) and its runtime instances. It does not model tenancy as a third dimension. Deployments that aggregate workloads from distinct trust domains under a single OAuth client_id concentrate those tenants' trust roots into one instance_issuers list. Compromise of any listed issuer extends to every tenant whose workloads it authenticates.¶

This profile RECOMMENDS issuing a separate client_id per tenant when tenants need to be isolated as trust boundaries. Per-tenant client_ids give each tenant its own instance_issuers list, its own descriptor scope, and its own revocation surface, and align this profile's trust model with the deployment's tenancy boundaries.¶

Where per-tenant client_ids are not practical, deployments SHOULD use tight per-issuer constraints in instance_issuers (per-tenant spiffe_id paths, per-tenant trust_domain values, or descriptor-level scope members that constrain accepted sub values to a specific tenant) and treat the cross-tenant blast radius as a known operational risk. Tenant isolation in such deployments is enforced by the breadth of these per-issuer constraints, not by the OAuth client identity.¶

This profile does not define a tenant identifier as a first-class claim. Future profiles MAY introduce one if cross-deployment interoperability of tenant scoping becomes necessary.¶

12.9. Mode-Switch Between Delegation and Self-Acting

Whether an issued access token represents delegation or self-acting (Section 8.6.1) determines whether the instance is exposed to resource servers as act or as sub. An adversary that can influence classification could escalate privileges, for example by inducing the AS to drop a sub belonging to a user and re-anchor the token on the instance's sub. The classification rule in Section 8.6.1 is determined by the grant type, not by comparison of attacker-influenceable subject strings; ASes MUST NOT employ heuristic or fuzzy matching of assertion contents to override the table. In particular, ASes MUST NOT normalize either side of any comparison they perform on subject identifiers (no Unicode normalization, no case folding, no percent-decoding beyond what [RFC7519] requires for JSON parsing). When classification is ambiguous (for example, custom grants not listed in the table), the AS MUST refuse rather than guess.¶

12.10. Sender-Constraint Requirement

Without sender-constraint, an act claim is an assertion about who acted, not a binding enforced at the resource server: any party in possession of the access token can present it as the named actor. Section 8.5 therefore requires sender-constrained access tokens and forbids bearer issuance under this profile. Per [ACTOR-PROFILE], the resource server validates proof of possession against the access token's top-level cnf only; confirmation members inside an act object are actor context for audit and correlation, not a binding the RS independently verifies.¶

12.11. Delegation Control

Unbounded delegation chains permit privilege amplification across boundaries. AS implementations MUST enforce a local maximum delegation depth ([ACTOR-PROFILE]). [ACTOR-PROFILE] recommends supporting at least depth 4 for cross-domain interop; deployments imposing lower ceilings should weigh interoperability against the privilege-amplification surface they are willing to allow.¶

12.12. Privacy

A client instance assertion reveals fine-grained workload identity to the AS and, after issuance, to resource servers via the act claim (delegation case) or the access token's top-level sub (self-acting case). Exposing per-instance identity to resource servers is the deliberate purpose of this profile (it is what enables instance-level audit, authorization, and binding downstream), but it has privacy and operational consequences:¶

• Resource servers gain visibility into the deploying organization's internal workload structure, including (depending on sub) cluster names, namespaces, function instance IDs, or session identifiers. Resource server operators SHOULD treat this information with the same care as any other identity attribute received from an AS, and SHOULD NOT log or propagate it more broadly than necessary.¶

• Naming conventions in sub may inadvertently encode sensitive details. Issuers and clients SHOULD avoid encoding identifiers of human users, secret material, or internal infrastructure topology in sub, and SHOULD prefer opaque or hierarchical identifiers (e.g., a SPIFFE path) whose minimum granularity matches the auditing need.¶

The error response guidance in Section 8.9 extends to logs and audit trails: instance assertion contents SHOULD be logged at a level commensurate with the sensitivity of the workload identity they convey.¶

13.1. OAuth Token Type

IANA is requested to register the following value in the "OAuth URI" registry established by [RFC6755] (and used by [RFC8693] for actor_token_type values on the token-exchange grant):¶

URN:

urn:ietf:params:oauth:token-type:client-instance-jwt¶

Common Name:

OAuth 2.0 Client Instance Assertion¶

Change Controller:

IETF¶

Specification Document(s):

This document¶

13.2. OAuth Client Instance Subject Syntaxes

IANA is requested to create a new sub-registry titled "OAuth Client Instance Subject Syntaxes" under the "OAuth Parameters" registry group established by [RFC6749]. Registration policy is Specification Required [RFC8126].¶

A Client Instance Subject Syntax is a short identifier appearing in the subject_syntax member of an instance issuer descriptor (Section 6.1.1). It declares the syntactic form of the sub claim used by the issuer and selects validation rules the AS applies to that claim.¶

Registry fields:¶

Syntax Identifier:

A short label used as the subject_syntax value. ABNF: 1*( ALPHA / DIGIT / "-" ).¶

Description:

A short description of the subject form.¶

Change Controller:

As required by Specification Required policy.¶

Specification Document(s):

The defining specification.¶

IANA is requested to register the following initial values:¶

13.3. OAuth Parameters Registration

IANA is requested to register the following value in the "OAuth Parameters" registry established by [RFC6749]:¶

Parameter name:

client_instance_assertion¶

Parameter usage location:

token request¶

Change Controller:

IETF¶

Specification Document(s):

Section 4 of this document¶

13.4. OAuth Dynamic Client Registration Metadata

IANA is requested to register the following parameters in the "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]. The Change Controller for each entry is IETF.¶

13.5. OAuth Token Endpoint Authentication Method

IANA is requested to register the following value in the "OAuth Token Endpoint Authentication Methods" registry established by [RFC8414]:¶

Token Endpoint Authentication Method Name:

client_instance_assertion¶

Change Controller:

IETF¶

Specification Document(s):

Section 8.3 of this document¶

13.6. OAuth Authorization Server Metadata

IANA is requested to register the following parameters in the "OAuth Authorization Server Metadata" registry established by [RFC8414]. The Change Controller for each entry is IETF.¶

13.7. Media Type

IANA is requested to register the following media type in the "Media Types" registry:¶

Type name:

application¶

Subtype name:

client-instance+jwt¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; A Client Instance Assertion is a JWT; JWT values are encoded as a series of base64url-encoded values separated by period characters.¶

Security considerations:

See Section 12 of this document.¶

Interoperability considerations:

N/A¶

Published specification:

This document.¶

Applications that use this media type:

OAuth 2.0 authorization servers and clients implementing this profile.¶

Fragment identifier considerations:

N/A¶

Additional information:

Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Karl McGuinness public@karlmcguinness.com¶

Intended usage:

COMMON¶

Restrictions on usage:

none¶

Author:

Karl McGuinness¶

Change controller:

IETF¶

This media type, when used as a value of the typ JWS protected header parameter ([RFC7515] Section 4.1.9), MUST be client-instance+jwt (per [RFC8725] Section 3.11; the application/ prefix is omitted).¶

13.8. OAuth Entity Profile

IANA is requested to register the following value in the "OAuth Entity Profiles" registry established by [ENTITY-PROFILES]. This registration is contingent on the establishment of that registry.¶

Profile Name:

client_instance¶

Profile Description:

A concrete runtime instance of an OAuth client identified by a client_id.¶

Profile Usage Location:

Actor Profile¶

Change Controller:

IETF¶

Specification Document(s):

This document¶

14.1. Normative References

[ACTOR-PROFILE]

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

[CIMD]

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

[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-01, 15 April 2026, <https://datatracker.ietf.org/doc/html/draft-mora-oauth-entity-profiles-01>.

[RFC2119]

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

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

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

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

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

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

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

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC7662]

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

[RFC7800]

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

[RFC8126]

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

[RFC8174]

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

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

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

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

[SPIFFE-CLIENT-AUTH]

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-02, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

14.2. Informative References

[ATTEST-CLIENT-AUTH]

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-09, 25 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-09>.

[RFC7009]

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

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/rfc/rfc8037>.

[SPIFFE]

SPIFFE, "SPIFFE: Secure Production Identity Framework For Everyone", 2024, <https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/>.

[WIMSE-ARCH]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-07, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-07>.

[WIMSE-CREDS]

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

Why not a client_instance identifier parameter?

A new top-level client_instance identifier would have to flow through the authorization request, the token request, introspection, the access token, and several existing extensions. Each is a separate specification touch-point and a deployment cliff. The validated instance identity surfaces in the issued access token's act.sub (delegation) or top-level sub (self-acting) per Section 8.6, which is the only place a resource server needs it; downstream profiles consume that representation rather than a parallel identifier.¶

Why a dedicated client_instance_assertion request parameter?

This profile defines a dedicated request parameter for presenting a Client Instance Assertion on the four non-token-exchange grants listed in Section 4.1, rather than reusing [RFC8693]'s actor_token / actor_token_type parameters on those grants. [RFC8693] defines actor_token and actor_token_type only on the token-exchange grant; this profile uses actor_token only on that grant (Section 4.2).¶

The reasons for a dedicated parameter on the other grants:¶

First, the parameter name matches what it carries. A request body with client_instance_assertion=... declares its purpose; a request with actor_token=...&actor_token_type=urn:...:client-instance-jwt requires the AS to inspect the type URN to recognize the same artifact. The dedicated parameter is more discoverable and easier to implement against.¶

Second, the self-acting case (notably client_credentials) does not fit [RFC8693]'s "actor" framing, in which the actor is a party distinct from the subject. In this profile's self-acting case the instance is the subject (top-level sub) rather than the actor (act); see Section 8.6.1. Naming the parameter actor_token for that case would require readers to mentally translate "actor token" to "validated instance identity assertion." The dedicated parameter removes that translation; the grant determines whether the result is delegation or self-acting.¶

Third, the dedicated parameter parallels the wire conventions of [ATTEST-CLIENT-AUTH], which uses purpose-named headers (OAuth-Client-Attestation and -PoP) rather than a typed general-purpose carrier. The two specifications use purpose-named wire artifacts that an AS can dispatch by parameter name rather than by URN inspection.¶

The URN urn:ietf:params:oauth:token-type:client-instance-jwt remains registered to identify the assertion when carried as actor_token on a token-exchange grant per [RFC8693]; see Section 4.2. The two parameter names are wire-syntax siblings carrying the same assertion under identical validation rules.¶

Why client metadata as the trust anchor for instance issuers?

The trust relationship between a client and its instance issuers is published in the client's registered metadata (either in a CIMD document or in the AS's registration store). This keeps the trust relationship auditable alongside other client metadata and reuses existing freshness, caching, and key-rotation mechanisms. Locating it elsewhere (in AS-side static configuration unrelated to the client, or in a separate trust-relationship registry) would have fragmented the surface and reduced the auditability of who trusts whom.¶

Why a token_endpoint_auth_method rather than a client_assertion_type?

[SPIFFE-CLIENT-AUTH] models its workload-identity-as-client-auth mechanism as a client_assertion_type. The natural question is why Section 8.3 does not.¶

The two cases differ in what the JWT names. A SPIFFE JWT-SVID presented as a client_assertion under [SPIFFE-CLIENT-AUTH] names the client (its sub is the spiffe_id of the workload acting as the client). The client-metadata listing of spiffe_id, including the permitted "/*" path-segment wildcard, turns the SVID into a credential for the client. There is no separate notion of "instance" on the wire.¶

A client instance assertion under this profile names the instance: its sub is the instance identifier and its client_id claim names the client. The same JWT is required to do double duty only when the client chooses token_endpoint_auth_method = client_instance_assertion; in every other auth method, a separate client credential authenticates the client and the instance assertion names the instance.¶

Modeling the dual-use case as a client_assertion_type would have required either (a) inventing a second token type identical to the Client Instance Assertion to serve as the client assertion, doubling the wire surface, or (b) overloading client_assertion_type with the actor-token URN, which conflicts with that URN's role on token-exchange grants. Modeling it as a token_endpoint_auth_method captures what is actually happening, namely that the AS authenticates the client implicitly from its client-metadata endorsement of the instance assertion's issuer, while keeping client_assertion and client_instance_assertion semantically distinct.¶

Authorization Code with User Delegation

Alice authorizes the agent (client) at the AS through a standard authorization_code flow. The agent runs as instance inst-01, which presents an instance assertion at the token endpoint to identify itself.¶

Authorization request from the agent (abridged). dpop_jkt carries the thumbprint of inst-01's DPoP key (matching the instance assertion's cnf.jkt) to establish key-bound continuity per Section 8.4:¶

GET /authorize?response_type=code
  &client_id=https%3A%2F%2Fapp.example.com%2Fagent
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
  &scope=repo.write
  &state=xyz
  &code_challenge=...
  &code_challenge_method=S256
  &dpop_jkt=0ZcOCORZNYy...iguA4I HTTP/1.1
Host: as.example.com

The AS authenticates Alice, displays consent for the client (per Section 8.4 consent applies to the client as a whole, not per-instance), binds the authorization code to the dpop_jkt value per [RFC9449], and redirects with an authorization_code.¶

Token request from instance inst-01:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-01's key>

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&code_verifier=...
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs... (private_key_jwt)
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

Decoded client_instance_assertion:¶

{
  "iss":         "https://workload.app.example.com",
  "sub":         "https://workload.app.example.com/inst-01",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770000000,
  "exp":         1770000300,
  "jti":         "ac-1a2b3c",
  "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
}

AS validation:¶

1. Authenticates the client (private_key_jwt).¶

2. Recognizes the client_instance_assertion parameter for this grant.¶

3. Resolves CIMD for the agent.¶

4. Locates the descriptor by matching iss.¶

5. Verifies signature via descriptor's jwks_uri.¶

6. Validates JWT claims.¶

7. Verifies the assertion's client_id == request client_id and applies the (iss, jti) replay check.¶

8. Applies AS-local maximum delegation depth.¶

9. Section 8.4: the request's client_id matches the client_id that received the code, and the DPoP proof's thumbprint matches both the code's dpop_jkt and the assertion's cnf.jkt.¶

10. Classifies as delegation; issues sender-constrained access token.¶

Issued access token:¶

{
  "iss":       "https://as.example.com",
  "aud":       "https://api.example.com",
  "sub":       "user:alice@example.com",
  "client_id": "https://app.example.com/agent",
  "scope":     "repo.write",
  "iat":       1770000005,
  "exp":       1770001805,
  "cnf":       { "jkt": "0ZcOCORZNYy...iguA4I" },
  "act": {
    "iss":         "https://workload.app.example.com",
    "sub":         "https://workload.app.example.com/inst-01",
    "sub_profile": "client_instance",
    "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
  }
}

The RS authorizes the request based on (alice, inst-01) per Section 9.¶

Client Credentials (Self-Acting)

A workload makes a client_credentials request with no human user involved.¶

Token request:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-02's key>

grant_type=client_credentials
&scope=repo.read
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs...
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

Decoded client_instance_assertion:¶

{
  "iss":         "https://workload.app.example.com",
  "sub":         "https://workload.app.example.com/inst-02",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770000000,
  "exp":         1770000300,
  "jti":         "cc-2b3c4d",
  "cnf":         { "jkt": "PqR...XyZ" }
}

Issued access token (self-acting; no user, instance is the principal):¶

{
  "iss":         "https://as.example.com",
  "aud":         "https://api.example.com",
  "sub":         "https://workload.app.example.com/inst-02",
  "sub_profile": "client_instance",
  "client_id":   "https://app.example.com/agent",
  "scope":       "repo.read",
  "iat":         1770000005,
  "exp":         1770001805,
  "cnf":         { "jkt": "PqR...XyZ" }
}

The RS treats sub as the workload identity (not a human user) per Section 9.¶

Token Exchange with Prior Delegation Chain (Agent Spawns Sub-Agent)

A parent agent's user-delegated access token is exchanged at the AS for a sub-agent's downstream-resource-scoped token. The sub-agent runtime presents an instance assertion; the inbound subject_token already carries an act chain naming the parent agent. The subject_token was issued by upstream.example.com, which as.example.com trusts as a token issuer under local policy.¶

Inbound subject_token (decoded; issued earlier when a parent agent "agent-orchestrator-alpha" obtained access on the user's behalf):¶

{
  "iss":       "https://upstream.example.com",
  "aud":       "https://app.example.com/agent",
  "sub":       "user:alice@example.com",
  "scope":     "repo.write",
  "act": {
    "iss":         "https://platform.example.com",
    "sub":         "agent:orchestrator-alpha",
    "sub_profile": "client_instance"
  }
}

Token request:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-03's key>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=https%3A%2F%2Fapi.example.com
&subject_token=eyJhbGciOiJFUzI1NiIs...
&subject_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs...
&actor_token=eyJhbGciOiJFUzI1NiIs...
&actor_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aclient-instance-jwt

The actor_token carries the Client Instance Assertion for the sub-agent runtime inst-03, with no act of its own (per [ACTOR-PROFILE], an actor_token MUST NOT carry act). Decoded actor_token:¶

{
  "iss":         "https://workload.app.example.com",
  "sub":         "https://workload.app.example.com/inst-03",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770000005,
  "exp":         1770000305,
  "jti":         "tx-3c4d5e",
  "cnf":         { "jkt": "AbC...123" }
}

Chain construction per Section 8.6.4:¶

• Outermost: the validated Client Instance Assertion (sub-agent inst-03).¶

• Inner: the subject_token's act chain, preserved (agent-orchestrator-alpha).¶

Issued access token:¶

{
  "iss":       "https://as.example.com",
  "aud":       "https://api.example.com",
  "sub":       "user:alice@example.com",
  "client_id": "https://app.example.com/agent",
  "scope":     "repo.write",
  "iat":       1770000010,
  "exp":       1770001810,
  "cnf":       { "jkt": "AbC...123" },
  "act": {
    "iss":         "https://workload.app.example.com",
    "sub":         "https://workload.app.example.com/inst-03",
    "sub_profile": "client_instance",
    "cnf":         { "jkt": "AbC...123" },
    "act": {
      "iss":         "https://platform.example.com",
      "sub":         "agent:orchestrator-alpha",
      "sub_profile": "client_instance"
    }
  }
}

Resulting chain depth is 2, well within typical AS-local maximums. The chain reads outward-in as: sub-agent inst-03 acted on behalf of the parent agent agent-orchestrator-alpha, which acted on behalf of user alice. Each act layer names a distinct runtime; resource servers and audit pipelines can attribute the request to the specific sub-agent that performed it.¶

Refresh with a Fresh Instance Assertion

Some time after the authorization-code example (Appendix "Authorization Code with User Delegation"), instance inst-01's original access token approaches expiry. The original Client Instance Assertion has also expired, so the client mints a fresh assertion (same iss, sub, and cnf) and presents it on the refresh request. The refresh token is sender-constrained to the same DPoP key per Section 8.7.¶

Token request:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-01's key>

grant_type=refresh_token
&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs... (private_key_jwt)
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

Decoded fresh client_instance_assertion:¶

{
  "iss":         "https://workload.app.example.com",
  "sub":         "https://workload.app.example.com/inst-01",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770001700,
  "exp":         1770002000,
  "jti":         "rf-1a2b3c",
  "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
}

AS validation per Section 8.7:¶

1. Authenticate the client (private_key_jwt).¶

2. Verify the refresh token belongs to this client and is bound to the presented DPoP key.¶

3. Validate the fresh assertion per Section 8.2; in particular verify that its (iss, sub) match those recorded at original issuance and its cnf matches the refresh-token binding key.¶

4. Inherit the original grant's classification (delegation), per Section 8.6.1.¶

5. Issue a new sender-constrained access token with the same act chain.¶

The refreshed access token is identical in shape to the original (Appendix "Authorization Code with User Delegation"), with updated iat and exp.¶

A second variant of this flow omits the fresh assertion entirely:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-01's key>

grant_type=refresh_token
&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs...

Without a fresh client_instance_assertion, the AS still inherits the original delegation classification and the original act chain (sender-constrained to the same DPoP key, since the refresh token was bound to it). This is the common case when instance identity has not changed since issuance; the issued access token's act claim is unchanged from Appendix "Authorization Code with User Delegation" (with updated iat and exp). Refresh does not introduce a new instance identity.¶

Client Authenticated via Instance Assertion

A workload's OAuth client is registered with token_endpoint_auth_method = client_instance_assertion (Section 8.3). The workload presents no separate client credential; the Client Instance Assertion authenticates both the client (through the registered endorsement of its issuer) and the instance.¶

Token request:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <DPoP proof bound to inst-04's key>

grant_type=client_credentials
&scope=repo.write
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

Decoded client_instance_assertion:¶

{
  "iss":         "https://workload.app.example.com",
  "sub":         "https://workload.app.example.com/inst-04",
  "aud":         "https://as.example.com",
  "client_id":   "https://app.example.com/agent",
  "sub_profile": "client_instance",
  "iat":         1770000100,
  "exp":         1770000400,
  "jti":         "ia-4d5e6f",
  "cnf":         { "jkt": "QrS...789" }
}

AS validation per Section 8.3.2:¶

1. Resolve the registered metadata for client_id (token_endpoint_auth_method is client_instance_assertion, so no separate client credential is expected and none is accepted on this request).¶

2. Validate the assertion using the descriptor lookup, signature verification, and JWT claim validation rules in Section 8.2 (token-type matching does not apply on client_credentials).¶

3. Verify the assertion's client_id claim equals the request's client_id parameter.¶

4. Verify the assertion contains a cnf claim.¶

5. Verify possession of the cnf key against the DPoP proof per Section 8.5.¶

6. Apply the replay check (Section 12.5).¶

7. Treat the client as authenticated. The validated assertion represents the instance for Section 8.6.¶

Any failure in steps 1-6 above is returned as invalid_client per Section 8.9; the assertion is the sole credential, so failures that would otherwise be returned as invalid_grant or invalid_request are reclassified.¶

Self-acting access token issued by the AS:¶

{
  "iss":         "https://as.example.com",
  "aud":         "https://api.example.com",
  "sub":         "https://workload.app.example.com/inst-04",
  "sub_profile": "client_instance",
  "client_id":   "https://app.example.com/agent",
  "scope":       "repo.write",
  "iat":         1770000105,
  "exp":         1770001905,
  "cnf":         { "jkt": "QrS...789" }
}

SPIFFE Workload (Self-Acting, JWT-SVID Reuse with X.509-SVID Binding)

A SPIFFE workload makes a client_credentials request. The workload holds both a JWT-SVID and an X.509-SVID issued by its SPIFFE trust domain. The workload presents the JWT-SVID directly as the client_instance_assertion under raw JWT-SVID compatibility (Section 8.8.1) and presents the X.509-SVID at TLS, so the certificate supplies the sender-constraint binding ([RFC8705]). Because the presented assertion is a raw JWT-SVID, its JOSE header follows SPIFFE conventions and is not required to carry typ=client-instance+jwt.¶

The descriptor uses subject_syntax="spiffe" and the access token is mTLS-bound, in place of the preamble's URI-syntax descriptor and DPoP binding.¶

Instance issuer descriptor:¶

{
  "issuer": "spiffe://example.com",
  "spiffe_bundle_endpoint": "https://example.com/spiffe/bundle",
  "subject_syntax": "spiffe",
  "trust_domain": "example.com",
  "spiffe_id": "spiffe://example.com/agent/*",
  "signing_alg_values_supported": ["ES256"]
}

Token request (TLS presents the workload's X.509-SVID; client authentication uses [SPIFFE-CLIENT-AUTH] X.509 mode, so client_assertion is omitted):¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=repo.read
&client_id=https%3A%2F%2Fapp.example.com%2Fagent
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

Decoded client_instance_assertion:¶

{
  "iss":         "spiffe://example.com",
  "sub":         "spiffe://example.com/agent/inst-04",
  "aud":         "https://as.example.com",
  "iat":         1770000000,
  "exp":         1770000300
}

The AS verifies the JWT-SVID signature against the trust bundle, that sub falls under the descriptor's spiffe_id prefix, that the TLS-presented X.509-SVID has SAN URI exactly equal to the JWT-SVID's sub, and binds the issued access token via cnf.x5t#S256 set to the certificate's SHA-256 thumbprint. Issued access token (self-acting; TTL kept short relative to the X.509-SVID rotation cycle):¶

{
  "iss":         "https://as.example.com",
  "aud":         "https://api.example.com",
  "sub":         "spiffe://example.com/agent/inst-04",
  "sub_profile": "client_instance",
  "client_id":   "https://app.example.com/agent",
  "scope":       "repo.read",
  "iat":         1770000005,
  "exp":         1770001805,
  "cnf":         { "x5t#S256": "AbCdE...xyz" }
}

At the resource server, the workload connects over mTLS with the same X.509-SVID; the RS verifies that the certificate thumbprint matches the access token's cnf.x5t#S256.¶

-01

• Wire surface. Introduced the client_instance_assertion request parameter on authorization_code, client_credentials, refresh_token, and JWT bearer grants, and the JOSE typ value client-instance+jwt. Token-exchange continues to present the assertion as actor_token with the registered token type urn:ietf:params:oauth:token-type:client-instance-jwt. Dropped the previous "actor token grant extension" framing and the generalization over arbitrary actor-token profiles.¶

• Access token surfacing. §access-token specifies how a validated Client Instance Assertion surfaces in the issued access token: act (delegation case) or top-level sub (self-acting case), with sub_profile ([ACTOR-PROFILE]) signalling the kind of subject, and sender-constraint binding per §sender-constrained. The generic JWT access-token contract is inherited from [RFC9068]; this profile does not restate the [RFC9068] claim set. Added §rs-processing-introspection requiring opaque tokens to surface the same set of claims via introspection.¶

• Validation procedure. Specified the client_instance_assertion token-endpoint authentication method (Section 8.3) with its validation procedure and invalid_client re-coding. Ordered §as-processing so PoP verification precedes replay checking (enabling the cnf-bound reusable-mode optimization). Specified octet-equality for iss/sub/client_id/aud/spiffe_id comparisons. Specified (iss, jti) replay-cache scope.¶

• SPIFFE. Added §spiffe-compatibility for raw JWT-SVID presentation without re-minting, with sender-constraint established via an independent binding key per §spiffe-binding.¶

• Security additions. New sections on multi-tenancy under a single client_id (Section 12.8) and the AS's inability to verify issuer-side compliance with the per-client minting rule. Softened §trust-model-as on AS-side issuer configuration from prescriptive to advisory. Added trust-root-collapse considerations for the auth-method mode.¶

• Signing. Declared ES256 mandatory-to-implement; RS256 SHOULD-support.¶

• IANA. Established the "OAuth Client Instance Subject Syntaxes" sub-registry (Specification Required) seeded with uri and spiffe. Added the client_instance_assertion token-endpoint-authentication-method registration.¶

• Metadata. Defined instance_issuers client metadata and the client_instance_assertion_supported AS metadata parameter.¶

• Editorial. Retitled to "OAuth 2.0 Client Instance Assertion". Added worked examples for authorization-code, client-credentials, token-exchange, refresh (with and without a fresh CIA), the client_instance_assertion auth method, and SPIFFE JWT-SVID reuse. Inverted and expanded §Design Rationale. Trimmed operational/deployment content not in scope for an OAuth protocol spec: removed the cross-instance-session-continuity recipes in §refresh; dropped the specific TTL "recommended defaults" in §security-trust-withdrawal-latency; removed the "Defer adoption" bullet from §Adoption; generalized §Introduction use-case language; trimmed §rs-processing's restatement of [ACTOR-PROFILE] to just the three additions this profile makes. Aligned the §instance-issuers example with the worked examples (app.example.com/agent).¶

-00

• Initial version.¶