<div dir="ltr"><div dir="ltr">I don't know the details of how kubeclt -- if it is using the id_token as an access token I would consider that to be problematic.<br><br>I'm unclear what use case there is for a cross domain id_token -- VCs tend to fit that use case much better -- which is quite different than the uses cases we want to use id_token key binding. We really do want an id_token.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Oct 7, 2025 at 2:45 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>Hi Dick and Ethan,<div><br></div><div>Thanks for the updated version. The scope is much more clear in this version.</div><div><br></div><div>In Security Considerations section 3.3 there is a prohibition with using the id_token as an access token. Yet in the kubeclt example that has been mentioned a few times in the email thread, the id_token IS used as an access token. This is driven partly from the existing behavior of stuffing attributes for ABAC and roles for RBAC into the id_token.</div><div><br></div><div>I also believe that there is a need for an identity token that is intended to cross trust-domain boundaries. I’m thinking it may make sense to define a mechanism that serves both the single RP (and its components) as well as the larger use case of crossing trust-domain boundaries. I’d expect that decentralized systems will need this capability (e.g. bluesky).</div><div><br><div><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br>

</div>
<div><br><blockquote type="cite"><div>On Oct 1, 2025, at 7:13 AM, Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Attached is a revised submission in HTML taking into consideration the feedback from the recent call for adoption.<br><br>repo: <a href="https://github.com/dickhardt/openid-key-binding" target="_blank">https://github.com/dickhardt/openid-key-binding</a><br>online html: <a href="https://dickhardt.github.io/openid-key-binding/main.html" target="_blank">https://dickhardt.github.io/openid-key-binding/main.html</a><br><br>The authors would like to thank Jacob for his review and feedback.<div><br></div><div>/Dick & Ethan</div></div></div></div>
<span id="m_4234059076839166262cid:f_mg7w0jdu0"><main.html></span>_______________________________________________<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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div><br></div></div></div></blockquote></div>