]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol OAuth client attestation instance identity This specification defines an optional claims profile of OAuth 2.0 Attestation-Based Client Authentication. When selected, the profile requires an attester-assigned client instance identifier, scoped by default to the server that validates it, that remains stable across verified key changes, and adds continuity and privacy rules for that identifier. Conveying instance context in tokens and introspection responses remains optional within the profile. Authentication and proof methods follow the base specification. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Attestation-Based Client Authentication answers one question: is this an authorized Client Instance in possession of this key? This profile adds a second: is this the same Client Instance the Receiver previously encountered? A new attestation alone cannot answer it: requires one for every new key, and after a key change a continuing installation is indistinguishable from a new one. This question arises in deployments where one Logical Client has many Client Instances, for example, an application on each managed laptop, a container per replica, or an agent runtime per host. Each instance presents a valid attestation for the same client_id and is distinguishable only by its current key. After an instance rotates that key, a Receiver cannot determine whether it is the instance the Receiver suspended or a new one, and audit history and status decisions tied to the old key do not carry over. This specification defines two claims:

• The client_instance_id claim allows a Receiver to recognize a Client Instance across key changes. Carried in the Client Attestation, it identifies one installation or runtime. The attester assigns it, retains it across verified key changes, and by default scopes it to one Receiver, which reveals that Receiver to the attester.
• The client_instance claim, or introspection response member, allows a resource server that does not receive the attestation to correlate requests with the instance validated at issuance. It carries a mapped reference to that instance in a token or introspection response.

This specification establishes instance identity and its continuity, not authority; instance evidence grants none. Authorization profiles can use validated instance identity or Instance Context as a policy input, subject to the prohibitions in . alone suffices when correlation is needed only for the current key. Assigning each instance its own client_id with a shared software_id client metadata value () is an alternative. This specification instead targets deployments that share one Logical Client, one metadata URL when using , and authorization server policy keyed by that client. The software_id value correlates registrations but defines no shared grants or policy across separate client identities. lists the five implementing roles and their requirements.

Identity and Scope

Identity	Purpose
Logical Client (client_id)	Identifies the OAuth client
Authorization principal	Identifies the subject or delegated actor
Client Instance	Identifies one installation or one execution of the client software

The deployment chooses the instance granularity:

• Installation: one installation, retaining its identity across process restarts.
• Execution: one unit the deployment names, such as a process, container, or Kubernetes Pod, retaining its identity for that unit's lifetime.

Enrollment records that choice. This specification addresses administratively configured deployments such as workloads and managed desktop or mobile applications. Its identifiers are not general-purpose device or wallet identifiers, and it does not define an enrollment, key-rotation, or status-distribution protocol. supplies the authentication and proof methods, including direct resource-server presentation (). When selected under , this profile applies whether the Client Attestation is the client authentication method or an additional security signal (). It does not replace the deployment's required client authentication.

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 () () when, and only when, they appear in all capitals, as shown here. The terms Client Attestation, Client Attester, Client Instance, and Client Instance Key are used as defined in .

Logical Client:

The OAuth client identified by client_id. Several Client Instances can authenticate as the same Logical Client.

Attester Issuer:

The iss claim value in the Client Attestation, which identifies the Client Attester.

Instance Identifier:

The client_instance_id claim value, which a Client Attester assigns to one Client Instance at the configured granularity and Receiver Scope ().

Source Instance Identity:

The pair (iss, client_instance_id) from a validated Client Attestation, that is, the Attester Issuer and the Instance Identifier. This specification keeps it stable across verified key changes, and Instance Context is mapped from it.

Instance Context:

The client_instance JSON object in a token or introspection response. It grants no authority and does not prove current possession.

Receiver:

A party that validates a Client Attestation under this profile, such as an authorization server or resource server. A Receiver that issues tokens carrying Instance Context is also a token issuer.

Context Consumer:

A party that consumes Instance Context from a token or introspection response. It need not receive the Client Attestation.

Receiver Scope:

The Receiver, or explicitly configured set of Receivers, to which one assignment of client_instance_id is scoped ().

Consumer Scope:

The Context Consumer, or explicitly configured set of Context Consumers, to which one mapping of Instance Context is scoped. A Consumer Scope is identified by a configured set of audience values ().

Instance Context Authority:

