<div dir="ltr">i can give you very specific examples of "claims" that are bundled into an id token that have an independent life of their own.<div><br></div><div>1. Claim that is an attestation about the siop wallet itself, which i believe is critical for the success of SIOP.</div><div>2. Claim about the liveness (proof of presence) of an individual, or of a webauth key , etc etc etc</div><div>3. Claim about the identity proofing of the individual, which can be a mobile driver's license or a statement of an existing proofed identity at (e.g.) a bank or a primary care physician.</div><div><br></div><div>I find this idea to be difficult, as Jeremie noted, but essential for the future of anything like OIDC.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 11:58 AM Jeremie Miller <<a href="mailto:jmiller@pingidentity.com">jmiller@pingidentity.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">I'm having a difficult time understanding the security implications with these proposed claims.<div><br></div><div>When I am writing an application that processes a JWT that has been validated by my JOSE library, I then process the contained claims in the security context that was just validated (by the issuer, for an audience, about a subject, etc). The moment I encounter _any_ claim that is itself _another_ clearly identified and self-contained security context, there needs to be extremely specific rules about how those two different contexts relate to each other.</div><div><br></div><div>If the new context is from a different issuer, is this an aggregation? Is there an implication from the parent issuer having signed it providing any assurance or binding? See the Identity Assurance draft for all the extra framework metadata that is required in that particular case: <a href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html" target="_blank">https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html</a></div><div><br></div><div>What if the new claim has a longer expiration? Which is valid? Or for a different subject, are they linked? It's a claim containing new claims, and I struggle to imagine all of the ways the two might intersect and how I as the application developer could properly evaluate that without very specific guidance and extra information from a spec.</div><div><br></div><div>Just adding standard claim names to support this pattern seems like it is dismissing the very important security complexity of mixing claims with two potentially drastically different envelopes. Leaving that up to future spec writers to solve feels like handing off an armed grenade.</div><div><br></div><div>Without doing the work like Identity Assurance to clearly define the relationship between the different contexts, I'm concerned that an over-simplified inclusion can lead to over-simplified security assumptions.</div><div><br></div><div>Personally, I believe credentials are most securely returned from an issuer each as their own individual envelopes of claims, and any need to bind them together should be intrinsic to each. That would also require successful validation of all envelopes before evaluating any relationships between them, a very good thing IMO.</div><div><br></div><div>Jer</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 11:14 AM Tom 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></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">This proposal is conceptually incomplete. We need to start with the AR with new request elements, go through the consent process and finally process those 2 inputs into (inter alia) an id token.<div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 8, 2021 at 11:10 PM Mike 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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">I have written the first draft of the promised specification, which is both attached (to contribute it to the working group) and available online at
<a href="https://openid.bitbucket.io/connect/jwt-claims-for-vc-objects-1_0.html" target="_blank">
https://openid.bitbucket.io/connect/jwt-claims-for-vc-objects-1_0.html</a>. The source is also checked into our bitbucket repository.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I intend this to further concrete discussions on how to interoperably include VC objects in the JWT claims world, when appropriate to the use cases.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> Best wishes,<u></u><u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
_______________________________________________<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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
_______________________________________________<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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></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></blockquote></div>