<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Dick,<div><br></div><div>A few thoughts as I’ve read through this thread</div><div><br></div><div>1. Just because a company deploys something doesn’t, by virtual of the deployment, make it a good idea. Fundamentally, id_tokens, if transferred outside the context of the workload to which it was issued, should ONLY be sent to the identity provider that issued the id_token (e.g. id_token_hint in OpenID Connect Core).</div><div><br></div><div>2. It seems that this spec is not about trying to determine the best way to provide an identity assertion that is transferable to other parties, but rather to “standardize” something that is already deployed. Standards should determine the best, most correct, way to accomplish something, not just “stamp” existing deployments.</div><div><br></div><div>3. Modifying the proposed standard to return a token that is specific to the purpose desired by the receiving workload is not that hard. Using a flow like ID-JAG would accomplish this and remove any of the issues identified by many regarding the current proposed use of the id_token. It’s unclear to me why this isn’t a viable option.</div><div><br></div><div>Thanks,</div><div>George</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">--<div>George Fletcher</div><div>Practical Identity LLC</div></div><div dir="ltr"><br><blockquote type="cite">On Sep 29, 2025, at 2:30 PM, Dick Hardt via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><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>
<span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span>Openid-specs-ab@lists.openid.net</span><br><span>https://lists.openid.net/mailman/listinfo/openid-specs-ab</span><br></div></blockquote></div></body></html>