The token issuer identified by the iss member of Instance Context. It assigned the current id value and is the enclosing token's issuer unless the context was preserved from an upstream token. The Client Attester remains the authority for the Source Instance Identity.

Instance Context Identifier:

The pair (iss, id) in Instance Context. Like a pairwise subject identifier, it is the Instance Context Authority's own correlator for one Source Instance Identity within a Consumer Scope; its id need not equal client_instance_id.

Consuming profile:

A specification or deployment profile that defines how a Context Consumer, or an issuer conveying Instance Context through token exchange, establishes the association between Instance Context and the token's subject, actor, or presenter, and how the provenance of preserved context is authenticated (, ). This specification acts as the consuming profile only in the case described in .

enrollment:

An attester-maintained record binding one instance, at the configured granularity, to its verified keys and assigned identifiers, separate from any user account, device registration, or Logical Client.

Identifier values in this specification are opaque. Implementations MUST compare iss, client_instance_id, client_instance.iss, and client_instance.id as exact, case-sensitive strings without URI normalization, and MUST NOT derive permissions, granularity, or key locations by parsing them.

Profile Selection and Trust The client and Receiver administratively configure:

• the Logical Client, authentication method, and attester trust policy;
• the instance granularity, continuity evidence, and freshness limits;
• the intended Receiver and any explicitly shared Receiver Scope ().

A Context Consumer that requires context configures that requirement, including whether it extends to attribution, with the issuers it accepts context from. Claims MUST NOT select this profile or change authentication methods; selection is part of the client-specific trust agreement, and this profile adds no discovery or metadata parameter. The error in reports rejection, not profile discovery.

Attester Trust The Receiver MUST bind each approved Attester Issuer to its validation keys and authorized Logical Clients through configured associations. An authorization server can derive those associations from client endorsements it accepts, for example under . applies only to authorization server endpoints (); a resource server validating attestations directly uses configured associations. A credential's iss claim, proof of possession, or client-published metadata (, ) alone does not establish attester authority. Key resolution follows . Local trust withdrawal MUST take effect on subsequent authentication.

Conformance Conformance is role-specific:

Role	Implements	Where
Client Attester	Claim, identifier, continuity, and enrollment requirements	,
Client	Scoped attestation use, key separation, and the selected ATTEST proof method	, ,
Receiver	Trust, validation, grant-continuity, and revocation rules	, ,
Token issuer conveying context	Mapping, preservation, and any binding that attribution requires
Context Consumer	Context validation and applicable proof checks	, ,

An implementation serving several roles satisfies each. Conveying Instance Context () is optional and independent of the rest of this specification.

Client Attestation Claims This profile uses the additional claims permitted by . All requirements apply, including a typ JOSE header parameter value of oauth-client-attestation+jwt, sub equal to client_id, the required exp and cnf claims, and the optional iat claim.

iss:

REQUIRED. Exactly matches an approved Attester Issuer ().

client_instance_id:

REQUIRED. A nonempty JSON string, whose UTF-8 encoding is at most 256 octets after JSON string decoding, that identifies the instance within the attester's namespace. A URI-form value carries no URI semantics. Receivers MUST reject longer values. Assignment, scoping, and generation follow .

Receiver Scope A Receiver Scope is an enrollment or issuance input, not an OAuth parameter or attestation audience. A Receiver cannot verify it from the identifier alone. The attester MUST assign distinct identifiers per Receiver unless an administrative agreement explicitly authorizes a shared identifier within a named set of Receivers. A shared client or trust domain does not by itself authorize sharing. The client MUST request and use the attestation for that configured scope. A Receiver cannot detect an attestation presented outside its scope; the resulting correlation exposes the end user of that instance (). Scoping an identifier to a Receiver reveals that Receiver to the attester (). A deployment that needs the attester not to learn individual Receivers, or that intends correlation across them, configures one Receiver Scope spanning them; one identifier and key then suffice. The client MUST also use distinct Client Instance Keys across scopes. recommends this across authorization and resource servers; this profile requires it across the scopes a deployment chooses to separate, because a shared key links attestations regardless of their identifiers. Token-binding key separation between Context Consumers is addressed in . In combined mode, the Client Instance Key is also the DPoP key. In normal mode, the DPoP key is independent of the attestation (). A token issued in combined mode is bound to the authorization server's scoped key. A separately scoped resource server's attestation carries a different key. No single proof can match both, so combined mode cannot also be used at that resource server. Instead, a client authenticating in normal mode can present the resource-server-scoped key as its DPoP key at issuance. That allows combined mode at the resource server, at a correlation cost described in .

