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

Sat Oct 11 02:21:35 UTC 2025

Thanks for your answer Aaron, I think I understand your perspective better.
This sounds like an argument for benefits of OP Commands and for RPs to
robustly support OP commands.

> the team realizes they are getting signed ID tokens from the IDP, and
start sending the ID tokens to the new meeting note app to log in. since
it's a separate app, the meeting notes app creates its own session when
presented with an ID token

Key binding/DPoP helps a little here because the todo app can't simply
replay the ID Token to the note taking app as it can without key binding.

>  Of course this is not best practice, as the meeting notes app should
have been configured as a second OIDC client in the IDP.

Instead of solving this problem by creating a separate audience/client-ids,
why not have the todo list and note app be a single RP and handle OP
commands across todos and notes? For example when I SSO into gitlab with
OIDC, I can use all the gitlab services without having to separately sign
into gitlab operations, gitlab todos, gitlab issues, gitlab workspaces
etc...

On Fri, Oct 10, 2025, 13:12 Aaron Parecki <aaron at parecki.com> wrote:

> So this isn't the scenario I'm talking about, this is an expected
> scenario. I'm talking about an unexpected scenario like the following:
>
> - an internal team builds a custom app to track todo list items and they
> configure it for SSO with the company IDP. The admin create the client ID
> and assign that team to the app
> - the team builds a new custom app to collect meeting notes
> - the team realizes they are getting signed ID tokens from the IDP, and
> start sending the ID tokens to the new meeting note app to log in. since
> it's a separate app, the meeting notes app creates its own session when
> presented with an ID token
>
> Now the admins at the company have no idea that this second meeting notes
> app exists. Let's say they do have some revocation mechanism set up such as
> OP Commands, the IDP would send the command to the todo app. But the IDP
> didn't know about the meeting notes app so doesn't even know it needs to
> tell that app to revoke its sessions too.
>
> Of course this is not best practice, as the meeting notes app should have
> been configured as a second OIDC client in the IDP. But this is exactly the
> kind of thing that happens when the audience of the ID token is ignored or
> "expanded" to include unrelated services.
>
> This example is relatively trivial, but you can imagine it gets worse and
> more complicated when the ID tokens are expanded to uses beyond
> establishing web sessions, such as establishing SSH sessions or signing git
> commits.
>
>
> On Fri, Oct 10, 2025 at 6:10 AM Ethan Heilman <eth3rs at gmail.com> wrote:
>
>> > 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.
>>
>> I want to understand your perspective better here. Can you give a
>> concrete example comparing:
>> -  a public OIDC client used in a webapp
>> - vs. a public OIDC client used by two webapps where both choose to trust
>> the same audience?
>>
>> What does it see or learn in the first case that it can't see or learn in
>> the second case?
>>
>> What actions does the IdP take in the first case that it can't take in
>> the second case?
>>
>>
>> On Thu, Oct 9, 2025 at 7:29 PM Aaron Parecki <aaron at parecki.com> 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251010/4633932b/attachment-0001.htm>