<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">It is very confusing why some members of this WG are opposed to standardizing and providing guidance on a pattern that is deployed in a non-standard way.<br><br>Ethan is one of the authors of OpenPubKey which puts a public key into a nonce. This is deployed by BastionZero, Docker, and Cloudflare. These companies could have deployed the OpenID Connect UserInfo Verifiable Credentials draft -- but chose not to -- so it failed in the market.</div><div dir="ltr"><br></div><div dir="ltr">This spec is standarding how to do this so that systems are more interoperable, and also provides an opportunity to provide guidance on when this should be used and when it should not be used.<br><br> The push back on this reminds me of why the OpenID Foundation was created -- we continued to get pushback from the IETF to do the OpenID work there -- so took our toys with us to a new sandbox. The response of "we already did this" is clearly not being accepted by the market.<br><br><a href="https://www.bastionzero.com/openpubkey">https://www.bastionzero.com/openpubkey</a><br><a href="https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/">https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/</a><br><a href="https://blog.cloudflare.com/open-sourcing-openpubkey-ssh-opkssh-integrating-single-sign-on-with-ssh/">https://blog.cloudflare.com/open-sourcing-openpubkey-ssh-opkssh-integrating-single-sign-on-with-ssh/</a></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 6:30 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 6:17 PM Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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"><div dir="ltr">I do <b>not </b>support adoption of this draft for the reasons that have been listed by Pieter, Aaron, Justin, Brian, Andrii and Ralph.</div></blockquote><div><br>There are a variety of reasons. You are opposed for all of them?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Key bound ID Tokens using OIDC is where Microsoft and few other companies have started when implementing Verifiable Credentials and OpenID for Verifiable Credential Issuance 1.0 is where all that implementation experience has led. I don't think there is a need to reinvent a wheel when there already is a well-tested final (!) protocol that can be used for this use case. </div></div></blockquote><div><br>Which protocol is that?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>It is also concerning that this call for adoption happened without the topic being mentioned in the DCP WG even once. I am sure DCP WG members would be happy to help and point out extension points in VCI 1.0 that can be leveraged, if needed.</div></div></blockquote><div><br></div><div>Why is that? We don't want a VC. We want an id_token as I have described that has an "aud" value.  </div></div></div>
</blockquote></div>