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

[Andrii Deinega]

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/20251008/9133a3cf/attachment.htm>