OAuth 2.0 Client Attester Endorsement

2.1. Acceptance Policy

For requests governed by this profile, the authorization server MUST accept a Client Attestation only when both of the following hold:¶

1. Client endorsement: the authoritative metadata for the requested client_id currently endorses the attestation's issuer (Section 3).¶

2. Authorization server attester acceptance: authorization server policy permits that attester for that client and determines how the attester's verification keys are trusted (Section 5.3).¶

Endorsement alone does not make an attester trusted, and authorization server trust in an attester alone does not authorize it for a client. Authorization server policy can narrow the endorsed set, and authorizing a publisher to select keys permits each attester that publisher endorses, subject to Section 5.3. Authorization server policy MUST NOT add an unendorsed attester or accept an attestation through another attester-trust mechanism. Where the attestation is optional, proceeding on a companion client authentication method without it (Section 5.4) is not such a fallback. An endorsement does not by itself establish that the client is trusted or authorized to access a resource.¶

This specification defines two key-trust policies, and authorization server policy determines which one applies. The policy cannot be chosen independently for each association: AS-configured attester trust is keyed by the exact issuer string and, once configured for any client, governs that issuer string for every client. Publisher-authorized key selection is keyed by the client publisher and requires no per-attester configuration. The two policies are defined as follows; Section 5.3 specifies the procedure that selects between them:¶

• Publisher-authorized key selection: the authorization server authorizes the publisher of specified clients to select both the attester and its key source, so the endorsed jwks_uri supplies the keys. For CIMD clients, the authorization server configures exact client URLs or HTTPS origins, optionally restricted to a path prefix. A prefix matches only at a / segment boundary. A client URL whose path contains \, ;, or a percent-encoded /, \, or . matches no prefix, because a server can decode or route such a path to a different document than the one compared. Client identifier comparison itself remains exact. A path prefix is a publisher boundary only where the host serves each path under it from the publisher it names; shared hosting requires such a boundary. Successful metadata retrieval does not establish this authorization. For a registered client, the publisher is the party authorized to set endorsements under Section 2.2, and the authorization server configures whether that party's endorsements select keys.¶

• AS-configured attester trust: the authorization server independently trusts a particular attester and configures its key source. The endorsement authorizes that attester to attest for the client; it cannot supply the trust anchor (Section 5.3).¶

Publisher-authorized key selection serves deployments in which per-attester configuration is impractical: an authorization server serving many CIMD clients, each published by a different operator and attested by that operator's own platform attester, would otherwise need a configured entry for every attester of every client before any of them could authenticate.¶

When combined with [INSTANCE-ID], the same two conditions establish attester authority; instance continuity remains independent.¶

2.2. Registered Endorsements

Registered endorsements MUST originate from a party authenticated and authorized to set them for that client, or be covered by a validated software statement from an issuer approved for that purpose under [RFC7591]. Open registration alone provides neither assurance; issuing a client credential does not retroactively approve its endorsements. The same restriction applies to endorsement updates, including updates made through the registration management protocol [RFC7592]. Possession of a registration access token establishes control of the registration, not authority to endorse, and MUST NOT by itself authorize setting or replacing client_attesters. Removing the parameter, including by omitting it from an update that [RFC7592] treats as a deletion request, is treated as replacing it.¶

An authorization server that does not accept a submitted value or removal of client_attesters MUST either reject the request with the invalid_client_metadata error code (Section 3.2.2 of [RFC7591]) or keep the previously stored value, if any, instead of the submitted one, as Section 2.2 of [RFC7592] permits for an ignored value. The client information response (Section 3.2.1 of [RFC7591]) then never contains an endorsement the authorization server has not accepted, and an unauthorized request never removes a stored endorsement.¶

2.3. Applicability and Scope

Authorization server policy, which can be scoped per client, determines whether this profile applies to a request; this out-of-band determination satisfies Section 13 of [ATTEST]. The presence or absence of client_attesters does not determine whether this profile applies, and publishing it does not require an authorization server to apply this profile. This profile is independent of how an authorization server processes unrecognized metadata in a CIMD, which [CIMD] leaves unspecified. An authorization server advertises the capability with the client_attester_endorsement_supported metadata parameter (Section 4). Because that parameter applies to the authorization server as a whole, deployments relying on endorsement enforcement establish through a trust agreement that the authorization server applies this profile to their clients. A trust agreement is the out-of-band arrangement between the authorization server operator and the client publisher or attester operator that fixes which policies the authorization server applies.¶

