OAuth 2.0 AI Agent Instance Profile

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

AI agent platforms are OAuth clients. A platform registers a single client_id and then runs many concurrent agent instances under it: one per user session, task, or delegated workflow. Resource servers receiving access tokens from these platforms see only the platform's client_id; this includes Model Context Protocol servers ([MCP]), which use OAuth for authorization. Every agent session collapses into one identity, defeating per-agent authorization, audit attribution, incident response, and abuse containment.¶

The OAuth 2.0 Client Instance Assertion specification [CIA-CORE] defines the general mechanism this profile builds on: a client instance proves its identity to the authorization server (AS) at the token endpoint, and the validated instance identity surfaces in the issued access token as act.sub (when the agent acts on a user's or another principal's behalf) or top-level sub (when the agent acts as itself), sender-constrained to a key the instance holds.¶

This profile adds what agent deployments need beyond a bare instance identifier:¶

• A stable, attester-minted agent instance identifier (Section 4). The instance subject is an identifier the agent attester mints for the agent session rather than a key thumbprint, so it survives key rotation and names something an audit record can act on.¶

• Attested agent provenance (Section 4): optional claims conveying the agent platform, the model an agent instance runs, and evidence about its runtime environment, so resource servers can apply provenance-aware policy.¶

• A uniform agent classification: surfacing rules that mark agent actors with the ai_agent entity profile registered by [ENTITY-PROFILES], so resource servers can distinguish agent actors from other workload actors with a single signal (Section 8).¶

• Attested delegation chains (Section 9): when an agent spawns a sub-agent, each hop presents its own instance evidence, producing an act chain in which every actor was attested rather than merely asserted.¶

The claims defined here are carrier-independent (Section 5). Workload-style deployments convey them in a Client Instance Assertion per [CIA-CORE]; deployments using OAuth 2.0 Attestation-Based Client Authentication [ATTEST-CLIENT-AUTH] convey them in the Client Attestation. The claims, the subject derivation, and the access-token surfacing are identical in both cases.¶

This profile does not define agent capability or tool-permission semantics; deployments expressing fine-grained agent permissions compose this profile with Rich Authorization Requests ([RFC9396]) or deployment-specific scope design.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms "Client Instance Assertion", "client instance", "instance issuer", and "OAuth client" as defined in [CIA-CORE], and "Client Attestation", "Client Attester", and "DPoP combined mode" as defined in [ATTEST-CLIENT-AUTH].¶

Agent:

An autonomous or semi-autonomous software actor, typically driven by a machine-learning model, that performs tasks by calling APIs, optionally on behalf of a user or another principal.¶

Agent Platform:

The OAuth client under which agent instances run. The platform holds the client registration and operates the control plane that spawns, supervises, and terminates agent instances.¶

Agent Instance:

A client instance ([CIA-CORE]) that is an agent: a specific agent session, task execution, or runtime.¶

Agent Attester:

The authority that authenticates agent instances and mints the agent instance claims defined in Section 4. Depending on the carrier (Section 5), the Agent Attester is a [CIA-CORE] instance issuer or an [ATTEST-CLIENT-AUTH] Client Attester. It is typically the agent platform's control plane, but MAY be a distinct party (see Section 11).¶

Agent Instance Evidence:

The carrier artifact conveying the agent instance claims of Section 4 to the AS: either a Client Instance Assertion, or a Client Attestation with its proof of possession.¶

3. Relationship to Other Specifications

This profile depends normatively on [CIA-CORE] for token-endpoint processing, sender-constraint binding, access-token representation, refresh-token semantics, and resource-server processing. It surfaces the ai_agent entity profile defined and registered by [ENTITY-PROFILES], profiling its use for attested agent instances. When the Client Attestation carrier is used, it depends on [ATTEST-CLIENT-AUTH] for attestation validation, including DPoP combined mode ([RFC9449]).¶

Delegation-chain construction follows the act semantics of [RFC8693] as profiled by [CIA-CORE].¶

Runtime-environment evidence is conveyed using the Entity Attestation Token ([RFC9711]) via the agent_runtime claim (Section 4); this profile does not define an evidence format of its own.¶