Example The following example shows a decoded Client Attestation payload with the optional iat claim:

Request Processing The Receiver MUST:

1. Validate the attestation and proof under the configured method.
2. Validate the claims in and attester authority under , including that the key that verified the attestation is bound to the asserted iss claim. Key resolution under selects a key from JOSE header parameters, not from iss, so a trust anchor covering several attesters does not by itself establish that association.
3. Associate the Source Instance Identity with the Logical Client and validated Client Instance Key, then apply the Receiver's local policy for that instance, such as suspension or required prior enrollment, reporting rejection under .

The Receiver MUST NOT:

• substitute an identifier for proof of possession or infer it from a key thumbprint, certificate serial number, or JWT jti claim;
• infer continuity from equal identifiers or keys across Attester Issuers; or
• set an access token's sub claim, add an act claim, or extend an actor chain solely from instance evidence.

Migration between Attester Issuers requires a procedure that establishes trust in both authorities and continuity evidence; this specification does not define one. Key selection follows ; when a separate token-binding key is used, context identifies the instance associated with the Client Instance Key.

Grant Continuity binds a refresh token to the Client Instance, by default through the Client Instance Key. The refresh token remains bound to that key; only a profile acting under can rebind it. This profile records an identity for the binding that persists across a verified key change, so later grants correlate with the same instance. It adds no instance-bound grants. Under the default binding, a refresh after a key change fails key-binding validation. With the original bound key, the identity check below detects an attestation that names a different instance; the check governs refresh across key changes only under a profile that rebinds refresh tokens. For a grant established using a Client Attestation validated under this profile, the authorization server MUST record the Source Instance Identity when issuing a refresh token. On refresh of such a grant, the authorization server:

1. MUST require a validated attestation, whether the attestation is the client authentication method or an additional security signal. This extends , which requires the attestation mechanism when refreshing.
2. MUST enforce two independent invariants:
   • the Source Instance Identity in the current validated attestation MUST match the recorded one; and
   • the proof and key binding MUST satisfy , or a profile that has redefined refresh-token binding under .
3. MUST produce the invalid_grant error code () for a conflict with the recorded identity, without disclosing the expected identity.

Instance continuity and key-binding continuity are independent. If authorization-time policy bound a code or other artifact to an instance, the authorization server MUST enforce that binding at redemption, whether the attestation is the client authentication method or an additional security signal (). Because presenting the attestation can be optional in that second mode, an authorization server that binds artifacts to instances MUST require it at their redemption; otherwise a conforming client cannot supply what the authorization server needs to check. recommends establishing such bindings where attestation is the client authentication method.

Attestation Errors If required instance claims are missing or invalid, or if the Receiver's local policy for the instance () rejects the instance, the Receiver MUST produce the invalid_client_attestation error code. defines that code for failures to verify the attestation or its proof. This profile extends it to instance claims and policy, so responses do not disclose whether an instance is unknown, suspended, or retired. Receivers SHOULD also avoid distinguishable response timing. Consequently, a client cannot distinguish a transient failure from a durable policy decision, or whether retrying with a fresh attestation will help. Responses use the format specifies for the code ( at the authorization server, at a resource server). Unknown instances are rejected only when local policy requires prior enrollment. If a profile check fails, the Receiver MUST NOT fall back to authentication without the required evidence. Grant-binding errors follow ; other errors follow .

Attester Requirements An Instance Identifier's meaning over time depends on the attester: how it generates identifiers (), when it may retain them (), how it handles suspension (), and what records it keeps ().

Identifier Generation For each enrollment and Receiver Scope (), the attester MUST assign identifiers that are:

• distinct, opaque, and never reassigned, including after retirement;
• generated from at least 128 bits of either cryptographically secure randomness or keyed pseudorandom-function output;
• unpredictable to parties other than the attester; and
• free of runtime hostnames, user identifiers, and embedded instance attributes.

A URI can name the attester's namespace; its instance-specific portion remains opaque. Keyed derivation, such as HMAC , MUST use a secret with at least 128 bits of entropy and unambiguously encode the Logical Client, Receiver Scope, and a unique enrollment component; a platform-stable input alone would reproduce retired identifiers after reinstall. If the attester changes its derivation inputs or secrets, it MUST still produce the values already assigned within a continuing enrollment. Storing the assigned values suffices.

