]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol OAuth client attestation client metadata 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. 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 OAuth 2.0 Attestation-Based Client Authentication (ATTEST) enables a Client Attester to make security-relevant statements about a Client Instance and the key it holds. Before an authorization server (AS) relies on such an attestation, it determines two things: whether the attester is trusted () and whether that attester is authorized to attest for this particular client. ATTEST defines the Client Attestation format, presentation, and validation, and places the establishment of trust in Client Attesters outside its scope (). It defines no relationship by which a client identifies the attesters authorized to attest its instances. That relationship is needed when a client has many independently provisioned instances, uses a platform or workload attester, migrates between attesters, or is identified by a Client ID Metadata Document (CIMD) rather than by pre-established bilateral configuration. If the authorization server configures every client-to-attester association, the client cannot withdraw or narrow its attesters without the involvement of the authorization server. This specification makes the relationship explicit with a Client Attester Endorsement in client metadata: Attester --attests--> Client Instance \__________________ AS validates __________________/ ]]> An endorsement states that the client publisher authorizes the named Client Attester to attest for the client. It does not make that attester trusted by the authorization server, which still decides whether to accept the endorsed attester and how to trust its verification keys (). The client_attesters client metadata parameter () carries the endorsed attesters and their verification-key locations. It can be used by registered clients and by clients identified by a CIMD, and it can hold several endorsements, for example across heterogeneous platforms or during attester migration. This separates two distinct authorities:

• the client publisher determines which attesters are authorized to attest for the client; and
• the authorization server determines which of those endorsements it is willing to trust.

The client publisher thus manages its attester associations without gaining control of authorization server trust policy. It can always withdraw or narrow its endorsements. Adding an attester or moving its key location takes effect without authorization server action only where the authorization server authorizes the publisher to select keys; where the authorization server configures attester trust itself, the change also requires acceptance by the authorization server (). This profile builds on ATTEST and introduces no new credential or client authentication method. ATTEST, this profile, and the optional Client Instance ID profile address separate layers: Endorsement carries no instance semantics, and instance identification does not establish attester trust. Neither establishes user delegation. Deployments that can manage client-to-attester associations entirely through authorization server configuration can use without this profile. This profile is intended for deployments in which the client publisher expresses and maintains that association, subject to authorization server policy ().

Conventions and Trust Model The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This specification uses the OAuth 2.0 terms defined in . The terms Client Attestation, Client Attester, Client Instance, and Client Instance Key are used as defined in .

client publisher

The party authorized to publish the endorsements for a client_id: for a client identified by a CIMD, the party that controls that document; for a registered client, the party authorized to set its endorsements ().

Client Attester Endorsement

A statement in the authoritative client metadata for a client_id identifying a Client Attester whose Client Attestations naming that client_id are eligible for acceptance under this profile, subject to authorization server policy (). It expresses the publisher's authorization for that attester to attest for the client; it does not specify which Client Instances the attester may attest, which leaves to the attester. An endorsement delegates attestation authority for the named client only. It does not delegate OAuth authorization, user authority, or authority to further delegate attestation.

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 ().
2. Authorization server attester acceptance: authorization server policy permits that attester for that client and determines how the attester's verification keys are trusted ().

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 . 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 () 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; 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 , 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 ().

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 , the same two conditions establish attester authority; instance continuity remains independent.

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 . 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 . 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 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 () or keep the previously stored value, if any, instead of the submitted one, as permits for an ignored value. The client information response () then never contains an endorsement the authorization server has not accepted, and an unauthorized request never removes a stored endorsement.

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 . 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 leaves unspecified. An authorization server advertises the capability with the client_attester_endorsement_supported metadata parameter (). 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 , the device authorization endpoint , and the introspection and revocation 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 . This profile retains the wire format, proof methods, and token binding of ATTEST. A resource server that accepts a Client Attestation presented to it () 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 () 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 , the Demonstrating Proof of Possession (DPoP) key 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 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.

Conformance Conformance requirements depend on the role:

• Client publishers publish and maintain client_attesters under , and withdraw an endorsement by updating that metadata ().
• Client Attesters and clients implement their issuance and presentation requirements in .
• Authorization servers implement key-trust policy selection, metadata and key validation, processing, and withdrawal, and can advertise support under .

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

Client Metadata The client_attesters parameter is OPTIONAL client metadata, usable in registered client metadata (including ) or a CIMD. Its value is a JSON array of objects, each a Client Attester Endorsement () for the client_id whose metadata contains it: Members of a client_attesters entry

Member	Requirement	Meaning
issuer	REQUIRED, nonempty StringOrURI	Exact iss claim value of the endorsed Client Attester
jwks_uri	REQUIRED, HTTPS URL without userinfo or fragment	Location of the attester's public JSON Web Key (JWK) Set

