OAuth 2.0 Client Attester Endorsement
draft-mcguinness-oauth-client-attesters-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Karl McGuinness | ||
| Last updated | 2026-09-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mcguinness-oauth-client-attesters-00
Web Authorization Protocol K. McGuinness
Internet-Draft Independent
Intended status: Standards Track 28 September 2026
Expires: 1 April 2027
OAuth 2.0 Client Attester Endorsement
draft-mcguinness-oauth-client-attesters-00
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://mcguinness.github.io/draft-mcguinness-oauth-client-attesters/
draft-mcguinness-oauth-client-attesters.html. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
mcguinness-oauth-client-attesters/.
Discussion of this document takes place on the Web Authorization
Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/oauth/.
Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.
Source for this draft and an issue tracker can be found at
https://github.com/mcguinness/draft-mcguinness-oauth-client-
attesters.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
McGuinness Expires 1 April 2027 [Page 1]
Internet-Draft Client Attester Endorsement September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Trust Model . . . . . . . . . . . . . . . . . 5
2.1. Acceptance Policy . . . . . . . . . . . . . . . . . . . . 5
2.2. Registered Endorsements . . . . . . . . . . . . . . . . . 7
2.3. Applicability and Scope . . . . . . . . . . . . . . . . . 7
2.4. Conformance . . . . . . . . . . . . . . . . . . . . . . . 8
3. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 9
4. Authorization Server Metadata . . . . . . . . . . . . . . . . 10
5. Attestation and Authorization Server Processing . . . . . . . 11
5.1. Issuance and Presentation . . . . . . . . . . . . . . . . 11
5.2. Authorization Server Processing . . . . . . . . . . . . . 12
5.3. Key Source Selection . . . . . . . . . . . . . . . . . . 13
5.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Updates and Withdrawal . . . . . . . . . . . . . . . . . . . 17
6.1. Cache Freshness and Removal . . . . . . . . . . . . . . . 17
6.2. Endorsement and Key Changes . . . . . . . . . . . . . . . 18
6.3. Existing Grants . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Publisher Compromise . . . . . . . . . . . . . . . . . . 19
7.2. Publisher-Selected Attesters . . . . . . . . . . . . . . 19
McGuinness Expires 1 April 2027 [Page 2]
Internet-Draft Client Attester Endorsement September 2026
7.3. Shared Attesters . . . . . . . . . . . . . . . . . . . . 20
7.4. Key Retrieval . . . . . . . . . . . . . . . . . . . . . . 20
7.5. Withdrawal Latency . . . . . . . . . . . . . . . . . . . 20
7.6. Omitted Attestation . . . . . . . . . . . . . . . . . . . 20
7.7. Unscoped Endorsement . . . . . . . . . . . . . . . . . . 21
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. OAuth Dynamic Client Registration Metadata
Registration . . . . . . . . . . . . . . . . . . . . . . 21
9.2. OAuth Authorization Server Metadata Registration . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Client ID Metadata Document Example . . . . . . . . 24
Appendix B. Registered Client Example . . . . . . . . . . . . . 27
Document History . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
OAuth 2.0 Attestation-Based Client Authentication (ATTEST) [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 (Section 7.1 of [ATTEST]) 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 (Section 10.8 of [ATTEST]). 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) [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:
Client metadata --endorses--> Attester --attests--> Client Instance
\__________________ AS validates __________________/
McGuinness Expires 1 April 2027 [Page 3]
Internet-Draft Client Attester Endorsement September 2026
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 (Section 2). The client_attesters client metadata
parameter (Section 3) 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 (Section 2).
This profile builds on ATTEST and introduces no new credential or
client authentication method. ATTEST, this profile, and the optional
Client Instance ID profile [INSTANCE-ID] address separate layers:
Client Attester Endorsement Who may attest for this client?
|
v
ATTEST Is this a legitimate instance holding
| this key now?
v
Client Instance ID (optional) Which persistent instance is this?
Endorsement carries no instance semantics, and instance
identification does not establish attester trust. Neither
establishes user delegation.
McGuinness Expires 1 April 2027 [Page 4]
Internet-Draft Client Attester Endorsement September 2026
Deployments that can manage client-to-attester associations entirely
through authorization server configuration can use [ATTEST] without
this profile. This profile is intended for deployments in which the
client publisher expresses and maintains that association, subject to
authorization server policy (Section 2.1).
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This specification uses the OAuth 2.0 terms defined in [RFC6749].
The terms Client Attestation, Client Attester, Client Instance, and
Client Instance Key are used as defined in [ATTEST].
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 (Section 2.2).
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 (Section 2.1). 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 Section 5
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.
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).
McGuinness Expires 1 April 2027 [Page 5]
Internet-Draft Client Attester Endorsement September 2026
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
McGuinness Expires 1 April 2027 [Page 6]
Internet-Draft Client Attester Endorsement September 2026
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
McGuinness Expires 1 April 2027 [Page 7]
Internet-Draft Client Attester Endorsement September 2026
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).
McGuinness Expires 1 April 2027 [Page 8]
Internet-Draft Client Attester Endorsement September 2026
* 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.
3. Client Metadata
The client_attesters parameter is OPTIONAL client metadata, usable in
registered client metadata (including [RFC7591]) or a CIMD. Its
value is a JSON array of objects, each a Client Attester Endorsement
(Section 2) for the client_id whose metadata contains it:
+==========+=======================+==============================+
| Member | Requirement | Meaning |
+==========+=======================+==============================+
| issuer | REQUIRED, nonempty | Exact iss claim value of the |
| | StringOrURI [RFC7519] | endorsed Client Attester |
+----------+-----------------------+------------------------------+
| jwks_uri | REQUIRED, HTTPS URL | Location of the attester's |
| | without userinfo or | public JSON Web Key (JWK) |
| | fragment | Set [RFC7517] |
+----------+-----------------------+------------------------------+
Table 1: Members of a client_attesters entry
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 [CIMD]. 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.
McGuinness Expires 1 April 2027 [Page 9]
Internet-Draft Client Attester Endorsement September 2026
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; Section 5.3 specifies how each policy uses the location.
Section 10.8 of [ATTEST] 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 [SPIFFE-OAUTH] publishes one verification-key location
per trust domain in the spiffe_bundle_endpoint client metadata
parameter. Under AS-configured attester trust, the endorsed jwks_uri
serves that function for each named attester, but the key source is
established out of band and the endorsed location is only compared
against it. Publisher-authorized key selection lets the publisher
name the location, so it does not substitute for SPIFFE bundle
configuration.
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 (Section 9 of
[ATTEST]). When attestation supplements another method (Section 7.6
of [ATTEST]), that method still authenticates the client. The
client_attesters parameter does not select a grant type, proof
method, or the optional instance-identification profile.
4. Authorization Server Metadata
In addition to the parameters in Section 8 of [ATTEST], this
specification defines the following OPTIONAL authorization server
metadata parameter [RFC8414]:
client_attester_endorsement_supported Boolean value indicating
McGuinness Expires 1 April 2027 [Page 10]
Internet-Draft Client Attester Endorsement September 2026
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 (Section 2.3, Section 2.1).
5. Attestation and Authorization Server Processing
This section specifies Client Attestation content, the authorization
server's validation order, key selection, and error reporting.
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.
McGuinness Expires 1 April 2027 [Page 11]
Internet-Draft Client Attester Endorsement September 2026
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
McGuinness Expires 1 April 2027 [Page 12]
Internet-Draft Client Attester Endorsement September 2026
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.
McGuinness Expires 1 April 2027 [Page 13]
Internet-Draft Client Attester Endorsement September 2026
* *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.
McGuinness Expires 1 April 2027 [Page 14]
Internet-Draft Client Attester Endorsement September 2026
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.
McGuinness Expires 1 April 2027 [Page 15]
Internet-Draft Client Attester Endorsement September 2026
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.
McGuinness Expires 1 April 2027 [Page 16]
Internet-Draft Client Attester Endorsement September 2026
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. Updates and Withdrawal
A publisher withdraws an endorsement by removing it from the
authoritative client metadata (Section 3). The removal takes effect
at the authorization server as cached copies expire (Section 6.1),
applies from the next presentation once retrieved (Section 6.2), and
does not affect issued grants unless they are separately revoked
(Section 6.3).
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;
McGuinness Expires 1 April 2027 [Page 17]
Internet-Draft Client Attester Endorsement September 2026
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
McGuinness Expires 1 April 2027 [Page 18]
Internet-Draft Client Attester Endorsement September 2026
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. Security Considerations
The security considerations of Section 12 of [ATTEST], Section 8 of
[CIMD], and [RFC8725] apply.
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.
McGuinness Expires 1 April 2027 [Page 19]
Internet-Draft Client Attester Endorsement September 2026
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.
McGuinness Expires 1 April 2027 [Page 20]
Internet-Draft Client Attester Endorsement September 2026
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.
8. Privacy Considerations
The privacy considerations of Section 11 of [ATTEST] and Section 9 of
[CIMD] 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.
9. IANA Considerations
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
McGuinness Expires 1 April 2027 [Page 21]
Internet-Draft Client Attester Endorsement September 2026
* Change Controller: IETF
* Specification Document(s): Section 4 of this specification
10. References
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>.
McGuinness Expires 1 April 2027 [Page 22]
Internet-Draft Client Attester Endorsement September 2026
[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>.
McGuinness Expires 1 April 2027 [Page 23]
Internet-Draft Client Attester Endorsement September 2026
[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>.
Appendix A. Client ID Metadata Document Example
This example is informative. The authorization server has the
following configuration, which is authorization server policy, not
protocol metadata:
McGuinness Expires 1 April 2027 [Page 24]
Internet-Draft Client Attester Endorsement September 2026
+=======================+=======================================+
| Setting | Value |
+=======================+=======================================+
| Permitted origin for | https://platform.example |
| CIMD retrieval | |
+-----------------------+---------------------------------------+
| Independently trusted | https://attester.example/tenant/acme |
| attester | |
+-----------------------+---------------------------------------+
| Key-trust policy for | AS-configured attester trust |
| that attester | |
+-----------------------+---------------------------------------+
| Configured key source | https://attester.example/tenant/acme/ |
| for that attester | jwks |
+-----------------------+---------------------------------------+
| Maximum metadata and | 3600 seconds each |
| key cache ages | |
+-----------------------+---------------------------------------+
Table 2: Authorization server configuration for this example
The following example shows the Client ID Metadata Document that the
publisher serves at https://platform.example/oauth-client:
{
"client_id": "https://platform.example/oauth-client",
"client_name": "Managed Agent Harness",
"redirect_uris": ["https://platform.example/callback"],
"grant_types": ["authorization_code"],
"response_types": ["code"],
"token_endpoint_auth_method": "attest_jwt_client_auth_dpop",
"client_attesters": [
{
"issuer": "https://attester.example/tenant/acme",
"jwks_uri": "https://attester.example/tenant/acme/jwks"
}
]
}
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:
McGuinness Expires 1 April 2027 [Page 25]
Internet-Draft Client Attester Endorsement September 2026
{
"keys": [{
"kty": "EC",
"crv": "P-256",
"kid": "attester-1",
"use": "sig",
"alg": "ES256",
"x": "axfR8uEsQkf4vOblY6RA8ncDfYEt6zOg9KE5RdiYwpY",
"y": "T-NC4v4af5uO5-tKfA-eFivOM1drMV7Oy7ZAaDe_UfU"
}]
}
The following example shows the decoded JOSE header of the Client
Attestation, whose kid header parameter selects that key:
{
"typ": "oauth-client-attestation+jwt",
"alg": "ES256",
"kid": "attester-1"
}
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:
{
"iss": "https://attester.example/tenant/acme",
"sub": "https://platform.example/oauth-client",
"exp": 2524608000,
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "9iHztmYIeKeyta94k1y5Dya5cab3-_H_yw_3v0p6K80",
"y": "NsrICJ4xFvOs5xaDM4sF1yDijCxN5LWailjw5EsERwI"
}
}
}
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
[RFC9449].
McGuinness Expires 1 April 2027 [Page 26]
Internet-Draft Client Attester Endorsement September 2026
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
[INSTANCE-ID] or an act claim (Section 4.1 of [RFC8693]).
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. Section 5.2 of [RFC6749]
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:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{"error": "invalid_client_attestation"}
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.
Appendix B. Registered Client Example
This example is informative. It repeats Appendix A, 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
(Section 2), but that difference does not arise here, because the
authorization server trusts this attester independently.
McGuinness Expires 1 April 2027 [Page 27]
Internet-Draft Client Attester Endorsement September 2026
An authenticated, authorized administrator registers the client, for
example through [RFC7591]. The following example shows the client
information response that the authorization server returns:
{
"client_id": "s6BhdRkqt3",
"client_name": "Managed Agent Harness",
"redirect_uris": ["https://app.example/callback"],
"grant_types": ["authorization_code"],
"response_types": ["code"],
"token_endpoint_auth_method": "attest_jwt_client_auth_dpop",
"client_attesters": [
{
"issuer": "https://attester.example/tenant/acme",
"jwks_uri": "https://attester.example/tenant/acme/jwks"
}
]
}
The attester signs with the same key as in Appendix A, so the JOSE
header of the attestation is unchanged:
{
"typ": "oauth-client-attestation+jwt",
"alg": "ES256",
"kid": "attester-1"
}
The following example shows the payload, in which only the sub claim
differs:
{
"iss": "https://attester.example/tenant/acme",
"sub": "s6BhdRkqt3",
"exp": 2524608000,
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "9iHztmYIeKeyta94k1y5Dya5cab3-_H_yw_3v0p6K80",
"y": "NsrICJ4xFvOs5xaDM4sF1yDijCxN5LWailjw5EsERwI"
}
}
}
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,
McGuinness Expires 1 April 2027 [Page 28]
Internet-Draft Client Attester Endorsement September 2026
then runs the same steps of Section 5.2: 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
Appendix A.
Document History
_RFC EDITOR: Remove this section before publication._
* Initial draft.
Author's Address
Karl McGuinness
Independent
Email: public@karlmcguinness.com
McGuinness Expires 1 April 2027 [Page 29]