<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#002060">I believe that Tom hit the nail on the head, here. Having a claim in a signed JWT means that the JWT issuer is asserting the claim value pertains to the interaction at hand. If the claim value itself (be it
a JWT, an LD Proof, a SAML Token, etc.) also is cryptographically secured, processing that claim value inherently entails separately validating the cryptographic security of the claim value. This validation is independent of the validation of the JWT itself.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Don’t trust the JWT if its cryptographic validation fails. Don’t trust the cryptographically secured claim value if its cryptographic validation fails.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">P.S. I think this is a great discussion and I’m glad we’re having it!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net>
<b>On Behalf Of </b>Tom Jones via Openid-specs-ab<br>
<b>Sent:</b> Friday, April 9, 2021 12:25 PM<br>
<b>To:</b> Jeremie Miller <jmiller@pingidentity.com><br>
<b>Cc:</b> Tom Jones <thomasclinganjones@gmail.com>; oliver.terbu@mesh.xyz; Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>Subject:</b> [EXTERNAL] Re: [Openid-specs-ab] JWT Claims for W3C Verifiable Credentials Objects<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">i can give you very specific examples of "claims" that are bundled into an id token that have an independent life of their own.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. Claim that is an attestation about the siop wallet itself, which i believe is critical for the success of SIOP.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Claim about the liveness (proof of presence) of an individual, or of a webauth key , etc etc etc<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I find this idea to be difficult, as Jeremie noted, but essential for the future of anything like OIDC.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:black;background:#F2F2F2">Be the change you want to see in the world
</span>..tom<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Apr 9, 2021 at 11:58 AM Jeremie Miller <<a href="mailto:jmiller@pingidentity.com">jmiller@pingidentity.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I'm having a difficult time understanding the security implications with these proposed claims.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Jer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:black;background:#F2F2F2">Be the change you want to see in the world
</span>..tom<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Best wishes,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> -- Mike<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<b><i><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#555555;border:none windowtext 1.0pt;padding:0in">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.</span></i></b><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>