Summary

  • draft-mcguinness-oauth-client-attesters-00 proposes client_attesters metadata through which a client publisher can name attesters and their JWK Set locations. Revision 00 is an individual Internet-Draft, not an RFC or adopted IETF standard.
  • Publisher endorsement and authorization-server trust are independent approvals. The first says who may vouch for this client; the second says whether, and from which key source, that voucher will be believed.
  • Removing an endorsement blocks future acceptance only after cache convergence. It does not revoke existing grants or tokens, and it does not affect a resource server that validates attestations directly.

The emergency ticket looks deceptively complete: “Attester removed.” The client publisher has deleted one entry from client_attesters. The authorization server’s dashboard has begun to refresh. Yet an access token issued an hour earlier still reaches a resource server, a fresh cache still contains the old endorsement, and another resource server validates Client Attestations directly under its own configured trust. The publication changed. The system did not change everywhere at once.

That gap is the most useful way to read OAuth 2.0 Client Attester Endorsement. The draft fills a real missing relationship in OAuth 2.0 Attestation-Based Client Authentication. ATTEST defines how an attester makes a signed statement about a Client Instance and its key. It deliberately leaves open how an authorization server knows that this attester is entitled to speak for this particular client_id. Revision 00 proposes putting that association in authoritative client metadata.

Each client_attesters entry carries an exact issuer and an HTTPS jwks_uri. The publisher thereby says: this named attester is eligible to attest for my client, and this is the key-set location associated with it. That is a statement of publisher intent. It is not a trust anchor, a client credential, a grant, a user delegation, or a resource authorization.

Two signatures of authority, not one

The profile requires two conditions before an authorization server accepts an attestation. First, the authoritative metadata selected for the requested client_id must currently endorse the attestation’s iss. Second, authorization-server policy must permit that attester for that client and determine how its verification keys are trusted.

Neither condition can substitute for the other. A publisher cannot force an authorization server to trust an attester merely by listing it. An authorization server that generally trusts an attester cannot add it to a client that has not endorsed it. For requests governed by the profile, policy can narrow the published set but may not widen it.

This division is easy to flatten in an interface. A green check beside “attester trusted” may describe only a cryptographic signature. A green check beside “attester endorsed” may describe only a metadata entry. The operational decision needs both records and their binding to the same client, exact issuer and key source. It also needs a separate grant decision afterward.

The draft offers two ways to establish the key source. Under publisher-authorized key selection, the authorization server has already decided that a particular publisher may select attesters and their keys. The endorsed jwks_uri is then retrieved, subject to HTTPS, same-origin, path-boundary and network-safety rules. This is scalable when an authorization server serves many independently operated clients. Its assurance is also bounded by the publisher: a compromised publisher can list an attester and key service it controls.

Under authorization-server-configured attester trust, the server independently configures the key source for the exact issuer. The endorsed jwks_uri must equal that source or an explicit alias, but it is not fetched. A mismatch fails rather than being resolved in favour of either party. This preserves independent trust, at the price of operator coordination.

The precedence rule deserves its own change review. If an authorization server has configured trust for an exact issuer for any client, that mode governs the issuer for every client. Removing the configured entry does not silently transfer control to publishers. An operator must separately authorize publisher selection. An apparently local trust edit can therefore have an issuer-wide blast radius.

The order prevents authority from leaking between fields

Validation begins by selecting one authoritative metadata source for client_id. The server must not merge a registration with a reachable Client ID Metadata Document, or switch sources after one fails endorsement validation. It then selects the sole entry whose issuer exactly matches the attestation’s iss, applies client-to-attester policy, chooses the governing key source, and resolves kid to exactly one eligible asymmetric public key.

The key is bound to four things: client identifier, issuer, selected source and trust policy. A kid value alone is not that binding. A union of keys from several entries is not that binding. The server ignores attestation-provided jku, x5u, x5c and jwk headers for key selection, then verifies the signature, exact sub == client_id, the remaining attestation and proof. Only after those steps does it apply grant and authorization policy.

That final separation is not ceremony. A valid attestation answers a security question about a client instance. It does not decide which resource, scope or business operation the client should receive. The draft’s architecture preserves this by making endorsement, trust, authentication and authorization serial decisions rather than synonyms.

Exact string comparison also matters. Issuer identifiers, client identifiers and configured source URIs are compared without URI normalization. An alias is an explicit policy statement, not a helpful parser rewrite. In a multi-tenant attester, an alias that erases tenant scope can quietly expand who may vouch for whom.

Withdrawal runs on several clocks

A publisher withdraws authority by removing the endorsement. The authorization server may continue using a fresh cached copy until its configured finite maximum age expires. The draft sets no universal ceiling. A publisher therefore cannot calculate the withdrawal time from the protocol alone; the bound belongs in the trust agreement.

The retrieval result changes the state. Once the server observes 404 or 410 for a Client ID Metadata Document or selected JWK Set, it must stop using the cached material. A timeout or 5xx does not invalidate a still-fresh cache. While the server relies on that cache, it cannot observe remote removal at all.

Key rotation has its own clock. The attester first publishes the new key, waits for JWK Set cache lifetimes, begins signing with it, and retains the old key until attestations signed by it expire. Moving the key location additionally waits for metadata refresh. In independently configured mode, the authorization-server operator must also accept the location or alias. “New key published” is therefore the start of a change, not evidence that every verifier can use it.

Most importantly, endorsement withdrawal is prospective. It prevents later authentication under that entry after the change is observed. It does not revoke grants or access tokens already issued. If the objective is termination, the operator must revoke the grants and their tokens, prevent later refresh issuance, make introspection report them inactive, and account for resource servers that validate tokens offline until expiration.

A direct-validation resource server forms another boundary. The profile does not tell it to discover or enforce client metadata. It relies on configured attester trust. Removing an endorsement at the authorization server has no effect there. A complete withdrawal plan has to inventory that path rather than assuming one metadata edit propagates to every verifier.

A receipt for the decision, not just the signature

The minimum useful record starts with the requested client_id and the single authoritative metadata source selected. It retains the metadata version or hash, retrieval time, freshness deadline and whether the copy came from cache. It records the exact endorsement, the publisher authority that made it admissible, and the authorization-server policy that independently accepted or rejected it.

Next comes key provenance: publisher-selected or independently configured; exact source; aliases; JWK Set hash and freshness; selected kid, algorithm and the fact that one eligible key matched. The receipt binds those values to the client and issuer before recording the attestation, proof and sub result.

Then it records whether attestation was mandatory on that endpoint. Publishing client_attesters does not itself make attestation compulsory. Where it is merely an optional signal beside another authentication method, policy may permit the request to proceed without it. A deployment can otherwise publish a careful endorsement list that an attacker bypasses with the client’s other credential.

Finally, the receipt records the independent grant decision. During withdrawal it adds observation time, cache convergence, last accepted presentation, attestation expiry, grant and token revocation, refresh denial, introspection state, offline-token horizon and the direct validators checked. This operating model is Daniel Kade analysis, not a requirement in the draft.

The public error deliberately cannot carry this detail. A rejected request receives invalid_client_attestation without saying whether the cause was a missing endorsement, a disallowed publisher, a key-source disagreement, an ambiguous kid or a transient fetch failure. A fresh attestation cannot fix a policy disagreement, yet the client cannot know that from the response. Privileged telemetry must preserve the cause while the wire error remains opaque.