<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 9:01 PM <<a href="mailto:george@practicalidentity.com">george@practicalidentity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Dick,<div><br></div><div>A few thoughts as I’ve read through this thread</div><div><br></div><div>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).</div></div></blockquote><div><br>Why is that? Because the protocol police say so? :)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.<br><br>OAuth 2.0 was based on the patterns deployed at Microsoft, Google, and Yahoo! and added in features that those deployments wanted. <br><br>In contrast, OAuth 1.0 was a clean slate protocol. History shows which approach won. <br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.<br><br>A number of members of the community have expressed interest in using the id_token with key binding as defined. <br><br>Aaron wants the language improved, but my understanding is he wants what is defined normatively.<br><br>Opposition seems to be in one of two buckets:<br><br>- we are the protocol police and we don't like you using an id_token that way because we believe something bad might happen<br><br>- this was already solved with the VC approach <br><br>/Dick</div></div></div>