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

Dick Hardt dick.hardt at gmail.com
Fri Oct 10 16:45:06 UTC 2025 

Including c_hash binds the DPoP proof to the code -- and the payload in the
token request which also has the code and PKCE -- otherwise there could be
a replay of the DPoP proof.

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

> Thanks Dick!
>
> 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.
>
> Joseph
>
>
> On 10 Oct 2025, at 16:34, Dick Hardt <dick.hardt at gmail.com> wrote:
>
> 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/15466a4e/attachment-0001.htm>

More information about the Openid-specs-ab mailing list