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

[Karl McGuinness]

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