[Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification

Dick Hardt dick.hardt at gmail.com
Fri Oct 10 15:34:30 UTC 2025 

Thanks for the feedback Joseph!

RFC 8626 should be RFC 8628 https://datatracker.ietf.org/doc/html/rfc8628
-- apologies for that

Sorry about the list formatting -- markdown does not always do what I think
it will do -- will address.

"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.


On Fri, Oct 10, 2025 at 3:05 PM Joseph Heenan <joseph.heenan at oidf.org>
wrote:

> Hi
>
> The “id token is then used to sign a git commit" example probably worries
> me a bit more than the ssh one.
>
> 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.
>
> 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.
>
> Btw: I presume the preference to the (non-existent) RFC8626 in
> https://dickhardt.github.io/openid-key-binding/main.html#section-1.6 s a
> mistake, and the bulleted list at the end of
> https://dickhardt.github.io/openid-key-binding/main.html#section-1.8 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.
>
> Thanks
>
> Joseph
>
>
> On 10 Oct 2025, at 14:18, Dick Hardt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> The OpenID Provider Commands `invalidate`[1] command could be used by the
> OP to invalidate sessions.
>
> 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
>
> [1] https://openid.github.io/openid-provider-commands/main.html
>
> On Fri, Oct 10, 2025 at 12:29 AM Aaron Parecki via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> 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.
>>
>> 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:
>>
>> > Alice can then reveal this ID Token to a third party to prove that she
>> is Alice at gmail.com. The ID Token functions like an authentication
>> credential.
>> Source:
>> https://www.bastionzero.com/blog/generalizing-openpubkey-to-any-identity-provider
>>
>> 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.
>>
>>
>> https://github.com/openpubkey/opkssh?tab=readme-ov-file#security-note-create-a-new-client-id-for-opkssh
>>
>>
>> On Thu, Oct 9, 2025 at 3:21 PM Ethan Heilman via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> > 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> On Thu, Oct 9, 2025 at 1:42 PM Andrii Deinega via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> Dick, I think Joseph communicated this well (a way better than me in
>>>> one of my previous
>>>> <https://lists.openid.net/pipermail/openid-specs-ab/2025-October/011052.html>
>>>> responses; English isn't my first language).
>>>>
>>>> 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.
>>>>
>>>>
>>>> These are two crystal-clear items for me; there are others as well.
>>>>
>>>> If you wish, I can go ahead and create issues to track those in
>>>> https://github.com/dickhardt/openid-key-binding, or other repo if you
>>>> / we decide to move it under https://github.com/openid as per Mike,
>>>> the OpenID Connect OpenID Connect Key Binding specification was adopted
>>>> today.
>>>>
>>>> All the best,
>>>> Andrii
>>>>
>>>>
>>>> On Thu, Oct 9, 2025 at 7:01 AM Dick Hardt <dick.hardt at gmail.com> wrote:
>>>>
>>>>> What do you see as the new problems Joseph?
>>>>>
>>>>> On Thu, Oct 9, 2025 at 2:57 PM Joseph Heenan <joseph at authlete.com>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> 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."
>>>>>>
>>>>>> After having a read of https://www.bastionzero.com/openpubkey 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Joseph
>>>>>>
>>>>>>
>>>>>> On 9 Oct 2025, at 07:37, Dick Hardt via Openid-specs-ab <
>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>
>>>>>> I consider the SSH system to be a single RP.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> On Thu, Oct 9, 2025 at 7:01 AM Andrii Deinega <
>>>>>> andrii.deinega at gmail.com> wrote:
>>>>>>
>>>>>>> There’s no confusion (at least for me). I don't consider an
>>>>>>> application that
>>>>>>>
>>>>>>>    1. receives an ID Token from an OP, and
>>>>>>>    2. helps the ssh utility in forwarding it to sshd, and
>>>>>>>    3. uses the private key corresponding to the public key
>>>>>>>    (specified in the cnf claim) to establish a SSH session
>>>>>>>
>>>>>>> to be different components of the same RP.
>>>>>>>
>>>>>>> This is one of the use cases standing behind OpenPubkey, 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> This is why I kindly asked you to share
>>>>>>>
>>>>>>> "more or less concrete use cases in this area (maybe... for a bit
>>>>>>> better transparency in this area)"
>>>>>>>
>>>>>>>
>>>>>>> as the very first tiny step.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Andrii
>>>>>>>
>>>>>>> On Mon, Oct 6, 2025 at 1:07 PM Dick Hardt <dick.hardt at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Oct 6, 2025 at 7:56 PM Andrii Deinega <
>>>>>>>> andrii.deinega at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Dick,
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is OpenID Connect, not OAuth, so that is confusing.
>>>>>>>>
>>>>>>>> Two different components of the same RP is the use case.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> "used elsewhere" is vague ... Perhaps you can tell me your opinion
>>>>>>>> on the point you are asking?
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251010/f88db1fb/attachment-0001.htm>

More information about the Openid-specs-ab mailing list