This profile applies at authorization server endpoints that accept Client Attestations for client authentication or as an additional security signal: typically the token endpoint, the pushed authorization request endpoint [RFC9126], the device authorization endpoint [RFC8628], and the introspection [RFC7662] and revocation [RFC7009] endpoints. The authorization endpoint does not authenticate clients and is outside the scope of this specification. A party authenticating at any of these endpoints acts as a client, including a resource server presenting a Client Attestation to the introspection endpoint. Where a flow authenticates more than once, each presentation is evaluated on its own under Section 5.2. This profile retains the wire format, proof methods, and token binding of ATTEST.¶

A resource server that accepts a Client Attestation presented to it (Section 7.6 of [ATTEST]) relies on configured attester trust; this profile does not define endorsement discovery or acceptance there. This keeps client metadata resolution and endorsement policy at the authorization server rather than at each resource server. As a consequence, withdrawing an endorsement (Section 6) has no effect at a resource server that validates attestations directly.¶

The authorization server conveys its decision through the artifacts it issues, not through endorsement data, and what they carry depends on the deployment's token-binding method. In the combined mode defined in Section 5.2 of [ATTEST], the Demonstrating Proof of Possession (DPoP) key [RFC9449] and the attested Client Instance Key are one key, so the issued token's confirmation claim names the attested key. Where DPoP is used alongside a separate Client Attestation proof, that section does not require the DPoP key to match the key in the cnf claim of the attestation, and the token is bound to the DPoP key instead. In both cases, a confirmation claim reports a key binding, not an endorsement decision, and introspection [RFC7662] reports the token's state, not how the authorization server evaluated the endorsement. Neither indicates to a resource server whether an endorsement was accepted; endorsement policy therefore remains at the authorization server.¶

2.4. Conformance

Conformance requirements depend on the role:¶

• Client publishers publish and maintain client_attesters under Section 3, and withdraw an endorsement by updating that metadata (Section 6).¶

• Client Attesters and clients implement their issuance and presentation requirements in Section 5.¶

• Authorization servers implement key-trust policy selection, metadata and key validation, processing, and withdrawal, and can advertise support under Section 4.¶

An implementation serving several roles satisfies each role's requirements. Instance identification is optional.¶

5.1. Issuance and Presentation

Requests under this profile MUST include the client_id parameter to select the client metadata; that parameter alone does not authenticate the client.¶

This narrows Section 7.1 of [ATTEST], which compares client_id with the sub claim only when the request includes it. This profile selects the client metadata from the client_id parameter rather than from the sub claim, and step 4 of Section 5.2 then requires the two to be equal. When this profile applies to a request that omits client_id, the authorization server MUST reject the request with the invalid_request error code (Section 5.2 of [RFC6749]).¶

The Client Attester MUST establish that the requesting Client Instance is authorized to obtain a Client Attestation naming the specified client_id. The attester MUST NOT treat knowledge of the client_id or possession of a newly generated key, alone or together, as sufficient. How the attester establishes this authorization is outside the scope of this specification.¶

The attester MUST include the following in the Client Attestation:¶

• the iss claim, containing its endorsed issuer value;¶

• the sub claim, containing the exact client identifier; and¶

• the kid JOSE header parameter [RFC7515], containing a nonempty value that identifies its signing key.¶

Section 4 of [ATTEST] does not require the iss claim. This profile requires it because a client can endorse several Client Attesters with independent key sets: the issuer selects the endorsement and key source before the kid value is resolved, and a kid value identifies a key within a JWK Set, not a Client Attester or a trust relationship.¶

This profile retains, without relaxation, the default requirement of Section 7.5 of [ATTEST] that the client_id parameter equal the sub claim, so an endorsement for one client cannot validate an attestation naming another. Other claims and proof requirements follow [ATTEST].¶

5.2. Authorization Server Processing

For each presentation, the authorization server MUST:¶

1. Before evaluating endorsements, select the authoritative metadata source for the requested client_id using authorization server registration or discovery policy. Obtain metadata from that source or a fresh cache, following the resolution and validation rules of [CIMD] or registered metadata policy, including Section 2.2. The authorization server MUST NOT combine endorsement lists from different sources or switch sources because endorsement validation fails. A client identifier with both a registration and a reachable CIMD is resolved from the single source this step selects; an endorsement validation failure from that source is final.¶

