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

[Andrii Deinega]

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/9d749fe5/attachment-0001.htm>