<div dir="ltr"><div class="gmail_quote"><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" style="overflow-wrap: break-word;"><div class="gmail-m_-5765211061182017376WordSection1"><p class="MsoNormal"><span style="color:rgb(0,32,96)">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.</span> </p></div></div></blockquote><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" style="overflow-wrap: break-word;"><div class="gmail-m_-5765211061182017376WordSection1"><p class="MsoNormal"><span style="color:rgb(0,32,96)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">Don’t trust the JWT if its cryptographic validation fails.  Don’t trust the cryptographically secured claim value if its cryptographic validation fails.</span></p></div></div></blockquote><div><br></div><div>We're in strong agreement here, and I hope I wasn't implying otherwise or that such a relationship isn't inherent in one security container wrapping another.</div><div><br></div><div>Where I'm struggling is in the instructions to the application in how to process the double-wrapped claims.  I believe those instructions will need to be incredibly specific to the use-case in order to detail the relationship between both of the containers, such as how Identity Assurance has done.</div><div><br></div><div>I don't believe that "vp_" and "vc_" prefixes are sufficient instructions alone to an application developer to indicate how those claims are related to the containing ones.  Additional specifications need to be developed to describe exactly what those relationships mean in a given use-case context (like SIOP or DIF's presentation exchange work).  Without that extra detail I am worried that it's dangerous to try and specify generic claim types, should anyone consider that enough of a standard to implement a custom solution around and miss the important security assumptions.  For example, such as only using the sub of the container and not the contained credential claim, or setting a timer based on only one of the exp values.</div><div><br></div><div>The other part that seems premature is assuming that these additional specs for specific use cases around requesting credentials, aggregating them, issuing them, presenting them, etc will actually be able to use a top level claim.  They very likely will have additional semantics that may best be served by putting any wrapped claims in custom data structures (like "_claims_sources":{"src1":{"JWT":"..."}} for IA).</div><div><br></div><div>While I am always a strong proponent of keeping things as simple as possible and would normally be very excited about this kind of proposal, I'm worried that it could eventually make things more complicated for the cognitive load on app developers and on credential specification work.</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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-5765211061182017376WordSection1"><p class="MsoNormal"><span style="color:rgb(0,32,96)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)">P.S.  I think this is a great discussion and I’m glad we’re having it!</span></p></div></div></blockquote><div><br></div><div>I am too! I'm always happy to be told I'm just being too paranoid or there's prior art/discussion I'm missing :)</div><div><br></div><div>Jer</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>