<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 5, 2025 at 2:46 PM Richard Barnes <<a href="mailto:rlb@ipv.sx" target="_blank">rlb@ipv.sx</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>Hi Mike,</div><div><br></div><div>To be blunt: The relationship between the two drafts is that the approach in the Key Binding draft was considered and rejected by our author team before we put forward the VC-based draft.</div></div></blockquote><div><br></div><div>There was also, for a period, if I recall correctly, consideration of an approach that involved DPoP + a signed userinfo response. For whatever that's worth.</div><div> </div><div><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>I totally understand how the authors arrived at this scheme; it's one I have proposed myself before.  The reason it was abandoned was that Aaron Parecki and some others noted that using the ID token here for anything other than DPoP-authenticated HTTP requests results in the reuse of the DPoP key in different contexts, creating a risk of cross-protocol attacks.  So for example it would be problematic to do BastionZero-like or SigStore-like things with this ID token.  The reason we went the VC route is that VC are intended to be used in different protocols, and you can mint multiple VCs to support different applications.</div><div><br></div><div>You are correct that at this point the UserInfo VC draft is basically abandoned.  But only because there was basically zero OP interest in implementing as far as I could tell.</div></div></blockquote><div><br></div><div>We are definitely interested. The perceived lack of interest is due to other competing factors that I won't bore the list with. But there's interest. Especially if the very logical move away from VCDM and DIDs was to be made and the VCI pieces mature and stabilize. </div><div><br></div><div> </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>  I still think the approach is correct, and the use cases are valuable (including Ethan and Dick's use cases).  If OPs were interested, I would be excited to consume it in Webex.</div><div><br></div><div>If there's new energy here, I would propose we revive the VC draft and rebase it on the latest VCI stuff, probably the simpler SD-JWT-VC stuff out of OAuth rather than anything from W3C.</div></div></blockquote><div><br></div><div>This seems eminently reasonable. The VCI stuff has undergone some changes and is nearing a 1.0 finalization. And SD-JWT VC (maybe even just plain SD-JWT) IMHO is both simpler and more meaningfully feature rich than the W3C VCDM stuff. </div><div><br></div><div> </div></div></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>