2. Validate client_attesters and select the entry whose issuer member exactly matches the nonempty iss claim of the attestation; because an issuer occurs at most once in the array (Section 3), the selection is unique. Verify that authorization server policy permits that client-to-attester association; selecting an entry does not by itself authorize it. Policy evaluates the selected entry, including its jwks_uri, not the issuer alone. Agreement between that jwks_uri and a configured key source is checked in step 3 (Section 5.3), not here.¶

3. Select the key source under Section 5.3. Resolve the kid header parameter to one eligible public key, refreshing on an unknown kid value only as Section 6 permits, and verify the signature using an acceptable asymmetric algorithm. Symmetric keys, private keys, and an alg header parameter value of none MUST NOT be accepted under this profile.¶

4. Verify that the sub claim exactly equals the requested client_id, then validate the remaining attestation and proof under the selected ATTEST method. When the attestation is an additional security signal alongside another client authentication method (Section 7.6 of [ATTEST]), validate that method under its own specification and verify that it authenticates the same client identifier; a mismatch is a failure of that method. Where the companion method also establishes a confirmation key, for example mutual TLS [RFC8705], authorization server configuration selects which key binds the issued token; the authorization server MUST NOT bind a token to the attested key on the basis of an attestation it did not accept.¶

5. Apply grant and authorization policy independently of the endorsement.¶

5.3. Key Source Selection

The authorization server MUST select keys according to the key-trust policy governing the client-to-attester association (Section 2). If the authorization server has configured attester trust for the attestation's exact issuer string for any client, AS-configured attester trust governs that issuer for every client, even if the requesting client's publisher is also authorized to select keys. Otherwise, publisher-authorized key selection applies if the publisher is so authorized. If neither applies, no key source is available and endorsement validation fails.¶

After a configured entry is removed, the authorization server MUST NOT verify an attestation under that issuer with publisher-selected keys unless an operator has since decided that publishers may select keys for that issuer; otherwise, removing a configured entry would transfer key selection to the publisher. Restoring a configured key source for the issuer returns it to AS-configured attester trust. Until one of these occurs, no key source is available and endorsement validation fails.¶

• AS-configured attester trust: use only the independently configured key source for the exact issuer; no origin relationship between that source and the issuer is required. The endorsed jwks_uri MUST equal that source's URI or one of its configured aliases. This check causes a disagreement between the endorsement and authorization server configuration, including endorsement of a different key set behind a shared issuer string, to fail validation instead of being resolved in favor of either. An alias is an endorsed URI that the authorization server treats as equivalent to the issuer's configured key source; it does not change where keys are retrieved. Aliases are issuer-wide: an alias applies to every client that endorses the issuer, not only the client whose endorsement prompted it. A configured alias MUST preserve the endorsed attestation authority, including tenant scope; a shared issuer or origin alone does not establish equivalence, and tenant isolation (Section 7) depends on this. An endorsed jwks_uri MUST NOT select, override, or provide a fallback for the configured key source. The authorization server MUST NOT retrieve the endorsed jwks_uri under this policy; the endorsed value is compared but never retrieved.¶

• Publisher-authorized key selection: use the endorsed jwks_uri. The issuer value MUST be an HTTPS URL, and the jwks_uri value MUST have the same origin [RFC6454]. This origin check neither isolates tenants sharing an origin nor establishes trust in an issuer name. A non-HTTPS issuer has no HTTPS origin binding and so requires AS-configured attester trust.¶

Configuring or changing trust for an issuer can affect every client that endorses that issuer. Before applying such a change, operators should evaluate existing endorsements for compatibility with the configured key source. Configured aliases represent equivalent attestation authority and cannot be used solely to accommodate different tenant key sets.¶

The authorization server MUST use exact, case-sensitive string comparison, without URI normalization, for issuer identifiers, for client identifiers, and when comparing endorsed jwks_uri values with configured source URIs and aliases. An alternative spelling of a location requires an explicit alias, and origin comparison does not change identifier comparison.¶

Key selection MUST bind a key to the client identifier, issuer, selected key source, and applicable key-trust policy, so that a key selected under one entry never verifies an attestation evaluated under another; a kid value alone or a union of keys from different entries is insufficient. The binding applies when a key is selected, not when it is retrieved, so a shared HTTP cache keyed by JWK Set URL is compatible with it. The authorization server MUST ignore the jku, x5u, x5c, and jwk JOSE header parameters for key selection under this profile and MUST resolve only the kid header parameter against the selected source.¶

