<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I’m thinking of a use case where one RP in an enterprise wants to communicate the context of the user’s authentication session to another RP in the enterprise. For example, who the user is and how they authenticated, when they last authenticated, etc (i.e. authentication context information). Sharing the id_token across the RPs is outside the scope of this spec and fails when it comes to the audience check. <div><br></div><div>Also, I’m a bit confused by why this needs to be an id_token. My understanding is that the token needs to be issued by the OpenID Provider, contain the user identity (i.e. the `sub` claim), some data about how the user authenticated (password, hardware phishing resistant) and possibly some user attributes. </div><div><br></div><div>In the current spec, sharing all the requested user attributes within the same logical RP still has privacy concerns as all that PII is being shared across multiple systems and any one of those systems being compromised can leak the data so the attack surface for obtaining the PII is much larger. </div><div><br></div><div>Having a dedicated token that contains just the attributes needed by the other components of the RP limits this attack surface. If some of the data being shared across the components of the RP are things like roles or ABAC related attributes, then the id_token is being used for authorization which it seems like section 3.3 is prohibiting.</div><div><div><br></div><div>Am I reading too much into the spec?</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br class="Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On Oct 7, 2025, at 10:40 AM, Dick Hardt <dick.hardt@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><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>
</div></blockquote></div><br></div></div></body></html>