Continuity and Lifecycle Continuity is authenticated evidence that shows the attester that a claimant is the same enrolled Client Instance at the configured granularity. An attester-recorded chain of verified key custody within one enrollment is the primary mechanism; platform or hardware-rooted identity evidence can supplement that chain or, where the deployment's evidence policy permits, replace it. Before retaining an identifier, the attester MUST verify and record:

1. an active enrollment binding the instance, Logical Client, Receiver Scope, granularity, and previously verified keys;
2. fresh possession of the current key and authenticated evidence binding it to that enrollment, including an authorized custody transition when the key changes; and
3. the configured continuity checks, their freshness, and observed lifecycle events or evidence of independent claimants.

The deployment specifies its evidence, freshness limits, and lifecycle boundaries. For example, when the unit is a Kubernetes Pod, a container restart keeps the identity, but a new Pod is a new unit. An identifier at Installation or Execution granularity does not identify individual processes within that installation or unit. The attester MUST apply the following outcomes:

Event	Required outcome
Renewal, verified key change, process restart at Installation granularity, or in-place update	Retain identifiers when continuity is verified
Reinstall, independent clone, replacement or restart of the unit at Execution granularity, or granularity change	Require new enrollment
Restore or snapshot rollback	Retain only with fresh evidence that the claimant succeeds the prior holder; copied keys and data alone are insufficient
Resume after suspension ()	Apply continuity checks at the next issuance using available authenticated evidence
Continuity cannot be established	Require new enrollment; a continuing original can retain its own enrollment
Detected fork of one enrollment	Retire the identifiers and enroll claimants separately, unless authenticated evidence shows which claimant continues the enrollment; that claimant keeps them

The attester MUST NOT knowingly retain identifiers for independent instances. Concurrent processes within one installation are not by themselves a fork. This prohibition covers detected forks, not events the platform cannot observe (). An identifier, expired attestation, or former public key alone does not establish continuity.

Suspension and Status The attester MUST stop issuance for suspended or retired enrollments. An authorization server that suspends an instance SHOULD revoke the instance's grants or report their tokens inactive through introspection . Short attestation lifetimes limit how long a suspended instance remains acceptable. When an authorization server revokes a grant for instance suspension, retirement, or attester trust withdrawal, it MUST revoke all of that grant's access and refresh tokens, report them inactive in introspection responses, and prevent further refresh issuance. Without a status channel, parties unaware of the change face three limitations: existing attestations may remain acceptable until expiration plus clock skew; issued tokens may still be accepted for their own lifetimes; and local revocation does not notify resource servers validating tokens offline. Status distribution, for example using Security Event Tokens delivered under , is outside the scope of this specification.

State and Retention Attesters MUST retain enrollment and verification records while issuing or renewing attestations, and status while supporting resumption. Verification summaries suffice. Deleting continuity records requires new enrollment. A validating Receiver need not keep an instance allowlist, but local suspension needs instance status, revocation needs token associations, and mapped context needs its mappings (). Audit retention is local policy.

Conveying Instance Context This section is optional. It defines how a token issuer represents a validated instance to downstream consumers () and what a consumer may conclude from it ().

Format and Mapping An issuer MAY include the client_instance claim in a token or the client_instance member in an introspection response . The client_instance value is a JSON object whose two REQUIRED members together form an Instance Context Identifier:

Member	Type	Meaning
iss	Nonempty string	Instance Context Authority that assigned id
id	Nonempty string, at most 256 octets of UTF-8 after JSON string decoding	That authority's representation of the instance

For direct issuance from a validated Client Attestation, context MUST identify the authenticated presenting instance; on refresh, that identity is subject to . Token exchange follows instead. Context MUST refer to validated instance participation; issuers MUST NOT copy unvalidated client-supplied context. The issuer MUST map its mapping input (the Source Instance Identity or, when remapping under , the upstream Instance Context Identifier) into its own namespace. Each mapping MUST:

• keep distinct instances separate unless continuity is established;
• generate the id value under , within the same length bound as the client_instance_id claim (), and retain it across attestation renewal and verified key changes; and
• scope the id value to a Consumer Scope, allowing sharing only within an explicitly configured set.