An issuer value identifies a namespace, not a discovery endpoint. An issuer MUST NOT occur more than once in the array. A missing or empty array authorizes no attester. An entry is malformed if it violates the requirements in the table above. The authorization server MUST:

• reject client_attesters for this profile if an entry is malformed or an issuer occurs more than once, using no endorsement from the list; and
• ignore unrecognized members.

Rejection under this profile does not affect the client's other authentication methods and does not by itself make a CIMD invalid or uncacheable under . An extension to this parameter is safe only if an implementation that ignores it interprets the endorsement the same way; this specification defines no means to mark an extension as critical. Endorsed keys authenticate attesters, not clients. A key obtained from an endorsement MUST NOT be used to verify a client authentication assertion, and a key from the client's own jwks or jwks_uri MUST NOT be used to verify a Client Attestation. An entry whose jwks_uri is identical to the client's own jwks_uri is also malformed. An endorsement identifies a Client Attester by both issuer and key location. The publisher cannot know which key-trust policy the authorization server applies, so each entry carries a complete issuer-to-key-location mapping that has the same meaning under either policy; specifies how each policy uses the location. recommends, among other options, resolving the kid header parameter through client metadata, such as the jwks_uri parameter. This profile applies that option through a separate key location for each endorsed issuer, not through the client's own jwks_uri. The client's own jwks_uri can hold several issuers' keys, but it neither associates them with named attesters nor separates them from client authentication keys, so it does not replace client_attesters. Secure Production Identity Framework for Everyone (SPIFFE) client authentication uses a comparable pair of key sources for SVID signing keys. Its spiffe_bundle_endpoint client metadata parameter names a bundle location for the client's trust domain. A bundle obtained from it is used only for that client_id, and recommends using a bundle that the authorization server has obtained for the trust domain by other means instead. Publisher-authorized key selection corresponds to accepting spiffe_bundle_endpoint from client metadata, and has the same trust model (). AS-configured attester trust corresponds to a bundle obtained by other means. This specification requires the configured key source to govern the issuer for every client (), where SPIFFE-OAUTH only recommends it. Clients using attestation as client authentication use the value attest_jwt_client_auth or attest_jwt_client_auth_dpop in the token_endpoint_auth_method client metadata parameter (). When attestation supplements another method (), that method still authenticates the client. The client_attesters parameter does not select a grant type, proof method, or the optional instance-identification profile.

Authorization Server Metadata In addition to the parameters in , this specification defines the following OPTIONAL authorization server metadata parameter :

client_attester_endorsement_supported

Boolean value indicating whether the authorization server supports processing the client_attesters client metadata parameter as defined in this specification. If omitted, the default value is false.

Whether this profile governs a particular client, and which key-trust policy applies to an attester, remain matters of authorization server policy (, ).

Attestation and Authorization Server Processing This section specifies Client Attestation content, the authorization server's validation order, key selection, and error reporting.

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 , 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 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 (). 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 , containing a nonempty value that identifies its signing key.

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

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 or registered metadata policy, including . 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 (), 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 (), not here.
3. Select the key source under . Resolve the kid header parameter to one eligible public key, refreshing on an unknown kid value only as 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 (), 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 , 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.

Key Source Selection The authorization server MUST select keys according to the key-trust policy governing the client-to-attester association (). 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 () 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 . 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 );
• 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 . The values that the authorization server advertises in the client_attestation_signing_alg_values_supported metadata parameter () SHOULD be consistent with the algorithm restrictions in step 3 of .

Errors Endorsement validation covers these parts of :

• 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 ();
• selecting a permitted endorsement in step 2;
• selecting the key source and resolving the kid header parameter in step 3 under , 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 .

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. 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. recommends 400 (Bad Request) for its error codes at an authorization server and permits 401 (Unauthorized) for invalid_client_attestation. 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 (), which a Client Attestation does not use. The introspection endpoint responds with 401 (Unauthorized) (). 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 (), 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 (). 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 () 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 (), 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 , 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 (), the authorization server MUST use invalid_client_attestation rather than invalid_client wherever 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 () 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 applies.

Updates and Withdrawal A publisher withdraws an endorsement by removing it from the authoritative client metadata (). The removal takes effect at the authorization server as cached copies expire (), applies from the next presentation once retrieved (), and does not affect issued grants unless they are separately revoked ().

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 and HTTP 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.

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, ) 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.

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 . A deployment that requires termination separately revokes the affected grants and their tokens and stops further refresh issuance. Introspection then reports the revoked tokens inactive; a resource server that validates tokens locally relies on a separate revocation mechanism or on token expiration.

Security Considerations The security considerations of , , and apply.

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.