Transaction Tokens ([TXN-TOKENS]) address propagation of immutable context across workloads within a trust domain after initial authorization; this profile addresses agent instance identity at initial token issuance. The two are complementary: a deployment may derive transaction tokens from access tokens issued under this profile, carrying the agent instance identity into the transaction context.¶

Identity and authorization chaining ([ID-CHAINING]) enables an authorization server in one domain to issue tokens redeemable in another, the pattern underlying enterprise cross-application access deployments in which an enterprise identity provider brokers agent access to third-party resources. That work moves identity across domains; it does not define agent claims. The two compose naturally: an authorization server applying this profile at issuance carries the agent instance identity and provenance into the chained tokens it brokers.¶

[ATTEST-CLIENT-AUTH] authenticates a client instance at the token endpoint but defines no representation of it in issued tokens; the design rationale appendix records why this profile builds its representation layer on [CIA-CORE] rather than over [ATTEST-CLIENT-AUTH] alone.¶

Agent identity is an active topic in multiple communities. This profile deliberately limits itself to two things: conveying attested agent instance identity and provenance to the OAuth token endpoint, and representing that identity in issued access tokens. It does not define agent-to-agent authentication protocols, agent discovery, capability or tool description, or model governance, and is designed to compose with, rather than compete with, specifications that do. In particular, fine-grained permission description composes via Rich Authorization Requests ([RFC9396]), and hardware-rooted runtime evidence composes via Entity Attestation Token formats ([RFC9711]).¶

4. Agent Instance Claims

The following claims are conveyed in the Agent Instance Evidence by the Agent Attester. Claim names are registered in the JSON Web Token Claims registry (Section 16.1). The claims are validated by the AS as part of carrier validation (Section 5); unknown members within object-valued claims MUST be ignored unless a profile of this document defines their processing.¶

agent_instance_id (REQUIRED):

A StringOrURI ([RFC7519]) identifying this agent instance, minted by the Agent Attester. The value MUST be unique among all instances attested by this Attester (across every OAuth client the Attester serves, so that resource servers evaluating the identifier need not qualify it by client_id) and MUST be stable for the lifetime of the agent instance. The value MUST NOT be derived from a proof-of-possession key: keys are binding material, not identity (Section 7). The Attester MUST NOT reassign an active or audit-relevant value to a different instance; see Section 15.2. Attesters SHOULD mint URI-shaped values within a namespace they control (for example, https://attester.example.com/instances/sess-9f2c), which makes the minting authority evident to consumers of the identifier.¶

agent_platform (OPTIONAL):

A StringOrURI identifying the agent platform or orchestration runtime under which the instance executes (for example, an identifier naming the orchestrator product and its major version). The value identifies software operated by the Agent Platform, not the OAuth client identity, which continues to be conveyed by client_id.¶

agent_model (OPTIONAL):

A JSON object characterizing the primary model configured for the agent instance, as determined by the Agent Attester at evidence issuance. The object contains an id member (REQUIRED, a StringOrURI model identifier) and MAY contain a version member (a string). The claim describes the instance's configuration, not each individual operation: an agent instance may route individual operations to other models (for example, routing, fallback, or auxiliary models) without invalidating the claim. A change to the primary configured model, however, means previously issued evidence no longer describes the instance, and the Attester MUST issue fresh evidence before the instance obtains further tokens under this profile (Section 15.1). A registry of model identifiers is out of scope; agent_model.id interoperability is an agreement between the Attester and the resource servers that consume it.¶

agent_runtime (OPTIONAL):

A JSON object conveying evidence about the runtime environment of the agent instance, such as confidential-computing or trusted-execution attestation results. This document defines one member: eat (OPTIONAL), containing an Entity Attestation Token ([RFC9711]), carried as the JWT compact serialization when the EAT is in JWT form or base64url-encoded when in CWT form. The two forms are distinguishable by structure: a JWT compact serialization contains period separators, while a base64url-encoded CWT does not. Additional members MAY be defined by deployments or companion profiles; unknown members MUST be ignored. agent_runtime is consumed by the AS for policy and is not surfaced to resource servers by default (Section 8).¶

An AS that receives Agent Instance Evidence for a client registered for this profile (Section 6) MUST reject evidence that omits agent_instance_id (Section 13). Evidence whose object-valued claims are malformed (for example, agent_model without an id member) MUST be rejected the same way.¶

5. Evidence Carriers

The claims in Section 4 are carried in exactly one of the following artifacts per token request. The claims, their validation, and all downstream processing are identical regardless of carrier.¶

6. Client and Authorization Server Metadata

This document defines one client metadata parameter (registered per [RFC7591], applicable to any registration model supported by [CIA-CORE]) and one authorization server metadata parameter (registered per [RFC8414]):¶

ai_agent_instance_profile (client metadata):

OPTIONAL. Boolean, default false. When true, the client is registered for this profile. The AS MUST require Agent Instance Evidence on every token request from the client on the grants covered by [CIA-CORE]'s access-token classification, except refresh_token requests, which follow Section 10; a covered request presenting no evidence MUST be rejected (Section 13). Without this requirement, an instance could omit evidence and obtain tokens indistinguishable from an ordinary client's, silently escaping the attribution this profile provides. The client's registration or AS policy MAY exempt designated grant types whose requests are not made by agent instances (for example, client_credentials used by the platform's control plane); exempted requests are processed as ordinary OAuth requests and receive no instance representation. The AS MUST require agent_instance_id in the client's Agent Instance Evidence (Section 4) and MUST apply the surfacing rules of Section 8; when the Client Attestation carrier is used, this registration constitutes the client's agreement required by Section 5.2. Deployments without access to this parameter MAY establish the same registration by out-of-band agreement.¶