Each Consumer Scope is identified by a configured set of audience values. The issuer selects the mapping by the token's audience: its aud claim or, for an opaque token, the audience recorded at issuance. If a token has no audience, or its audiences span Consumer Scopes, no single id value is correct, and the issuer MUST omit the client_instance object. An introspection response conveys the id the token would carry. When the authenticated introspection caller is outside the token's Consumer Scope, the issuer MUST omit the client_instance object. For derived mappings, the mapping input supplies the enrollment-specific component and the consumer supplies the scope. Issuers MUST separate this derivation from attester identifiers, for example by a distinct key or purpose label. shows mapped context in an access token and an introspection response.

Mapping Stability For one mapping input and Consumer Scope, an issuer:

• MUST NOT represent that input by more than one id;
• MUST retain the mapping while any token or grant it issued for that input remains valid, including clock skew; and
• MUST omit the client_instance object rather than assign a replacement once it no longer holds or can reproduce the mapping. A Context Consumer requiring context then rejects the request as specified in .

An issuer that changes its derivation inputs or secrets MUST still produce the identifiers already assigned for any input and scope for which it continues to include context, as requires of attesters. Storing those values suffices. Otherwise, rotating one secret would silently and permanently remove context from every instance mapped under it. Attester identifiers are never reassigned, so a new enrollment presents a new mapping input and receives a new mapping. Storage requirements differ by mapping strategy:

Strategy	Records needed	Non-reassignment depends on
Derived	None per instance, while the derivation secret and inputs remain available ()	Never reusing enrollment inputs
Random	Retained for as long as the issuer intends to include context	Probability

Presenter Attribution Instance Context grants no authority. Alone, it describes only the instance that participated in obtaining the token. When a Context Consumer uses context to attribute the current token presentation to that instance, the applicable consuming profile MUST require a mechanism associating the token presenter with the instance. A Context Consumer attributing a presentation this way MUST validate that mechanism. For tokens issued directly from a validated Client Attestation, the mechanism is sender constraint: DPoP , mutual TLS , or another mechanism the consuming profile defines, using a key the issuer associated with the authenticated instance at issuance. For presenter attribution, the client MUST use a constraining key unique to the instance at the configured granularity. A key shared by instances within that boundary establishes no attribution, because any of them can present the token and satisfy the proof. Where the configured requirement for a Consumer Scope includes attribution, an issuer that cannot bind such a key MUST omit the client_instance object. Context conveyed without such a key indicates only participation (), including when it is conveyed only through introspection. A token without sender constraint supports no presenter attribution, and a Context Consumer requiring attribution rejects the request as specified in . The HTTP Bearer scheme does not indicate an unbound token; certificate-bound tokens also use it. All validation requirements of the token-binding mechanism apply whether or not context is used for attribution, including rejection of a bound token presented without its proof ( and ). The binding authenticates the presenter; it does not establish that the presenter is the instance named in context derived from an upstream token. Any presenter or key change during exchange requires authorization under the consuming profile. Unlinkability between Context Consumers also requires distinct token-binding keys ().

Preservation and Authorization An exchange issuing Instance Context MUST use a consuming profile that defines:

• whether context identifies the authenticated presenting instance or an instance represented by validated input-token context;
• how its association with the subject, actor, or presenter is validated;
• when input context is remapped or preserved; and
• refresh binding and context continuity, if the exchange issues refresh tokens.

Issuers SHOULD remap upstream context into their own namespace, which keeps each consumer's view pairwise. An issuer MAY instead preserve a validated upstream Instance Context Identifier when configured trust and the upstream Consumer Scope authorize its disclosure downstream; otherwise it MUST remap or omit the context. An issuer MUST NOT name an upstream Instance Context Authority in the iss member unless it has authenticated:

1. that the named authority assigned the context; and
2. that the context refers to the instance the input token represents.

Validating the input token authenticates only its issuer's assertions. By default, therefore, an issuer MUST limit preservation to context whose iss member equals the authenticated input-token issuer, and MUST remap or omit context that an intermediary itself preserved. A consuming profile that specifies authenticated provenance and its enforcement can permit deeper preservation; the object carries no forwarding history, and shallow preservation is also a privacy default. Context identifies one instance, not a chain, and MUST NOT be treated as a separate token or delegated actor. Remapping changes the Instance Context Identifier; like preservation, it leaves the represented Source Instance Identity unchanged. An issuer MUST NOT treat upstream context as identifying a different presenting instance. The upstream identifier does not establish that the issuer validated the original Client Attestation.

