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

Fri Oct 10 17:12:39 UTC 2025

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/86168a8e/attachment-0001.htm>