ai_agent_instance_profile_supported (AS metadata):

OPTIONAL. Boolean. Indicates that the AS supports this profile: validating agent instance claims, deriving the instance subject per Section 7, and surfacing per Section 8. An AS implementing this profile MUST include this parameter, set to true, in any authorization server metadata it publishes. Clients SHOULD verify it before depending on agent instance surfacing, since an AS without support may process the underlying carrier without applying this profile's representation.¶

7. Instance Subject Derivation

The instance subject used for access-token surfacing is the agent_instance_id value, scoped to the Agent Attester that minted it. The AS MUST NOT derive the instance subject from a proof-of-possession key thumbprint: keys are binding material, not identity, and key rotation MUST NOT change the agent instance's identity. Consumers needing key-level correlation can use the access token's cnf confirmation claim directly.¶

Because the subject is Attester-minted and key-independent:¶

• the identity is stable across DPoP or binding-key rotation within an instance's lifetime: access tokens obtained with a rotated key carry the same instance subject, so resource-server policy state and audit trails keyed on the subject survive rotation (Section 10 covers the refresh-token interaction);¶

• audit records name an identifier the Agent Attester can resolve to session context, rather than an opaque key fingerprint.¶

When a client lists multiple Agent Attesters, the subject-collision requirements of [CIA-CORE] apply: the client MUST ensure the Attesters' agent_instance_id spaces do not collide. Attesters that follow the URI-shaped minting recommendation of Section 4 satisfy this structurally, since each mints within a namespace it controls.¶

8. Access Token Surfacing

Access-token representation follows [CIA-CORE]: the instance subject appears as act.sub in delegation cases and as top-level sub in self-acting cases, and the issued access token is sender-constrained per [CIA-CORE].¶

This profile additionally specifies:¶

• The surfaced sub_profile (top-level in self-acting cases, act.sub_profile in delegation cases) MUST include both the value ai_agent (defined by [ENTITY-PROFILES]) and the value client_instance (registered by [CIA-CORE]), per the list syntax of the underlying registry. Every agent instance is a client instance; including both values lets resource servers that implement [CIA-CORE] but not this profile continue to classify the actor correctly. Other applicable registered values MAY additionally be included.¶