Context Consumer Processing Before using context, the Context Consumer MUST perform these steps:

1. Validate the enclosing token or authenticated introspection response.
2. Validate the context members, treating an id value that exceeds the length bound in as invalid and ignoring unrecognized members.
3. Accept the Instance Context Authority only if it is the token issuer or an upstream token issuer explicitly trusted for that issuer and consumer.
4. Discard invalid context. If context is required and is missing or was discarded, reject the request ().

Before using the context's association with the subject, actor, or presenter in policy or audit, a Context Consumer MUST establish that association from the applicable consuming profile and the validated token or trusted introspection configuration. If the issuer might have preserved context from an input token, the association is established only if that profile also defines how the context's provenance is authenticated, because the object does not record how the issuer obtained it. The client_instance object alone, including whether its iss member matches the token issuer, establishes neither the association nor the provenance. When trusted configuration establishes that the token issuer conveys context only from direct Client Attestation validation, this specification is the consuming profile. Context then identifies the authenticated presenting instance (), and validating the token's sender constraint () establishes the association. That configuration describes the issuer, not the token, so it does not apply at an issuer that also preserves context from input tokens. There, only a consuming profile carrying provenance can distinguish directly validated context from preserved context. If the association is not established, the Context Consumer MUST treat context only as evidence of instance participation and MUST NOT attribute the current request to that instance. In this case, a Context Consumer whose configured requirement includes attribution MUST reject the request as specified in . An issuer whose trust agreement with a Context Consumer states that it conveys context only from direct Client Attestation validation MUST NOT convey to that consumer Instance Context derived from anything other than a Client Attestation it validated for the issuing request. For introspection, trusted endpoint configuration identifies the expected token issuer. If present, a top-level iss member MUST match that issuer; neither the endpoint URL nor the client_instance.iss member selects the issuer. Multi-issuer introspection requires a consuming profile that authenticates the represented issuer. The iss value does not authorize fetching keys from that location, and extensions MUST NOT change the meaning of the iss or id member.

Context Errors When required context is missing or invalid, or required attribution cannot be established, the rejection MUST use the invalid_token error code at a resource server () or the invalid_request error code for a rejected subject or actor token in an exchange (). Retrying with a new access token () does not resolve a rejection for a missing sender constraint. When a resource server rejects a request for that reason, it SHOULD include the challenge for the binding mechanism it requires, such as the DPoP scheme in , so that the client can determine the required binding mechanism. Other consuming profiles define their own error mapping. Direct Client Attestation failures follow .

Relationship to Other Identity Systems This section compares this profile with client, workload, and agent identity mechanisms; it adds no requirements.

Client ID Metadata Documents With , the metadata URL is the Logical Client's client_id, and many installations can use it. Retrieving public metadata does not prove that a caller is an authorized instance:

Mechanism	Contribution
CIMD	Discovers Logical Client metadata and its authentication method
ATTEST	Authenticates an attester-approved instance and possession of its key
This profile	Retains instance identity across verified key changes and conveys optional downstream context

One CIMD URL describes the Logical Client, and Instance Identifiers belong in attestations, not per-installation metadata. The attestation's sub claim is that URL, and the client_instance_id claim distinguishes installations (). CIMD removes per-authorization-server registration of client metadata but not this profile's trust agreement (). allows a client to endorse attesters through client_attesters metadata (), subject to authorization server policy. That endorsement establishes the attester-to-client association but does not select this profile or its continuity and privacy policy.

Workload and Agent Credentials A shared workload identity does not identify an individual instance; the attester requires instance-level evidence under . Direct SPIFFE Verifiable Identity Document (SVID) authentication and client mappings are defined by . An AAuth Agent Provider or workload attester can instead issue a Client Attestation under this profile when it holds the required enrollment evidence. Native credentials with different sub or typ semantics require a separate carrier profile. A deployment authenticating only with them conveys no Instance Context under this profile, which maps context only from a validated Client Attestation (). These boundaries are illustrated in .

Security Considerations The security considerations of and apply.

Attester Compromise and Assurance A compromised attester can impersonate instances within its approved client associations. Receivers limit those associations and configure acceptable evidence assurance. An attester that overstates the assurance of its evidence defeats that configuration. Self-reported, platform-verified, and hardware-rooted evidence are not interchangeable. Without independent platform evidence, copied keys and enrollment data can be indistinguishable from the original; governs detected forks and does not guarantee clone detection. Instance identity proves no software integrity beyond the evaluated evidence.

