Client Instance Identification for Attestation-Based Client Authentication

1.1. Identity and Scope

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. [ATTEST] supplies the authentication and proof methods, including direct resource-server presentation (Section 7 of [ATTEST]). When selected under Section 3, this profile applies whether the Client Attestation is the client authentication method or an additional security signal (Section 7.6 of [ATTEST]). It does not replace the deployment's required client authentication.¶

3.1. 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 [ATTESTER-ENDORSEMENT]. [ATTESTER-ENDORSEMENT] applies only to authorization server endpoints (Section 2.3 of [ATTESTER-ENDORSEMENT]); a resource server validating attestations directly uses configured associations. A credential's iss claim, proof of possession, or client-published metadata ([RFC7591], [CIMD]) alone does not establish attester authority. Key resolution follows Section 10.8 of [ATTEST]. Local trust withdrawal MUST take effect on subsequent authentication.¶

3.2. Conformance

Conformance is role-specific:¶

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

4.1. 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 (Section 11.1 of [ATTEST]).¶

Scoping an identifier to a Receiver reveals that Receiver to the attester (Section 10.3). 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. Section 11.1 of [ATTEST] 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 Section 10.2.¶

In combined mode, the Client Instance Key is also the DPoP key. In normal mode, the DPoP key is independent of the attestation (Section 5.2 of [ATTEST]). 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 Section 10.2.¶

4.2. Example

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

{
  "iss": "https://attester.example/tenant/acme",
  "sub": "https://platform.example/oauth-client",
  "client_instance_id": "i-844a2aa37074eed77f3b3e950432f597",
  "iat": 1789128000,
  "exp": 1789128300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "VcKVNBZ4IaBAYW3jxM4w3TJFVA7myeUGQyGt-g_yvpQ",
      "y": "f-E-hYE3TAWKwhVv9pej9NABs9SX9XsNO80x57jFTyU"
    }
  }
}

5.1. Grant Continuity

Section 10.3 of [ATTEST] 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 Section 13 of [ATTEST] 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 Section 10.3 of [ATTEST], 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 [ATTEST], or a profile that has redefined refresh-token binding under Section 13 of [ATTEST].¶

3. MUST produce the invalid_grant error code (Section 5.2 of [RFC6749]) 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 (Section 7.6 of [ATTEST]). 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. Section 10.4 of [ATTEST] recommends establishing such bindings where attestation is the client authentication method.¶

5.2. Attestation Errors

If required instance claims are missing or invalid, or if the Receiver's local policy for the instance (Section 5) rejects the instance, the Receiver MUST produce the invalid_client_attestation error code. Section 7.4 of [ATTEST] 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 [ATTEST] specifies for the code (Section 5.2 of [RFC6749] at the authorization server, Section 3 of [RFC6750] 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 Section 5.1; other errors follow [ATTEST].¶

6.1. Identifier Generation

For each enrollment and Receiver Scope (Section 4.1), 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 [RFC2104], 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.¶

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

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 (Section 9.1). An identifier, expired attestation, or former public key alone does not establish continuity.¶

6.3. 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 [RFC7662]. 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 [RFC8417] delivered under [RFC8935], is outside the scope of this specification.¶

6.4. 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 (Section 7.2). Audit retention is local policy.¶

7.1. Format and Mapping

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

For direct issuance from a validated Client Attestation, context MUST identify the authenticated presenting instance; on refresh, that identity is subject to Section 5.1. Token exchange follows Section 7.4 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 Section 7.4, 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 Section 6.1, within the same length bound as the client_instance_id claim (Section 4), 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. Appendix A shows mapped context in an access token and an introspection response.¶

7.2. 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 Section 7.6.¶

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 Section 6.1 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:¶

7.3. 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 [RFC9449], mutual TLS [RFC8705], 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 (Section 7.5), 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 Section 7.6. The HTTP Bearer scheme does not indicate an unbound token; certificate-bound tokens [RFC8705] 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 (Section 7.1 of [RFC9449] and Section 7.2 of [RFC9449]). 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 (Section 10.2).¶

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

7.5. 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 Section 7.1 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 (Section 7.6).¶

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 (Section 7.1), and validating the token's sender constraint (Section 7.3) 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 Section 7.6.¶

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

7.6. 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 (Section 3.1 of [RFC6750]) or the invalid_request error code for a rejected subject or actor token in an exchange (Section 2.2.2 of [RFC8693]).¶

Retrying with a new access token (Section 3.1 of [RFC6750]) 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 Section 7.1 of [RFC9449], so that the client can determine the required binding mechanism.¶

Other consuming profiles define their own error mapping. Direct Client Attestation failures follow Section 5.2.¶

8.1. Client ID Metadata Documents