• The AS MAY surface agent_platform and agent_model subject to local policy and the privacy considerations of Section 15.8. Surfaced provenance claims appear within the act object in delegation cases (they describe the actor) and at top level in self-acting cases (the instance is the subject). An AS MUST NOT surface provenance claims that were not present in validated Agent Instance Evidence.¶

• agent_runtime evidence is consumed by the AS for policy and MUST NOT be surfaced to resource servers verbatim. Deployments that expose a runtime-assurance signal to resource servers SHOULD surface a coarse assurance tier (Section 11) via a deployment-defined claim rather than raw evidence.¶

For opaque (reference) access tokens, the same surfaced claims appear in introspection responses, per [CIA-CORE]'s introspection requirements.¶

9. Attested Delegation Chains

When an agent instance spawns a sub-agent that requires its own access token, the sub-agent obtains it via token exchange ([RFC8693]) using [CIA-CORE]'s token-exchange presentation, presenting its own Agent Instance Evidence (either carrier). The resulting act chain nests the spawning agent's actor entry per [CIA-CORE]'s chain merging, and scope attenuation at each exchange follows [RFC8693].¶

Whether a given instance is permitted to perform such an exchange is AS authorization policy under [RFC8693] and [CIA-CORE]; this profile defines no separate spawn-permission mechanism. Because chain merging preserves the spawning agent's entry, spawning cannot be used to shed identity: a compromised instance that spawns sub-agents remains visible in every descendant chain.¶

The property this profile targets: every actor entry the AS introduces into a chain corresponds to an instance that presented Agent Instance Evidence at the hop where it was introduced. An AS MUST NOT introduce an actor entry for an agent instance that did not present such evidence. Inner actor entries preserved verbatim from a subject_token were attested at the hop (and by the AS) that introduced them; the attested-at-every-hop property therefore spans exactly the hops processed under this profile.¶

Chains that cross agent platforms or authorization servers (a sub-agent running on a different platform, under a different OAuth client, possibly at a different AS) compose through cross-domain token exchange and are governed by the trust and federation policy of the domains involved; this profile defines no additional cross-domain rules.¶

10. Refresh Tokens

Refresh-token handling follows [CIA-CORE], with the derived instance subject, the Agent Attester, and any surfaced provenance claims recorded as originating instance state. Fresh Agent Instance Evidence presented on refresh MUST be issued by the same Agent Attester and carry the same agent_instance_id recorded at original issuance; the AS MUST reject a refresh presenting evidence from a different Attester or for a different instance with invalid_grant. A refresh processed without fresh evidence re-surfaces the provenance recorded at original issuance; see Section 15.1 for the staleness this implies across refresh chains.¶

Refresh tokens remain bound to the binding key present at their issuance, per [CIA-CORE]; this profile does not relax that binding. An instance that rotates its binding key (for example, after migrating between nodes) therefore cannot use a previously issued refresh token with the new key; it obtains new tokens through a fresh grant or token exchange, presenting fresh evidence that carries its unchanged agent_instance_id. The instance's identity, and everything resource servers key on it, is unaffected by the rotation (Section 7).¶

11. Trust Model and Assurance Tiers

The strength of agent instance claims depends on who the Agent Attester is relative to the agent platform:¶

Platform self-attestation:

The Attester is the agent platform's own control plane. The claims reflect the platform's internal bookkeeping; assurance rests on organizational separation between the control plane and the agent runtime, comparable to a workload identity provider attesting its own workloads.¶

Hardware-rooted attestation:

The Attester incorporates evidence from a trusted-execution or confidential-computing environment (conveyed via agent_runtime, aligned with [RFC9711]). Claims about the runtime are rooted in hardware rather than platform assertion.¶

Independent attestation:

The Attester is a party distinct from the platform operator (for example, an enterprise attesting agent instances it runs on a third-party platform). Claims reflect a trust relationship independent of the platform.¶

Authorization servers and resource servers MAY condition policy on the tier. Deployments SHOULD document which tier their Attester provides and MUST NOT represent platform self-attestation as hardware-rooted or independent attestation.¶

12. Local and Public-Client Agent Instances