Suspension and Re-enrollment Suspension at a Receiver applies to the Source Instance Identity that Receiver recorded. An instance can appear under a different identity by re-enrolling, which requires after events such as a reinstall, or by presenting an attestation scoped to another Receiver, which the Receiver cannot detect (). Unless the Receiver requires prior enrollment (), such an instance is accepted as a new one. Suspension at the attester () stops issuance only for the suspended enrollment: it does not prevent a replacement enrollment unless the attester also controls admission of new enrollments for that installation, and attestations issued before the suspension remain usable until they expire. A Receiver that relies on suspension for containment therefore requires prior enrollment, or coordinates with the attester both suspension and admission control for replacement enrollments, and accepts the window set by outstanding attestation lifetimes.

Forwarding Forwarding resistance is provided by proof validation, freshness, and key possession, not by identifier scope. The Client Attestation has no audience; its proof-of-possession JWT identifies the Receiver, and combined DPoP binds the HTTP request.

Privacy Considerations The privacy considerations of apply.

Correlation Across Receivers Separate identifiers and keys per Receiver Scope () limit correlation, strengthening the protections of . Receivers MUST NOT assume that identifiers are comparable across scopes; explicitly shared scopes permit correlation.

Token-Binding Keys Per-consumer Instance Context Identifiers do not prevent correlation through a shared binding key. In DPoP combined mode (), the Client Instance Key is the DPoP key, so tokens for different Context Consumers can carry different id values but the same cnf.jkt. When unlinkability between Context Consumers is required, the client MUST use distinct token-binding keys across those scopes, for example, DPoP without combined mode or a distinct mutual-TLS certificate and key pair per scope. Other claims and application data can also correlate requests. Identifier scoping does not permit changing a refresh token's bound key (). The same applies between an authorization server and a resource server. A client that authenticates to the authorization server in normal mode and presents a resource-server-scoped key as its DPoP key, so that it can use combined mode at that resource server (), also exposes that key to the authorization server. The two Receivers can then correlate through its thumbprint, even though their identifiers and Client Instance Keys differ.

Attester Visibility The attester learns any Receiver Scope the client supplies. Scoping an identifier to a Receiver () therefore reveals that Receiver to the attester. This forgoes a property that states in its abstract: the client proves its authenticity without revealing its target audience to the attester. This profile trades attester visibility for unlinkability between Receivers. A single Receiver Scope spanning every Receiver the client uses limits what the attester learns to that scope, at the cost of allowing those Receivers to correlate the instance.

Error Disclosure Error responses SHOULD NOT reveal unrelated instance identities. governs status non-disclosure; and govern retention. Unpredictable identifiers limit guessing and enumeration but are not authentication.

IANA Considerations

JSON Web Token Claims This specification requests registration of the following values in the "JSON Web Token Claims" registry established by .

Claim Name	Claim Description	Change Controller	Specification Document(s)
client_instance_id	Attester-qualified client instance identifier	IETF	of this specification
client_instance	Validated client instance context	IETF	of this specification

OAuth Token Introspection Response This specification requests registration of the following value in the "OAuth Token Introspection Response" registry established by :

• Name: client_instance
• Description: Validated client instance context
• Change controller: IETF
• Specification document(s): of this specification

These registrations define claims and a response member, not subject or actor profile values.