Publisher-Selected Attesters Under publisher-authorized key selection, the authorization server accepts each attester that an authorized publisher endorses (). 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. limits reliance on attestation claims, such as platform or hardware integrity of the Client Instance, to the trust placed in the issuing Client Attester; under this policy, that is trust in the publisher. describes the same trust model for SPIFFE bundles obtained from a CIMD. A deployment that relies on attester assurance independent of the publisher uses AS-configured attester trust for those attesters.

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 isolates tenants only if the configured key source and its aliases preserve the endorsed tenant scope, which is the authorization server operator's responsibility.

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 constrain that request, and extend to key retrieval the prohibition on automatically following HTTP redirects in , 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.

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

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 (); 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 (). A registration access token can change the token_endpoint_auth_method or jwks parameter through even where it cannot change client_attesters (), so a deployment relying on endorsement also restricts those changes or requires attestation by authorization server policy.

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.

Privacy Considerations The privacy considerations of and apply. Public metadata exposes client-to-attester relationships. Such metadata need not enumerate instances or their keys, and this specification does not require them to; it requires no stable instance identifier. Caching reduces the request-timing information observable at metadata and key sources.

IANA Considerations

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

• 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): of this specification

OAuth Authorization Server Metadata Registration This specification requests registration of the following value in the "OAuth Authorization Server Metadata" registry established by :

• 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): of this specification

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, as 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. 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 defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] 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] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. 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 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. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. 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 This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. 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. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. 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. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. 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 X509-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. Independent 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.

Client ID Metadata Document Example This example is informative. The authorization server has the following configuration, which is authorization server policy, not protocol metadata: Authorization server configuration for this example

Setting	Value
Permitted origin for CIMD retrieval	https://platform.example
Independently trusted attester	https://attester.example/tenant/acme
Key-trust policy for that attester	AS-configured attester trust
Configured key source for that attester	https://attester.example/tenant/acme/jwks
Maximum metadata and key cache ages	3600 seconds each

The following example shows the Client ID Metadata Document that the publisher serves at https://platform.example/oauth-client: The following example shows the JWK Set published at the configured key source. Its signing key is distinct from the Client Instance Key in the jwk member of the cnf claim: The following example shows the decoded JOSE header of the Client Attestation, whose kid header parameter selects that key: The following example shows the decoded payload of the Client Attestation. The iss claim names the endorsed issuer, and the sub claim names the client:

1. The Client Instance proves to the attester that it is authorized to use this client identifier and holds its Client Instance Key.
2. The attester issues the Client Attestation shown above.
3. After user authorization, the Client Instance redeems its authorization code with that client_id, the Client Attestation, and a combined Demonstrating Proof of Possession (DPoP) proof .
4. The authorization server validates the CIMD, endorsement, attestation, proof, and grant before issuing the access token.

There is one Client ID Metadata Document, not one per Client Instance. An endorsement for this client does not let the attester authenticate another client, even if both use the same Client Attester. The flow does not require the client_instance_id claim of or an act claim (). Under AS-configured attester trust, keys come only from the configured key source, and the endorsed jwks_uri is required to equal it, as it does here. An attestation from an unendorsed issuer, an endorsement naming the trusted issuer with a different key location, or a kid value that resolves to no key in the configured key source results in the following error response. requires a 401 (Unauthorized) status code only for a client that attempted to authenticate through the Authorization request header field, which this client does not use, so the example shows the default 400 (Bad Request) status code: If the authorization server had instead authorized https://platform.example for publisher-authorized key selection and had not configured trust for the issuer, the same document would also be accepted, with keys retrieved from the endorsed jwks_uri, which shares the issuer's origin. An entry whose jwks_uri had a different origin from the issuer would then fail endorsement validation with the same error.

Registered Client Example This example is informative. It repeats , with the same authorization server configuration, for an opaque client identifier. Under AS-configured attester trust, neither endorsement nor key selection depends on the form of the identifier: the client_attesters parameter is part of the client's metadata, and the endorsement names the key location directly, so no origin is derived from the client identifier. Publisher authorization differs between the two forms (), but that difference does not arise here, because the authorization server trusts this attester independently. An authenticated, authorized administrator registers the client, for example through . The following example shows the client information response that the authorization server returns: The attester signs with the same key as in , so the JOSE header of the attestation is unchanged: The following example shows the payload, in which only the sub claim differs: The client redeems its authorization code with client_id=s6BhdRkqt3, that attestation, and a combined DPoP proof. The authorization server reads the registered metadata rather than retrieving a CIMD, then runs the same steps of : the endorsed issuer matches the iss claim of the attestation, AS-configured attester trust selects the configured key source, the kid value resolves to the attester-1 key there, and the sub claim equals the requested client_id. The failure cases and their error response are those of .

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

• Aligned with draft-ietf-oauth-attestation-based-client-auth-12 and draft-ietf-oauth-spiffe-client-auth-03: the example attestations include the now-required iat claim, Errors cites the status codes of ATTEST, and the SPIFFE comparison reflects client-scoped bundles.
• Cited draft-mcguinness-oauth-client-instance-id as an Internet-Draft.

-00

• Initial draft.