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

Mon Oct 6 07:53:49 UTC 2025

Standardization of already existing deployed technology is, in my opinion,
good. It offers an opportunity to align the community on a more secure,
privacy-preserving and interoperable design than what they might have
independently come up with.
I think the use cases mentioned on the list is convincing evidence that the
problem targeted by this draft is worth defining a standard solution for.

I think the newly introduced notions of "RP authenticating component" and
"RP consuming component" clarify that the ID tokens is only to be shared
within components controlled by the RP.
The draft would benefit from some additional clarification on these
concepts:

   1. Add a definition of them to section 1.2 (Terminology) since they are,
   AFAICT, new concepts.
   2. Upper-case the full name of the concepts throughout to clarify that
   they are defined concepts: "RP Authenticating Component" and "RP Consuming
   Component".
   3. Modify section 1.3 (Protocol Profile Overview) to show the two
   components of the RP and make it clear that only the RP Authenticating
   Component communicates with the OP.

To further clarify that the ID Token is only for "internal" RP use, I think
you should expand the note in section 2 (Privacy Considerations) with
something like: "The RP Authenticating Component MUST NOT share an ID Token
with any component not controlled by the RP."

Since there has been some confusion about the use case of the draft, I
think it would be worthwhile for the authors to sketch out how the "RP
Authenticating Component" and "RP Consuming Component" map to at least one
use case (such as OpenPubKey, which seems to be the main motivating
example?).
Such a mapping would be a convincing argument that the draft solves the
problems you are intending to solve, and would make it easier to
"advertise" use cases of the draft to the community post-adoption.
For instance, I think it would be useful to show how the concepts of "RP
Authenticating Component" and "RP Consuming Component" apply to the roles
in Figure 7/Figure 11 here:
https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/
(If I misunderstood something and this application is not intended to be
covered by the draft, please let me know and maybe pick some other
representative use case.)

Cheers,
Frederik

On Mon, 6 Oct 2025 at 06:00, Karl McGuinness via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> I support adoption as I see value in adding support for key bound id
> tokens for the following use cases that I have seen in production
>
>    - CLI. scripts, and other automation tools that act as the front end
>    to a service that use Device Authorization Grant for example to JIT
>    obtain an ID Token from enterprise IdP with authorization claims and
>    exchange the ID Token with their backend for programmatic access to an API
>    or control plane. AWS, GCP, and Kubectl are examples.  The CLI is acting as
>    a part of the RP in these scenarios vs cross-domain.  This is very common
>    in the infrastructure and developer tool space where RPs may not always
>    have a browser application (or devs don't use it) or want to unify
>    enterprise authentication between web and programmatic access. It's not
>    common or practical for the enterprise IdP to be the issuer of an access
>    token for these deployments and the backend may not always be an OAuth 2.0
>    protected resource.
>    - Native apps that are part of logical application and have a need for
>    cross-client identity
>    <https://developers.google.com/identity/protocols/oauth2/cross-client-identity> and
>    need to SSO to another component in the logical application.
>    - Token exchange for public clients with OpenID Connect Native SSO
>    <https://openid.net/specs/openid-connect-native-sso-1_0.html> or OAuth
>    Identity and Authorization Chaining Across Domains/ID Assertion
>    Authorization Grant
>    <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-03.html> which
>    Aaron had already called out.
>
> One of the key reasons IMHO for adoption of OIDC in the enterprise has
> been its adaptability to support for new use cases outside of traditional
> browser SSO where SAML was not as successful (*cough WS-Trust*). As others
> have noted, SAML did support an assertion presenter role and holder of key
> and OIDC does define the azp claim for advanced scenarios.
>
> My reading of this revision is that it doesn't change the semantics of ID
> Token but rather enables secure presentation of an ID Token in more complex
> deployments of an RP that exist today in a single trust domain.  The RP is
> a logical concept which matches my experience with modern application
> architectures and client experiences.  It would be a lot less effort for
> the ecosystem to adopt key bound id tokens for these use cases with this
> draft then a new token or protocol.
>
> -Karl
>
> On Thu, Oct 2, 2025 at 5:45 AM Michael Jones via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Responding to feedback from the initial call for adoption, the authors of
>> the OpenID Connect Key Binding specification revised it to clear up
>> potential misunderstandings of what the draft does and doesn't do.  The
>> revised specification was submitted to the working group for consideration
>> in the message
>> https://lists.openid.net/pipermail/openid-specs-ab/2025-October/011023.html
>> .
>>
>>
>>
>> This message starts a one-week call for adoption for the revised
>> specification, ending on Thursday, October 9th.  Even if you responded
>> to the initial call for adoption, please reply to this one stating your
>> views.
>>
>>
>>
>>                                                                 Thank you,
>>
>>                                 -- Mike (writing as a Connect WG chair)
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> 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/20251006/a2d7f64c/attachment-0001.htm>