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

[Dick Hardt]

This proposal allows a distributed RP to securely move an ID Token between
components. How long an SSH session or a web session are relative to the
lifetime of an ID Token is a different matter.



On Thu, Oct 9, 2025 at 8:29 AM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> Thank you for the response.
>
> I believe it's fair to say that OPs inevitably completely lose visibility
> on what's going on with ID Tokens used this way (they are the transport for
> the public key) aren't ATs.
>
> A few more Qs if I may.
>
> What do we do when an application (RP) with bad intentions authenticates a
> user via an OP and right after that, starts forwarding an ID token to sshds
> on the left and right?
>
> How can an OP terminate an SSH session obtained this way? Is that why OP
> Commands are there? Or, should we consider using the backchannel Logout
> Tokens... these won't work well with public /native clients.
>
> What happens when an ID Token expires? SSH sessions, at least in my
> experience, typically live longer. I think I understand well what happens
> in OpenPubkey with that... but unsure if we can accept this answer as is.
>
> My sole intention is only to make the protocols & specs of tomorrow better.
>
> All the best,
> Andrii
>
>
> On Wed, Oct 8, 2025 at 11:37 PM Dick Hardt <dick.hardt at gmail.com> 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?
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251009/117a92a6/attachment.htm>