
<html><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;">Hi<div><br></div><div>I am concerned that this logic is closer to “the SSH system is a single RP because the id_token is shared within that system” rather than “It makes sense to view the sshd as part of the relying party because of how it is constructed (when you exclude what they’re doing with id_tokens), and hence it makes sense to share the id_token between those entities."<br id="lineBreakAtBeginningOfMessage"><div><br></div><div>After having a read of <a href="https://www.bastionzero.com/openpubkey">https://www.bastionzero.com/openpubkey</a> it does sound like the id_token is really being used as some kind of super token being shared with multiple systems (there’s an example of the id_token then effectively being used to sign git commits), and much of this is arguably hidden from the user - the user and IDP authorised a single RP to have the users identity, and this is then being used with multiple parties that don’t have any direct relationship with the original IDP - that seems problematic as, e.g. the IDP has no visibility that these things are happening and no (currently standardised) way to communicate out revocation if a session turns out to be fraudulent etc.</div><div><br></div><div>It does feel a lot like the verifiable credentials ecosystems, but without the clear separation that there is an extra component involved & the behaviour of which is then clearly defined. It feels like trying to pretend these components are all part of the same RP is creating new problems rather than helping us figure out how a good design for these flows could be created.</div><div><br></div><div>Joseph</div><div><br></div><div><br><blockquote type="cite"><div>On 9 Oct 2025, at 07:37, Dick Hardt via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">I consider the SSH system to be a single RP.<br><br>The sshd is relying on the id_token from the OP to determine who the user is. The ssh utility in this case is just an intermediary, and part of the SSH system.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 7:01 AM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com">andrii.deinega@gmail.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="ltr">There’s no confusion (at least for me). I don't consider an application that<br><ol><li>receives an ID Token from an OP, and</li><li>helps the ssh utility in forwarding it to sshd, and</li><li>uses the private key corresponding to the public key (specified in the cnf claim) to establish a SSH session</li></ol>to be different components of the same RP.<br><br>This is one of the use cases standing behind <span id="m_-1045751815295385407:1ng.2" role="menuitem" aria-haspopup="true">OpenPubkey</span>, and what's going there is well described and clearly communicated elsewhere but not in this WG... or, the OpenID Connect Key Binding spec from you.<br><br>I find it to be a clever way to authenticate a user in sshd (or basically, in other services) using OPs but at the same time, I don't think that forwarding (repurposing) existing ID Tokens is the right way to go.<br><br>This is why I kindly asked you to share <br><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">"more or less concrete use cases in this area (maybe... for a bit better transparency in this area)"</blockquote><br>as the very first tiny step.<div><br></div><div>All the best,</div><div>Andrii</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 6, 2025 at 1:07 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.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="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 6, 2025 at 7:56 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.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="ltr">Dick,<div><br></div><div>Do you consider a native OAuth client (which helps the ssh utility to inject and forward an ID Token) and sshd (which retrieves and handles the ID Token) to be two different components of the same RP?</div></div></blockquote><div><br></div><div>This is OpenID Connect, not OAuth, so that is confusing. <br><br>Two different components of the same RP is the use case.</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="ltr"><div><br></div><div>If yes... I'm curious whether, in your opinion, the OP should be aware that the ID Tokens it issues are actually being forwarded and used elsewhere.</div></div></blockquote><div><br></div><div>"used elsewhere" is vague ... Perhaps you can tell me your opinion on the point you are asking? </div></div></div>

</blockquote></div>

</blockquote></div>

_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>https://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></blockquote></div><br></div></body></html>