Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect Key Binding

OpenID Connect Key Binding is a June 2026 OpenID Connect draft for binding a public key to an ID Token so the token can be checked with proof of possession rather than treated as a portable bearer artifact.

Category: Concept / Identity Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OpenID Connect, DPoP, ID Tokens, key binding, AI agent identity, proof of possession

Definition

OpenID Connect Key Binding 1.0 is an OpenID Connect working-group draft by Dick Hardt and Ethan Heilman. Draft 02 was published on June 24, 2026. The draft defines how to bind a public key to an OpenID Connect ID Token using the mechanisms of OAuth DPoP, which RFC 9449 standardized for proof-of-possession OAuth token use.

The problem is familiar in identity systems: a bearer ID Token can be replayed by whoever obtains the token. Key Binding changes the evidence. A relying-party component that received the authentication must also prove it controls the private key corresponding to the public key bound into the token.

The draft is not a finished OpenID Final Specification. It should be cited as a draft profile of OpenID Connect 1.0, the OAuth 2.0 Device Authorization Grant, and DPoP, with details subject to change as the working-group process continues.

How It Works

The draft adds a small set of protocol elements rather than a new identity flow. An OpenID Provider metadata document can advertise support with the bound_key scope and dpop_signing_alg_values_supported. A relying party asks for a key-bound ID Token by including bound_key in the authentication request and sending dpop_jkt, the JWK thumbprint of its proof-of-possession public key.

In the authorization-code flow, the token request includes a DPoP header. The draft adds a c_s256 claim to bind that proof to the authorization code. In the device-authorization flow, the same pattern is used with the device_code. If the OpenID Provider issues the key-bound token, the returned ID Token includes a cnf claim containing the public key and a protected-header type of dpop+id_token.

The draft also covers refresh behavior. A refresh token returned with a key-bound ID Token must remain bound to the same public key, and the OpenID Provider must validate a DPoP proof for that key on refresh. The mechanism by which a relying-party authenticating component proves possession to a consuming component is explicitly out of scope.

Agent Context

Agent systems are likely to contain distributed relying-party components: a user-facing interface, a browser worker, a tool broker, a retrieval service, and one or more backend services that consume authentication evidence. If an ID Token crosses those boundaries as a bearer artifact, logs or compromised components can turn into replay points.

Key-bound ID Tokens are useful where an agent runtime needs to prove both user authentication context and local key possession before another component accepts the token. That is not the same as authorizing an agent action. It only tightens the chain between authentication evidence and the component that received it.

Governance and Safety

The strongest governance value is evidence separation. A log should distinguish the user identity asserted by the ID Token, the relying-party component that holds the key, the DPoP proof used on the exchange, the consuming component that accepted it, and the downstream action. Flattening those facts into "the agent was logged in" erases the boundary Key Binding is meant to clarify.

The security considerations in the draft matter for agent deployments. The consuming component must not trust the cnf claim without a corresponding proof of possession. It must independently verify the ID Token signature, validity, audience, and dpop+id_token type. The draft also says ID Tokens must not be used as access tokens to protected resources.

Key Binding does not solve prompt injection, consent, authorization, or tool policy. If the legitimate key holder signs an unsafe request, the cryptographic checks can still pass. The control reduces replay and confusion; it does not prove that a model made a good decision.

Defense Pattern

Source Discipline

Claims about this topic should name the draft number and publication date. As reviewed for this entry, the current document is OpenID Connect Key Binding 1.0 - draft 02, published June 24, 2026. Do not describe it as an RFC or final OpenID specification.

When comparing it with OAuth DPoP, keep the layer clear: DPoP defines proof-of-possession mechanics; Key Binding profiles those mechanics for OpenID Connect ID Tokens.

Spiralist Reading

Spiralism reads Key Binding as a demand that identity evidence stop wandering alone. A token should not be a loose note saying who someone is. It should carry a cryptographic question: who can still prove custody of the key that received this identity?

For agent systems, that question matters because delegation already blurs user, tool, runtime, and service. Key Binding does not settle authority. It keeps one thread from disappearing.

Open Questions

Sources

Return to Wiki