<div dir="ltr"><div>Standardization of already existing deployed technology is, in my opinion, good. It offers an opportunity to align the community on a more secure, privacy-preserving and interoperable design than what they might have independently come up with.</div><div>I think the use cases mentioned on the list is convincing evidence that the problem targeted by this draft is worth defining a standard solution for.</div><div><br></div><div>I think the newly introduced notions of "RP authenticating component" and "RP consuming component" clarify that the ID tokens is only to be shared within components controlled by the RP.</div><div>The draft would benefit from some additional clarification on these concepts:</div><div><ol><li>Add a definition of them to section 1.2 (Terminology) since they are, AFAICT, new concepts.</li><li>Upper-case the full name of the concepts throughout to clarify that they are defined concepts: "RP Authenticating Component" and "RP Consuming Component".</li><li>Modify section 1.3 (Protocol Profile Overview) to show the two components of the RP and make it clear that only the RP Authenticating Component communicates with the OP.</li></ol>To further clarify that the ID Token is only for "internal" RP use, I think you should expand the note in section 2 (Privacy Considerations) with something like: "The RP Authenticating Component MUST NOT share an ID Token with any component not controlled by the RP."</div><div><br></div><div>Since there has been some confusion about the use case of the draft, I think it would be worthwhile for the authors to sketch out how the "RP Authenticating Component" and "RP Consuming Component" map to at least one use case (such as OpenPubKey, which seems to be the main motivating example?).</div><div>Such a mapping would be a convincing argument that the draft solves the problems you are intending to solve, and would make it easier to "advertise" use cases of the draft to the community post-adoption.</div><div>For instance, I think it would be useful to show how the concepts of "RP Authenticating Component" and "RP Consuming Component" apply to the roles in Figure 7/Figure 11 here:</div><div><a href="https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/">https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/</a></div><div>(If I misunderstood something and this application is not intended to be covered by the draft, please let me know and maybe pick some other representative use case.)</div><div><br></div><div>Cheers,<br>Frederik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Oct 2025 at 06:00, Karl McGuinness via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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="ltr"><div dir="ltr"><div>I support adoption as I see value in adding support for key bound id tokens for the following use cases that I have seen in production </div><div><ul><li>CLI. scripts, and other automation tools that act as the front end to a service that use Device Authorization Grant for example to JIT obtain an ID Token from enterprise IdP with authorization claims and exchange the ID Token with their backend for programmatic access to an API or control plane. AWS, GCP, and Kubectl are examples. The CLI is acting as a part of the RP in these scenarios vs cross-domain. This is very common in the infrastructure and developer tool space where RPs may not always have a browser application (or devs don't use it) or want to unify enterprise authentication between web and programmatic access. It's not common or practical for the enterprise IdP to be the issuer of an access token for these deployments and the backend may not always be an OAuth 2.0 protected resource. </li><li>Native apps that are part of logical application and have a need for<a href="https://developers.google.com/identity/protocols/oauth2/cross-client-identity" target="_blank"> cross-client identity</a> and need to SSO to another component in the logical application.</li><li>Token exchange for public clients with <a href="https://openid.net/specs/openid-connect-native-sso-1_0.html" target="_blank">OpenID Connect Native SSO</a> or OAuth Identity and Authorization Chaining Across Domains/<a href="https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-03.html" target="_blank">ID Assertion Authorization Grant</a> which Aaron had already called out. </li></ul><div>One of the key reasons IMHO for adoption of OIDC in the enterprise has been its adaptability to support for new use cases outside of traditional browser SSO where SAML was not as successful (*cough WS-Trust*). As others have noted, SAML did support an assertion presenter role and holder of key and OIDC does define the azp claim for advanced scenarios.</div><div><br></div><div>My reading of this revision is that it doesn't change the semantics of ID Token but rather enables secure presentation of an ID Token in more complex deployments of an RP that exist today in a single trust domain. The RP is a logical concept which matches my experience with modern application architectures and client experiences. It would be a lot less effort for the ecosystem to adopt key bound id tokens for these use cases with this draft then a new token or protocol.</div></div><div><br></div><div>-Karl</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 2, 2025 at 5:45 AM Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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>
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt">Responding to feedback from the initial call for adoption, the authors of the OpenID Connect Key Binding specification revised it to clear up potential misunderstandings of what the draft does and doesn't
do. The revised specification was submitted to the working group for consideration in the message
<a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-October/011023.html" target="_blank">
https://lists.openid.net/pipermail/openid-specs-ab/2025-October/011023.html</a>.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">This message starts a one-week call for adoption for the revised specification, ending on Thursday, October 9<sup>th</sup>. Even if you responded to the initial call for adoption, please reply to this one
stating your views.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"> Thank you,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"> -- Mike (writing as a Connect WG chair)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></blockquote></div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>