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

[Andrii Deinega]

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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251009/10b3e6f7/attachment.htm>