<div dir="ltr"><div dir="ltr"><div>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 <a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-September/date.html" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-September/date.html</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 25, 2025 at 8:25 AM Pieter Kasselman <<a href="mailto:prkasselman@gmail.com" target="_blank">prkasselman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Although this is not an area in which I am currently actively working,<br>
I would like to share some perspectives that arose from the process of<br>
creating the UserInfoVC draft that has similar objectives to this<br>
proposed draft.<br>
<br>
As part of creating the UserInfoVC draft, we considered several<br>
options, including approaches like the one proposed in the OpenID<br>
Connect Key Binding draft. Richard mentioned some concerns previously<br>
regarding potential key re-use, especially if the idea is to use the<br>
DPoP mechanisms for generating proof of possession. Another reason for<br>
preferring the VC approach at the time was that it is a credential<br>
format that was designed to be presented to third parties, along with<br>
a suite of specifications specifically for presentation. It avoids<br>
potential confusion that may arise from having a ID Token that may<br>
sometimes be a bearer token (and need "aud" constraints enforced) and<br>
sometimes being a key bound credential that can be presented anywhere<br>
(no "aud" constraints).<br>
<br>
Although I am sympathetic to the simplicity and perceived ease of<br>
adoption/deployment of just adding a cnf claim to an ID token to share<br>
attributes regarding the authentication of the logged in user with<br>
resource servers, using an ID token in the ways proposed may be unsafe<br>
and have unforeseen consequences. I would suggest using mechanisms<br>
that were designed for presentation to third parties.<br>
<br>
<br>
On Wed, Sep 24, 2025 at 8:48 PM Brian Campbell<br>
<<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:<br>
><br>
> I do not believe the Working Group should adopt the OpenID Connect Key Binding draft.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
> On Tue, Sep 23, 2025 at 10:38 AM george--- via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>><br>
>> As per my many comments and emails on this topic…<br>
>><br>
>> 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.<br>
>><br>
>> Not sure if this is helpful to the chairs or not :)<br>
>><br>
>> George Fletcher<br>
>> Identity Standards Architect<br>
>> Practical Identity LLC<br>
>><br>
>><br>
>><br>
>> On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> The specification was contributed at <a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html" rel="noreferrer" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html</a>. 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.<br>
>><br>
>> Writing as a working group chair,<br>
>> -- Mike<br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
> 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.<br>
</blockquote></div></div>
</div>
<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i>