A key is eligible when all of the following hold:¶

• it is the only key in the selected JWK Set whose kid parameter equals the kid header parameter by octet comparison;¶

• it is an asymmetric public key whose key type is consistent with the alg header parameter;¶

• its use parameter, if present, is sig or, under AS-configured attester trust, a value the authorization server has configured for that key source as identifying signature keys (for example jwt-svid for a SPIFFE trust bundle [SPIFFE-OAUTH]);¶

• its key_ops parameter, if present, includes verify; and¶

• its alg parameter, if present, equals the alg header parameter.¶

If more than one key matches the kid value, key selection fails; the authorization server MUST NOT try candidate keys in turn.¶

When retrieving a JWK Set or client metadata, the authorization server MUST authenticate the HTTPS server and MUST NOT follow redirects. Bounding response size and request time, and blocking prohibited network destinations, are local defenses; see Section 7. The values that the authorization server advertises in the client_attestation_signing_alg_values_supported metadata parameter (Section 8 of [ATTEST]) SHOULD be consistent with the algorithm restrictions in step 3 of Section 5.2.¶

5.4. Errors

Endorsement validation covers these parts of Section 5.2:¶

• obtaining the client metadata in step 1, when neither the authoritative source nor a fresh cached copy provides it, including a CIMD that has been removed (Section 6.1);¶

• selecting a permitted endorsement in step 2;¶

• selecting the key source and resolving the kid header parameter in step 3 under Section 5.3, including an endorsed jwks_uri that matches neither the configured key source nor a configured alias; and¶

• finding no eligible key after any refresh permitted by Section 6.¶

How a failure is reported depends on how the Client Attestation is used in the request.¶

When the Client Attestation is the client authentication method, the authorization server MUST respond to an endorsement validation failure with the invalid_client_attestation error code. Section 7.4 of [ATTEST] defines that error code alongside the more general invalid_client error code; this profile requires the specific code so that the response identifies the Client Attestation, not another client credential, as the cause. The code does not distinguish endorsement failures from other attestation failures.¶

This profile does not change the HTTP status code that an endpoint returns for a client authentication failure. The token endpoint responds with HTTP status code 400 (Bad Request) by default and requires 401 (Unauthorized) only when the client attempted to authenticate through the Authorization request header field (Section 5.2 of [RFC6749]), which a Client Attestation does not use. The introspection endpoint responds with 401 (Unauthorized) (Section 2.3 of [RFC7662]). Other endpoints follow their own specifications.¶

A client library that recognizes only the invalid_client error code treats the invalid_client_attestation error code as an unrecognized failure rather than a credential failure.¶

When the Client Attestation accompanies another client authentication method as an additional security signal (Section 7.6 of [ATTEST]), an endorsement validation failure leaves no attestation signal for that request. The authorization server MUST NOT treat the failed attestation as a satisfied signal. If the deployment requires an attestation alongside that method, the request fails. An authorization server signals that requirement by advertising the client_attestation_pop_methods_supported metadata parameter without the value none; a list containing none signals that the attestation is optional. Where the attestation is optional, whether the request proceeds on the companion method alone is authorization server policy.¶

Whenever an endorsement validation failure causes the authorization server to reject the request, the authorization server MUST respond with the invalid_client_attestation error code, whether the Client Attestation served as the client authentication method or as an additional security signal. In either case, the response MUST NOT expose policy details.¶

A fresh attestation does not correct an endorsement validation failure caused by disagreement between the endorsement and authorization server configuration, such as an endorsed jwks_uri matching neither the configured key source nor a configured alias (Section 5.3). Because the response carries no policy detail, a client cannot distinguish that case from one that a fresh attestation would correct, or from a transient retrieval failure (Section 6) that a later presentation can resolve. The client publisher and the authorization server operator resolve a configuration disagreement outside the protocol, for example under the trust agreement (Section 2.3), not by client retry.¶

