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

Brian Campbell bcampbell at pingidentity.com
Mon Sep 29 11:45:11 UTC 2025


It looks like I received this from Pieter because I was a direct addressee
of the reply but, presumably caught up in moderation somewhere, it doesn't
appear to have been delivered to the list
https://lists.openid.net/pipermail/openid-specs-ab/2025-September/date.html

On Thu, Sep 25, 2025 at 8:25 AM Pieter Kasselman <prkasselman at gmail.com>
wrote:

> Although this is not an area in which I am currently actively working,
> I would like to share some perspectives that arose from the process of
> creating the UserInfoVC draft that has similar objectives to this
> proposed draft.
>
> As part of creating the UserInfoVC draft, we considered several
> options, including approaches like the one proposed in the OpenID
> Connect Key Binding draft. Richard mentioned some concerns previously
> regarding potential key re-use, especially if the idea is to use the
> DPoP mechanisms for generating proof of possession. Another reason for
> preferring the VC approach at the time was that it is a credential
> format that was designed to be presented to third parties, along with
> a suite of specifications specifically for presentation. It avoids
> potential confusion that may arise from having a ID Token that may
> sometimes be a bearer token (and need "aud" constraints enforced) and
> sometimes being a key bound credential that can be presented anywhere
> (no "aud" constraints).
>
> Although I am sympathetic to the simplicity and perceived ease of
> adoption/deployment of just adding a cnf claim to an ID token to share
> attributes regarding the authentication of the logged in user with
> resource servers, using an ID token in the ways proposed may be unsafe
> and have unforeseen consequences. I would suggest using mechanisms
> that were designed for presentation to third parties.
>
>
> On Wed, Sep 24, 2025 at 8:48 PM Brian Campbell
> <bcampbell at pingidentity.com> wrote:
> >
> > I do not believe the Working Group should adopt the OpenID Connect Key
> Binding draft.
> >
> > I find that this document is conceptually duplicative of much of the
> existing Working Group's efforts on the OpenID Connect UserInfo Verifiable
> Credentials (VC) document. Richard, one of the authors of the UserInfo VC
> draft, recently proposed reviving that draft and rebasing it on the latest
> OpenID4VCI and the simpler SD-JWT VC token construct. I previously
> expressed my support for that proposal on the mailing list, and I reiterate
> that support now.
> >
> > Even if some authors and contributors to the UserInfo VC work have
> shifted their focus, I believe the Working Group should not discard or
> disregard that existing work by adopting a duplicative specification. At a
> minimum, there should be a clear attempt at collaboration or reconciliation
> between these efforts before proceeding with adoption.
> >
> >
> > On Tue, Sep 23, 2025 at 10:38 AM george--- via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >>
> >> As per my many comments and emails on this topic…
> >>
> >> I am in favor of providing a mechanisms for Relying Parties to be able
> to share attributes regarding the authentication of the logged in user with
> downstream systems (e.g. resource servers). I am not in favor of using an
> id_token to communicate this information.
> >>
> >> Not sure if this is helpful to the chairs or not :)
> >>
> >> George Fletcher
> >> Identity Standards Architect
> >> Practical Identity LLC
> >>
> >>
> >>
> >> On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >>
> >> This starts a two-week call for feedback on whether to adopt the OpenID
> Connect OpenID Connect Key Binding specification contributed to the working
> group by Dick Hardt and Ethan Heilman as an OpenID Connect Working Group
> specification.  Please reply-all by Monday, September 29, 2025 saying
> whether you are favor of adoption or not, also saying why.
> >>
> >> The specification was contributed at
> https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html.
> It has been extensively discussed by the working group both on calls and on
> the mailing list.  From my observations of the discussion as a working
> group chair, I believe that there is consensus that it would be useful to
> have a standard solving the problem addressed by this specification.
> >>
> >>                                                 Writing as a working
> group chair,
> >>                                                                 -- Mike
> >>
> >> _______________________________________________
> >> 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
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250929/ed80bfbd/attachment-0001.htm>


More information about the Openid-specs-ab mailing list