<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;">
Thanks Dick!
<div><br>
</div>
<div>Re: authorization code - I get the how, it’s the “why” I’m struggling with. I think the “to the token request” part probably isn’t quite expressing what was intended or I’m missing what important security property it has. It certainly creates a link between
the authorization code and the dpop proof of possession and hence the underlying key. But that overlaps quite a lot with what PKCE already does, without achieving the session binding that PKCE achieves. I may well be missing something.</div>
<div><br>
</div>
<div>Joseph</div>
<div><br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 10 Oct 2025, at 16:34, Dick Hardt <dick.hardt@gmail.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Thanks for the feedback Joseph!<br>
<br>
RFC 8626 should be RFC 8628 <a href="https://datatracker.ietf.org/doc/html/rfc8628">https://datatracker.ietf.org/doc/html/rfc8628</a> -- apologies for that<br>
<br>
Sorry about the list formatting -- markdown does not always do what I think it will do -- will address.<br>
<br>
"This binds the authorization code to the token request." -- inclusion of the c_hash is what binds the authorization code to the token request -- I can see now that is not clear, we will work on removing tha ambiguity.</div>
<div dir="ltr"><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, Oct 10, 2025 at 3:05 PM Joseph Heenan <<a href="mailto:joseph.heenan@oidf.org">joseph.heenan@oidf.org</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>Hi</div>
<div><br>
</div>
The “id token is then used to sign a git commit" example probably worries me a bit more than the ssh one.
<div><br>
</div>
<div>But the more I think about this, the more this sounds like the issuer - wallet - verifier model. It feels like majority of the problems being solved in that world (credential revocation, presentment to an entity other than the token was issued to, signing,
the new security concerns of a three party model, preventing oversharing of potential PII with selective disclosure/ZKP) also apply here - but with the added problem of using id_tokens for purposes they were never intended for.</div>
<div><br>
</div>
<div>I can see the attractiveness of what is a technically fairly simple protocol change, and maybe a solution something like this is okay in some limited use cases, but I worry we’re opening the floodgates but potentially standardising a mechanism that looks
general purpose but probably isn’t suitable for many purposes.</div>
<div><br>
</div>
<div>Btw: I presume the preference to the (non-existent) RFC8626 in <a href="https://dickhardt.github.io/openid-key-binding/main.html#section-1.6" target="_blank">https://dickhardt.github.io/openid-key-binding/main.html#section-1.6</a> s a mistake, and the
bulleted list at the end of <a href="https://dickhardt.github.io/openid-key-binding/main.html#section-1.8" target="_blank">https://dickhardt.github.io/openid-key-binding/main.html#section-1.8</a> isn’t rendering correctly. I’m also struggling with "This binds
the authorization code to the token request.” - I mean I guess it does do that, but I don’t see why you’d do that or what attack it prevents. It seems like there’s probably something more valuable that is achieved.</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Joseph</div>
<div><br id="m_-4638961892512557642lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 10 Oct 2025, at 14:18, 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">The OpenID Provider Commands `invalidate`[1] command could be used by the OP to invalidate sessions.
<div><br>
</div>
<div>If the sshd was part of system that had an RP Command URI, then it would receive the invalidate commands directly so it could terminate an SSH session</div>
<div><br>
</div>
<div>[1] <a href="https://openid.github.io/openid-provider-commands/main.html" target="_blank">https://openid.github.io/openid-provider-commands/main.html</a></div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct 10, 2025 at 12:29 AM Aaron Parecki 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">The question isn't _how_ to revoke. The problem is the IdP doesn't necessarily know this is happening in the first place, so doesn't even know it needs to revoke that access.
<div><br>
</div>
<div>When an ID token is sent by an RP to some other unrelated component, while the other thing can validate the ID token, the IdP doesn't know it has been sent elsewhere, so doesn't know it might need to clean things up over there. This is precisely what OpenPubKey
seems to suggest with language such as this:</div>
<div><br>
</div>
<div>> Alice can then reveal this ID Token to a third party to prove that she is <a href="mailto:Alice@gmail.com" target="_blank">
Alice@gmail.com</a>. The ID Token functions like an authentication credential.</div>
<div>Source: <a href="https://www.bastionzero.com/blog/generalizing-openpubkey-to-any-identity-provider" target="_blank">https://www.bastionzero.com/blog/generalizing-openpubkey-to-any-identity-provider</a></div>
<div><br>
</div>
<div>Between OpenPubKey doing this in the wild today, and this draft being adopted, the best we can do is give guidance on this kind of scenario. One simple recommendation could be to configure a dedicated RP at the OP for the particular use (SSH vs signing
Docker images for example). I do see this called out in the OpenPubKey README, so is probably worth bringing into this draft in the security considerations. As long as the IdP is aware of what the ID token is being used for, that provides the capability for
it to revoke access in some way.</div>
<div><br>
</div>
<div><a href="https://github.com/openpubkey/opkssh?tab=readme-ov-file#security-note-create-a-new-client-id-for-opkssh" target="_blank">https://github.com/openpubkey/opkssh?tab=readme-ov-file#security-note-create-a-new-client-id-for-opkssh</a></div>
<div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 3:21 PM Ethan Heilman 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">> 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.<br>
<br>
Isn't the standard way to communicate revocation in OpenID Connect to revoke the refresh token? That is, the ID Token expires after 30 seconds to 2 hours depending, then if IDP revokes the refresh token, the ID token can't be refreshed and expires and that
authentication session is no longer valid. This seems like the consensus pattern for revocation.<br>
<br>
The SSH protocol, as far as I am aware, does not support closing existing SSH connections. You can set the SSH certificate to expire when the ID Token expires, but that only prevents creating new SSH connections with that certificate, SSH does not close the
existing connections.<br>
<br>
<div>At Bastion Zero we did extend SSH to have this revocation functionality so that when the user is required to continuously send an unexpired ID Token or the connection closes. Thus, the IDP can revoke all connections opened by the authentication session
by revoking the refresh token associated with that session. I've thought about adding this functionality to OPKSSH, but I haven't seen much demand for it. Most users are comfortable with the current access model provided by SSH.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 1:42 PM Andrii Deinega 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>Dick, I think Joseph communicated this well (a way better than me in one of my
<a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-October/011052.html" target="_blank">
previous</a> responses; English isn't my first language).</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.</blockquote>
<div><br>
</div>
<div>These are two crystal-clear items for me; there are others as well.</div>
<div><br>
</div>
<div>If you wish, I can go ahead and create issues to track those in <a href="https://github.com/dickhardt/openid-key-binding" target="_blank">
https://github.com/dickhardt/openid-key-binding</a>, or other repo if you / we decide to move it under
<a href="https://github.com/openid" target="_blank">https://github.com/openid</a> as per Mike, the OpenID Connect OpenID Connect Key Binding specification was adopted today.</div>
<div><br>
</div>
<div>All the best,</div>
<div>Andrii</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 7:01 AM 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">What do you see as the new problems Joseph?</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 2:57 PM Joseph Heenan <<a href="mailto:joseph@authlete.com" target="_blank">joseph@authlete.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
<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="m_-4638961892512557642m_-7791867305124465269m_7583723736748167839m_-4147747999013335200m_7349304443391071591m_-7075336819650479317m_-4385585469923405232lineBreakAtBeginningOfMessage">
<div><br>
</div>
<div>After having a read of <a href="https://www.bastionzero.com/openpubkey" target="_blank">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 <<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">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">
<div dir="ltr" class="gmail_attr">On Thu, Oct 9, 2025 at 7:01 AM 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">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_-4638961892512557642m_-7791867305124465269m_7583723736748167839m_-4147747999013335200m_7349304443391071591m_-7075336819650479317m_-4385585469923405232m_-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>
<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>
</blockquote>
</div>
</blockquote>
</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>
_______________________________________________<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>
_______________________________________________<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>
_______________________________________________<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>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>