With [CIMD], 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:¶

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 (Appendix B.1). CIMD removes per-authorization-server registration of client metadata but not this profile's trust agreement (Section 3). [ATTESTER-ENDORSEMENT] allows a client to endorse attesters through client_attesters metadata (Section 3 of [ATTESTER-ENDORSEMENT]), 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.¶

8.2. Workload and Agent Credentials

A shared workload identity does not identify an individual instance; the attester requires instance-level evidence under Section 6.2. Direct SPIFFE Verifiable Identity Document (SVID) authentication and client mappings are defined by [SPIFFE-OAUTH]. An AAuth Agent Provider [AAUTH] 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 (Section 7.1). These boundaries are illustrated in Appendix B.¶

9.1. 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; Section 6.2 governs detected forks and does not guarantee clone detection. Instance identity proves no software integrity beyond the evaluated evidence.¶

9.2. 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 Section 6.2 requires after events such as a reinstall, or by presenting an attestation scoped to another Receiver, which the Receiver cannot detect (Section 4.1). Unless the Receiver requires prior enrollment (Section 5.2), such an instance is accepted as a new one. Suspension at the attester (Section 6.3) 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.¶

9.3. Forwarding

Forwarding resistance is provided by [ATTEST] 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.¶

10.1. Correlation Across Receivers

Separate identifiers and keys per Receiver Scope (Section 4.1) limit correlation, strengthening the protections of Section 11.1 of [ATTEST]. Receivers MUST NOT assume that identifiers are comparable across scopes; explicitly shared scopes permit correlation.¶

10.2. Token-Binding Keys

Per-consumer Instance Context Identifiers do not prevent correlation through a shared binding key. In DPoP combined mode (Section 5.2 of [ATTEST]), 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 (Section 5.1).¶

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 (Section 4.1), 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.¶

10.3. Attester Visibility

The attester learns any Receiver Scope the client supplies. Scoping an identifier to a Receiver (Section 4.1) therefore reveals that Receiver to the attester. This forgoes a property that [ATTEST] 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.¶

10.4. Error Disclosure

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

11.1. JSON Web Token Claims

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

11.2. OAuth Token Introspection Response

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

• Name: client_instance¶

• Description: Validated client instance context¶

• Change controller: IETF¶

• Specification document(s): Section 7 of this specification¶

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

12.1. Normative References

[ATTEST]

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

[RFC6749]

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

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

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

[RFC7662]

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

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

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

[BCP14]

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

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

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

12.2. Informative References

[AAUTH]

Hardt, D., "AAuth Protocol", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-11, 25 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11>.

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

[ATTESTER-ENDORSEMENT]

McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-00>.

[CIMD]

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

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/rfc/rfc2104>.

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

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[RFC8252]

Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/rfc/rfc8252>.

[RFC8417]

Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, <https://www.rfc-editor.org/rfc/rfc8417>.

[RFC8935]

Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, November 2020, <https://www.rfc-editor.org/rfc/rfc8935>.

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

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[SPIFFE-OAUTH]

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

A.1. Access Token Payload

The following example shows a decoded [RFC9068] 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 Section 4.2.¶

{
  "iss": "https://as.example",
  "sub": "user-17",
  "aud": "https://api.example",
  "client_id": "https://platform.example/oauth-client",
  "iat": 1789128000,
  "exp": 1789128300,
  "jti": "at-95a76b823",
  "scope": "documents.read",
  "cnf": {
    "jkt": "Ak20Cf62SpTybasujYXbaI-Ms655MyvOZCtnnf8y1QU"
  },
  "client_instance": {
    "iss": "https://as.example",
    "id": "m-95c9f383a07468578c0329a9a660740f"
  }
}

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

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

{
  "active": true,
  "iss": "https://as.example",
  "sub": "user-17",
  "aud": "https://api.example",
  "client_id": "https://platform.example/oauth-client",
  "scope": "documents.read",
  "exp": 1789128300,
  "cnf": {
    "jkt": "Ak20Cf62SpTybasujYXbaI-Ms655MyvOZCtnnf8y1QU"
  },
  "client_instance": {
    "iss": "https://as.example",
    "id": "m-95c9f383a07468578c0329a9a660740f"
  }
}

A.3. 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 [ACTOR-PROFILE] 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:¶

{
  "sub": "user-17",
  "aud": "https://api.example",
  "act": {
    "iss": "https://as.example",
    "sub": "agent-42"
  },
  "client_instance": {
    "iss": "https://as.example",
    "id": "m-a524d3cc4ba2df62c17f080e8779794d"
  }
}

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

A.4. Attestation Rejection

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

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_client_attestation"
}

B.1. CIMD Client

Let C1 be https://platform.example/oauth-client, whose CIMD declares attest_jwt_client_auth_dpop (Appendix A of [ATTESTER-ENDORSEMENT] 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 Appendix B.4.¶

B.2. 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 [RFC9421] 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.¶

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

B.4. 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 [RFC8252] with PKCE S256 [RFC7636], 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.¶