References Normative References MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Hellō This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports five resource access modes — agent identity, resource- managed (two-party), person identity, PS authorization (three-party), and federated authorization (four-party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. Independent OAuth deployments increasingly involve agents and workloads acting on behalf of human users across organizational boundaries. Existing specifications provide relevant building blocks (notably the act claim from RFC 8693 Token Exchange) but do not define a consistent profile for representing delegated actor relationships across JWT assertion grants (RFC 7523), JWT access tokens (RFC 9068), and Transaction Tokens, nor for classifying actor entity types or signaling support between authorization servers and resource servers. The result is inconsistent actor representation and actor- representation interoperability gaps that force deployments to rely on proprietary conventions. This document defines the OAuth Actor Profile for Delegation. It specifies a common act claim structure extended with sub_profile for entity-type classification, processing rules for authorization servers and resource servers across the three token families and their Token Exchange inputs, and OAuth discovery metadata parameters for advertising actor-profile support. The profile applies uniformly across token types and integrates with existing sender-constraint mechanisms (DPoP, mTLS). It does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject; those decisions remain deployment-specific. Independent OAuth 2.0 Attestation-Based Client Authentication requires an authorization server to trust the attester that makes statements about a client instance, but does not define how a client identifies the attesters authorized to attest for it. This specification defines a client metadata parameter, usable by registered clients and in Client ID Metadata Documents, that names the endorsed attesters and the locations of their verification keys. It defines how an authorization server validates endorsements and processes their withdrawal while retaining control over whether to trust them. It introduces no new credential or client authentication method. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Defakto Security Defakto Security NIST IBM Cisco Systems This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets.

Wire Examples These examples are informative. The first two use the managed-device flow (): the user is the authorization subject, and the installation appears as Instance Context. The authorization server maps the attester's identifier to a value scoped to https://api.example.

Access Token Payload The following example shows a decoded access token payload; its JOSE header contains a typ value of at+jwt. The jkt member of the cnf claim identifies the public key in .

Introspection Response The following example shows an authenticated introspection response conveying the same context for an opaque access token. The resource server has configured this endpoint as authoritative for https://as.example. The top-level iss member names the token issuer, and the nested iss member names the Instance Context Authority; here they are the same authorization server.

Governed Actor and Instance Context A consuming profile can authorize instance B to continue work that instance A began for the same governed agent. Here that profile authorizes agent-42 to act for user-17 under and selects the authenticated presenting instance for output context. The authorization server validates B's attestation and proof, replaces A's input context with B's mapping for the resource server's Consumer Scope, and binds the output token under the consuming profile. The following example shows the relevant output claims: The governed actor remains agent-42; the mapped identifier is B's. Neither B's authentication nor continuity of the agent identity alone authorizes this exchange. A profile that instead preserved A's context would have to define that upstream association explicitly.

Attestation Rejection The following example shows a token endpoint response when a required instance claim is missing or local policy rejects the instance (). It does not reveal whether the instance is unknown, suspended, or retired.

Deployment Examples The following informative examples share three steps. C1 is the Logical Client; I1 and K1 are an Instance Identifier and key scoped to the authorization server.

1. The attester verifies enrollment evidence and possession of K1, then issues the attestation in : iss naming the attester, sub=C1, client_instance_id=I1, and cnf.jwk holding public key K1.
2. The client presents its grant, attestation, and combined DPoP proof using K1 at the authorization server token endpoint.
3. The authorization server validates them and issues a DPoP-bound token with mapped context M1, scoped to the resource. The resource server validates the token, proof, and context without seeing the enrollment evidence.

CIMD Client Let C1 be https://platform.example/oauth-client, whose CIMD declares attest_jwt_client_auth_dpop ( has a metadata example). The authorization server validates the CIMD and trusts the attester through configuration or an accepted client_attesters endorsement. Key renewal does not change the CIMD. User-authorized access follows .

AAuth Agent Provider At step 1, the Agent Provider verifies managed installation evidence and issues a Client Attestation. Native aa-agent+jwt credentials and HTTP Message Signatures do not replace the attestation or the proof. Step 2 uses a pre-authorized client credentials grant; AAuth metadata alone does not establish attester trust.

SPIFFE Workload At step 1, the workload uses an X.509-SVID from the Workload API for mutual TLS. The attester validates its trust domain and runtime evidence binding this container to K1; a shared SPIFFE ID cannot distinguish replicas. Step 2 uses client credentials with the resulting attestation. With the container as the Execution unit, a restart requires new enrollment; SVID renewal within a continuing container does not.

Managed Device At step 1, a management component verifies the installed client and its platform-protected K1, using app-attestation evidence where available. Device enrollment or key storage alone does not identify the installation. Before step 2, the client obtains a code through an external browser with PKCE S256 , then redeems it with the code verifier, redirect URI, C1, attestation, and DPoP proof. The browser receives neither attestation nor proof. Process restarts can retain the installation identity; reinstallation requires new enrollment.

Document History RFC EDITOR: Remove this section before publication. -00

• Initial version. Replaces draft-mcguinness-oauth-client-instance-assertion-01. Instead of a separate Client Instance Assertion carried in the client_instance_assertion request parameter, instance identity is carried in the Client Attestation of as the client_instance_id claim, with optional Instance Context conveyed downstream as the client_instance claim.