Agent instances do not necessarily run on platform infrastructure: command-line and desktop agents execute on end-user machines, typically as public clients ([RFC6749]) using the authorization_code grant with PKCE ([RFC7636]) and without a client-level credential. This profile applies to such deployments with the following pattern:¶

• The local agent instance generates its per-instance proof-of-possession key locally and authenticates to the agent platform's control plane (how is out of scope; typically the user's platform login). The control plane, acting as the Agent Attester, mints Agent Instance Evidence whose cnf binds the key the local instance presented and whose agent_instance_id names the local session.¶

• The instance presents the evidence at the token endpoint per the Client Instance Assertion carrier (Section 5.1) alongside its normal public-client interaction. Presenting a Client Instance Assertion does not require confidential-client authentication; only [CIA-CORE]'s instance-assertion authentication method does, and public clients do not use that method.¶

• The issued access token is sender-constrained to the locally held key per [CIA-CORE], and the instance subject, surfacing, and chain semantics of this profile apply unchanged.¶

Attestation of a local session is platform self-attestation (Section 11) with a narrower meaning: the Attester vouches that it issued the session to an authenticated platform account and bound the presented key, not for the integrity of the end-user host the instance runs on. Resource servers applying tier-conditioned policy SHOULD treat locally executing instances accordingly; deployments needing runtime-integrity claims for local instances can convey hardware-rooted evidence from the host via agent_runtime (Section 4) where available.¶

13. Error Responses

Errors are returned per [RFC6749] Section 5.2, inheriting the error taxonomy of [CIA-CORE] and, on the Client Attestation carrier, of [ATTEST-CLIENT-AUTH]. This profile adds the following invalid_grant cases (returned as invalid_client when, per [CIA-CORE], the evidence is the client authentication credential):¶

• a token request on a covered grant other than refresh_token presents no Agent Instance Evidence, and neither the client's registration nor AS policy exempts the grant type (Section 6);¶

• the Agent Instance Evidence omits agent_instance_id and the client is registered for this profile (Section 6);¶

• an object-valued agent claim is malformed (Section 4);¶

• on the Client Instance Assertion carrier, the assertion's sub does not equal agent_instance_id (Section 5.1);¶

• under carrier precedence, the binding keys or agent_instance_id values of the two artifacts do not match (Section 5.3);¶

• on refresh, presented evidence is issued by a different Agent Attester or carries a different agent_instance_id than recorded at original issuance (Section 10).¶

14. Conformance

An AS conforms to this profile by supporting at least one evidence carrier (Section 5); requiring evidence from registered clients per Section 6; validating the agent instance claims per Section 4; deriving the instance subject per Section 7; surfacing per Section 8, including the ai_agent and client_instance values in the surfaced sub_profile; applying the refresh rules of Section 10; applying carrier precedence (Section 5.3) when both artifacts are presented; and advertising support via ai_agent_instance_profile_supported (Section 6). An AS supporting the Client Instance Assertion carrier conforms to [CIA-CORE]; an AS supporting the Client Attestation carrier conforms to [ATTEST-CLIENT-AUTH] and to the activation-policy requirement of Section 5.2.¶

An Agent Attester conforms by meeting the minting requirements of Section 4 (in particular the uniqueness, stability, non-reassignment, and key-independence of agent_instance_id) and, per carrier, the obligations of a [CIA-CORE] instance issuer or an [ATTEST-CLIENT-AUTH] Client Attester.¶

An Agent Platform (OAuth client) conforms by registering for this profile (Section 6) and for exactly the carriers it uses, listing its Agent Attester per Section 5.1 where applicable, and ensuring the Attester is authorized to attest its instances.¶

A resource server conforms by processing delegated and self-acting tokens per [CIA-CORE]'s resource-server rules, treating actors whose sub_profile includes ai_agent as agent instances, and treating surfaced provenance claims subject to the assurance-tier considerations of Section 11 and Section 15.3.¶

15. Security Considerations

This document inherits the security considerations of [CIA-CORE] and, when the Client Attestation carrier is used, [ATTEST-CLIENT-AUTH] and [RFC9449].¶