Other failures produce the errors defined by their own specifications. Failures of signature verification with a resolved key and of the remaining attestation and proof checks produce the errors of Section 7.4 of [ATTEST], including challenge and freshness responses. Except where the selected proof method's own specification requires a different error code, such as invalid_dpop_proof for an invalid DPoP proof in DPoP combined mode (Section 5 of [RFC9449]), the authorization server MUST use invalid_client_attestation rather than invalid_client wherever Section 7.4 of [ATTEST] permits it, so that a generic attestation failure does not reveal whether endorsement validation succeeded. The specific responses that ATTEST and the proof method require, such as use_fresh_attestation, use_attestation_challenge, and invalid_dpop_proof, occur only after endorsement validation succeeds and so reveal that it did; this profile preserves them. A DPoP key that does not match the cnf claim of the Client Attestation (Section 7.3 of [ATTEST]) still produces invalid_client_attestation. A companion client authentication method that fails, or that authenticates a different client identifier, produces the error defined by its own specification. Other metadata-discovery, registration, authentication, and grant errors follow their base specifications. The prohibition on other attester-trust mechanisms in Section 2.1 applies.¶

6.1. Cache Freshness and Removal

The authorization server MUST:¶

• enforce configured finite maximum ages for cached endorsement metadata and JWK Sets, applying the caching constraints of [CIMD] and HTTP [RFC9111] when stricter; and¶

• revalidate or refresh expired entries before use, rejecting stale entries if that operation fails.¶

Configured maximum ages bound withdrawal latency: a withdrawn endorsement or key can remain acceptable until the applicable age expires. The authorization server operator chooses maximum ages that keep this latency within the deployment's security requirements; short maximum ages, for example one hour, reduce it. This specification defines no upper limit, so a publisher cannot predict withdrawal latency from the protocol alone; a deployment that needs a predictable bound states one in its trust agreement. Fresh entries need not be retrieved on each request. These limits apply to cached copies, not to authoritative client registrations.¶

On an unknown kid value, the authorization server SHOULD refresh the selected key source's JWK Set once and retry key selection, subject to rate limits. The authorization server MUST rate-limit these refreshes per selected key source, independently of the kid value, and MUST reject the attestation if no eligible key is available. Where several clients or publishers endorse one key source, the authorization server SHOULD also limit refreshes per endorsing client and per publisher, so that no client or publisher can exhaust another's allowance. Rate-limit parameters are deployment-specific. An iss claim value that matches no endorsement MUST NOT cause a client metadata refresh; the metadata maximum age bounds the delay before a newly published endorsement takes effect, as it bounds withdrawal.¶

On observing that a CIMD or a selected JWK Set has been removed, as indicated by a 404 (Not Found) or 410 (Gone) status code, the authorization server MUST stop using previously cached endorsements or keys from that document, and MUST NOT use them again unless a later retrieval of that document succeeds. A retrieval failure that is not a removal, such as a timeout or a 5xx (Server Error) status code, does not by itself invalidate an unexpired cached copy. While the authorization server uses an unexpired cached copy, it cannot observe a removal. Deleting a client registration removes its endorsements.¶

6.2. Endorsement and Key Changes

Once the authorization server has retrieved or stored a metadata or key update, it MUST use it on the next presentation. Removing an endorsement or a verification key, or publishing an empty list, prevents acceptance under that entry or key, including for attestations issued before the update. Denial by authorization server policy MUST take effect immediately on subsequent requests, without waiting for cache expiration.¶

For planned key rotation, the attester adds the new key to the JWK Set the authorization server reads (the configured key source or the endorsed jwks_uri, Section 5.3) and waits for JWK Set cache lifetimes to elapse before signing with it. It keeps the old key published until attestations signed with it expire, because removing the key causes them to be rejected. A new key location takes effect only after the publisher updates the endorsement and the authorization server's cached metadata refreshes. Under AS-configured attester trust, it also fails endorsement validation until the authorization server configures a matching alias or updates its configured key source, so the attester and publisher coordinate the change with the authorization server operator.¶

6.3. Existing Grants

Endorsement withdrawal is prospective: it prevents future client authentication under the removed endorsement but does not revoke existing grants or access tokens. Refresh requests that require a Client Attestation are checked again under Section 5. A deployment that requires termination separately revokes the affected grants and their tokens and stops further refresh issuance. Introspection [RFC7662] then reports the revoked tokens inactive; a resource server that validates tokens locally relies on a separate revocation mechanism or on token expiration.¶

7.1. Publisher Compromise

