[Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification

[Dick Hardt]

On Mon, Sep 29, 2025 at 9:01 PM <george at practicalidentity.com> wrote:

> Hi Dick,
>
> A few thoughts as I’ve read through this thread
>
> 1. Just because a company deploys something doesn’t, by virtual of the
> deployment, make it a good idea. Fundamentally, id_tokens, if transferred
> outside the context of the workload to which it was issued, should ONLY be
> sent to the identity provider that issued the id_token (e.g. id_token_hint
> in OpenID Connect Core).
>

Why is that? Because the protocol police say so? :)


>
> 2. It seems that this spec is not about trying to determine the best way
> to provide an identity assertion that is transferable to other parties, but
> rather to “standardize” something that is already deployed. Standards
> should determine the best, most correct, way to accomplish something, not
> just “stamp” existing deployments.
>

Standardize a solution for a problem that many people have that are working
around current standards. I take it as a signal that there is market
demand, and a signal that the userinfo VC approach was not an acceptable
solution to the problem. These deployments have been out for a long time,
which is a signal that they work, and have not needed to be reworked due to
a security issue.

OAuth 2.0 was based on the patterns deployed at Microsoft, Google, and
Yahoo! and added in features that those deployments wanted.

In contrast, OAuth 1.0 was a clean slate protocol. History shows which
approach won.



>
> 3. Modifying the proposed standard to return a token that is specific to
> the purpose desired by the receiving workload is not that hard. Using a
> flow like ID-JAG would accomplish this and remove any of the issues
> identified by many regarding the current proposed use of the id_token. It’s
> unclear to me why this isn’t a viable option.
>

You might have some of my messages in the thread. As we have reflected on
the problem, the mental model we have is that the id_token with key binding
is being exchanged between different components of the same RP. We want all
components to verify that the "aud" value is the correct value. Many
systems pass around an id_token between components today as a bearer token
-- we are providing a mechanism for that exchange to have dpop.

A number of members of the community have expressed interest in using the
id_token with key binding as defined.

Aaron wants the language improved, but my understanding is he wants what is
defined normatively.

Opposition seems to be in one of two buckets:

- we are the protocol police and we don't like you using an id_token that
way because we believe something bad might happen

- this was already solved with the VC approach

/Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250930/26cc80d1/attachment-0001.htm>