Summary

  • A 28 September individual Internet-Draft proposes client_attesters metadata so a client publisher can name and later remove attesters; an authorization server must still accept the issuer under its own policy.
  • Withdrawal blocks future authentication under the removed endorsement once the server observes it. The proposal does not turn existing grants or access tokens off; those require separate action.

There is an invitingly simple incident-response step in the new OAuth 2.0 Client Attester Endorsement draft: remove an unwanted attester from the client's authoritative metadata. It is a meaningful act. It is not the same act as ending every session of access that the client has already obtained. The distinction is the centre of the proposal's governance value—and the risk of reading it as a universal revocation button.

K. McGuinness's 28 September 2026 -00 text is an individual Internet-Draft with intended Standards Track status. The IETF Datatracker lists it as an existing draft. That is not a published RFC, working-group adoption, interoperation result or evidence of a deployed incident. The text builds on the separate, still-developing attestation-based client authentication draft. It adds a relationship in client metadata, not a new credential or authentication method.

The relationship has two authors. A client publisher can place client_attesters in registered-client metadata or a Client ID Metadata Document, naming an attester and a location for verification keys. That says who the publisher authorizes to attest for this client. For a request governed by the profile, the authorization server must also decide that the attester is acceptable for this client and select a trusted key source. Endorsement cannot force server trust. Conversely, a server's pre-existing trust in an attester cannot add that attester to a client that did not endorse it. Neither act grants a user delegation or resource entitlement.

Withdrawal therefore has a particular path. The publisher changes authoritative metadata. A server using an unexpired cached copy may continue to see the older endorsement until its configured maximum age runs out. The draft requires finite maximum ages for cached endorsement metadata and JWK Sets, plus revalidation or rejection after expiry, but sets no universal upper bound. The operator chooses the bound; an agreement must state one if the publisher needs predictable latency. Those cache rules apply to copies, not authoritative client registrations.

Once the server has retrieved or stored the changed metadata, it must use the change on the next presentation. A denial made directly by server policy must take effect on subsequent requests without waiting for a cache.

The draft is equally explicit about the second path: withdrawing endorsement prevents future client authentication under it, but does not revoke existing grants or access tokens. A refresh request that requires Client Attestation is checked again. If termination is the objective, the deployment separately revokes affected grants and tokens and stops further refresh issuance. RFC 7662 offers a way for introspection to report revoked tokens inactive. A resource server validating tokens locally needs another revocation mechanism or must wait for token expiry. Even a perfectly refreshed endorsement cache is not a retroactive token eraser.

There are further boundaries to keep on the same page. If the publisher is authorized to choose an attester and its keys, the publisher can operate its own attester; the attestation then carries no assurance independent of that publisher. If another client authentication method is allowed and attestation is optional, the mere presence of client_attesters does not require one. A compromised metadata host can alter endorsements within server policy without this proposal independently proving that compromise. These are stated threat-model limits, not findings that any named operator has failed.

The published text does not prescribe a cross-organization termination receipt. An operator nevertheless needs to distinguish a change notice from a confirmed stop: the current endorsement set, the server's trust mode, the cache age, the first rejected new presentation, the affected grants and tokens, refresh behavior, and what each resource server will actually enforce. This is an editorial operating test, not a claimed IETF field. It asks whether the party declaring an attester removed can show where that declaration has—and has not—become effective.

Sources