A party that controls a CIMD host or a client's registration administration can change endorsements, within authorization server policy. This specification provides no independent indication that an endorsement change resulted from publisher compromise, so operators typically monitor endorsement changes and treat new attesters as policy changes. A separately specified signed-metadata mechanism with independently trusted signing keys could bind publisher intent independently of the HTTPS host; this specification defines none.¶

7.2. Publisher-Selected Attesters

Under publisher-authorized key selection, the authorization server accepts each attester that an authorized publisher endorses (Section 2.1). The publisher, or a party that controls its CIMD host, can therefore operate its own attester, and a Client Attestation verified under this policy carries no assurance independent of the publisher. Claims it makes about the Client Instance, such as platform or hardware integrity, are only as trustworthy as the publisher. A deployment that relies on attester assurance independent of the publisher uses AS-configured attester trust for those attesters.¶

7.3. Shared Attesters

A client or tenant of a shared attester could obtain attestations naming another, so the attester needs issuance controls that prevent this. Under AS-configured attester trust, the agreement check in Section 5.3 isolates tenants only if the configured key source and its aliases preserve the endorsed tenant scope, which is the authorization server operator's responsibility.¶

7.4. Key Retrieval

Under publisher-authorized key selection, an authorized publisher chooses both the issuer and the key location, and so can direct a request from the authorization server to an origin of its choosing. The requirements in Section 5.3 constrain that request, and extend to key retrieval the prohibition on automatically following HTTP redirects in Section 5 of [CIMD], but they do not prevent it. An authorization server can also bound response size and request time and block prohibited network destinations. Endorsed URLs remain subject to server-side request forgery (SSRF) defenses; endorsement does not make a network location safe.¶

7.5. Withdrawal Latency

Cached copies can remain in use after withdrawal (Section 6), so removing a key at its origin is not instantaneous revocation. Prompt termination requires denial by authorization server policy (Section 6.2) or another revocation channel.¶

7.6. Omitted Attestation

The client_attesters parameter does not itself require attestation, so an attacker that obtains the client's other credentials can authenticate without one unless the deployment requires attestation, either through an attestation-based token_endpoint_auth_method value or by authorization server policy that requires an attestation alongside another method (Section 5.4); the latter retains mutual TLS or private_key_jwt as the client authentication method. Advertising the client_attestation_pop_methods_supported metadata parameter without the value none signals such a policy to clients but does not enforce it (Section 7.6 of [ATTEST]). A registration access token can change the token_endpoint_auth_method or jwks parameter through [RFC7592] even where it cannot change client_attesters (Section 2.2), so a deployment relying on endorsement also restricts those changes or requires attestation by authorization server policy.¶

7.7. Unscoped Endorsement

An endorsement carries no audience. Under publisher-authorized key selection, one endorsement selects the attester and its keys at every authorization server whose policy covers that publisher, so a compromised attester authenticates the client at all of them until the endorsement is withdrawn.¶

9.1. OAuth Dynamic Client Registration Metadata Registration

This specification requests registration of the following value in the "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]:¶

• Client Metadata Name: client_attesters¶

• Client Metadata Description: Attesters endorsed to issue Client Attestations for this client, with their verification-key locations¶

• Change Controller: IETF¶

• Specification Document(s): Section 3 of this specification¶

9.2. OAuth Authorization Server Metadata Registration

This specification requests registration of the following value in the "OAuth Authorization Server Metadata" registry established by [RFC8414]:¶

• Metadata Name: client_attester_endorsement_supported¶

• Metadata Description: Boolean value indicating whether the authorization server supports processing the client_attesters client metadata parameter¶

• Change Controller: IETF¶

• Specification Document(s): Section 4 of this specification¶

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

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

[RFC2119]

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

[RFC6454]

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/rfc/rfc6454>.

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

[RFC7515]

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

[RFC7517]

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

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

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

[RFC8174]

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

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

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

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

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

10.2. Informative References

[INSTANCE-ID]

McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", 14 September 2026, <https://mcguinness.github.io/draft-mcguinness-oauth-client-instance-id/draft-mcguinness-oauth-client-instance-id.html>.

[RFC7009]

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

[RFC7592]

Richer, J., Ed., Jones, M., Bradley, J., and M. Machulak, "OAuth 2.0 Dynamic Client Registration Management Protocol", RFC 7592, DOI 10.17487/RFC7592, July 2015, <https://www.rfc-editor.org/rfc/rfc7592>.

[RFC7662]

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

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

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

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

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