16. IANA Considerations

17. References

Design Rationale

This appendix records design choices that motivated the normative text.¶

Worked Example: Agent Calling an MCP Server

Alice uses an AI assistant operated by an agent platform to triage issues in her project tracker. The tracker's API is fronted by a Model Context Protocol server ([MCP]) that acts as an OAuth resource server. The example uses the Client Instance Assertion carrier (Section 5.1); the Client Attestation carrier would convey the same claims with the flow otherwise unchanged.¶

Deployment:¶

• User: alice@example.com¶

• OAuth client (agent platform): https://agents.example.com/assistant¶

• Agent Attester (the platform's control plane): https://attester.agents.example.com¶

• AS: https://as.example.com¶

• MCP resource server: https://mcp.example.org (fronting the project tracker)¶

The platform's registered client metadata lists its control plane as a trusted instance issuer per [CIA-CORE]:¶

{
  "client_id": "https://agents.example.com/assistant",
  "jwks_uri": "https://agents.example.com/assistant/jwks.json",
  "token_endpoint_auth_method": "private_key_jwt",
  "ai_agent_instance_profile": true,
  "instance_issuers": [
    {
      "issuer": "https://attester.agents.example.com",
      "jwks_uri": "https://attester.agents.example.com/jwks.json",
      "subject_syntax": "uri"
    }
  ]
}

{
  "iss":       "https://attester.agents.example.com",
  "sub":
    "https://attester.agents.example.com/instances/sess-9f2c",
  "aud":       "https://as.example.com",
  "client_id": "https://agents.example.com/assistant",
  "sub_profile": "ai_agent",
  "agent_instance_id":
    "https://attester.agents.example.com/instances/sess-9f2c",
  "agent_platform": "urn:example:orchestrator:v5",
  "agent_model":
    { "id": "urn:example:model:atlas", "version": "7.3" },
  "iat": 1770000000,
  "exp": 1770000300,
  "jti": "ag-1a2b3c",
  "cnf": { "jkt": "0ZcOCORZNYy...iguA4I" }
}

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

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=...
&client_id=https%3A%2F%2Fagents.example.com%2Fassistant
&client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs...
&client_instance_assertion=eyJhbGciOiJFUzI1NiIs...

{
  "iss":       "https://as.example.com",
  "aud":       "https://mcp.example.org",
  "sub":       "alice@example.com",
  "client_id": "https://agents.example.com/assistant",
  "scope":     "projects.read issues.write",
  "iat":       1770000005,
  "exp":       1770001805,
  "cnf":       { "jkt": "0ZcOCORZNYy...iguA4I" },
  "act": {
    "iss":         "https://attester.agents.example.com",
    "sub":
      "https://attester.agents.example.com/instances/sess-9f2c",
    "sub_profile": "ai_agent client_instance",
    "agent_model":
      { "id": "urn:example:model:atlas", "version": "7.3" },
    "cnf":         { "jkt": "0ZcOCORZNYy...iguA4I" }
  }
}

{
  "iss":       "https://as.example.com",
  "aud":       "https://mcp.example.org",
  "sub":       "alice@example.com",
  "client_id": "https://agents.example.com/assistant",
  "scope":     "projects.read",
  "cnf":       { "jkt": "QrS...XyZ" },
  "act": {
    "iss":         "https://attester.agents.example.com",
    "sub":
      "https://attester.agents.example.com/instances/sess-a114",
    "sub_profile": "ai_agent client_instance",
    "agent_model":
      { "id": "urn:example:model:scout", "version": "2.0" },
    "cnf":         { "jkt": "QrS...XyZ" },
    "act": {
      "iss":         "https://attester.agents.example.com",
      "sub":
        "https://attester.agents.example.com/instances/sess-9f2c",
      "sub_profile": "ai_agent client_instance"
    }
  }
}

Document History

RFC EDITOR: please remove this section before publication.¶

Acknowledgments

The author thanks participants in the OAuth Working Group for discussions on client instance identity and agent identity that informed this document.¶

Author's Address