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

[Dick Hardt]

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