<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">I would propose two new names, “jsonld” and “jwt”. The “jwt” claim exists for allowing for a payload with additional claims, which is not supported with nested JWTs, and for allowing for multiple JWTs to be nested inside one (which will have a space penalty).</div><div class=""><br class=""></div><div class="">Specifically for the “jsonld” case: </div><div class=""><br class=""></div><div class="">JSON-LD’s @Context is acting analogous to an XML namespace in the sense that it is defining a new axis for how properties should be interpreted, and without that additional context in mind the data cannot be interpreted as JSON. A non-cached JSON-LD Context document also allows for arbitrary redefining how the data should be interpreted as the context is changed on the network.</div></div><div class=""><br class=""></div><div class="">In this light, the reason to have a vc/vp claims is to isolate the rest of the JWT, which *does* have well-defined and static claim definitions, from the different set of rules that is the JSON-LD. IMHO, there are not enough security considerations around JSON-LD VCs and VPs to treat them as standard JSON data - you need to interpret that data as RDF in tooling.</div><div class=""><br class=""></div>Because of that, the security properties of a JWT should be declared as JWT claims. Merely treating a JWT as an envelope for delivering RDF data should not alter the security posture or interpretation of any other claim that is abiding by JWT rules (or rules of other similarly isolated claims like CNF). If there are properties which do not map from the VC/VP space which are necessary, they should have a JWT standard for them with IANA-registered claims or JOSE header values.<div class=""><div class=""><div class=""><br class=""></div><div class="">Once you strip VC/VP of those responsibilities, I suspect you are just doing one of two things:</div><div class=""><br class=""></div><div class="">1. Using JSON-LD as a way to pass RDF-defined attributes inside a JWT in an isolated manner. As an example, trying to (e.g.) define an @context for the root of the JWT payload to represent it as a VC or VC-adjacent RDF graph would put us in the same undesirable security posture as VCs with LD-Proofs are today - a single set of security-related data which can be interpreted in multiple ways by different tools. Those of us with XML battle scars know the sorts of ways implementers can mess this up, even _with_ properly declared security considerations. This was fixed in DIDs by having JSON and JSON-LD be considered separate formats.</div><div class=""><br class=""></div><div class="">2. Using a JWT as an envelop for LD-Proof signed JSON-LD data. This is appropriate for a verifiable presentation of say an RSA-based proof VC, where the presentation step is more about applying a proof-of-possession than doing any sort of manipulation (selective disclosure, ZKP proof)</div><div class=""><br class=""></div><div class="">I don’t believe _either_ of these are VC or VP related. I can see for instance lab results from SMART on FHIR being secured with one or both of these methods, for instance. We specifically don’t WANT to have JWT validation depend on the semantics of say an embedded VC/VP data set, nor do we want to limit people from having to work within the constraints of the VC data model in order to leverage these techniques.</div><div class=""><br class=""></div><div class=""><div class="">Likewise, I don’t think the claim name should attempt to be a hint for the type of data contained within the claim, because the interpretation of that data is defined by JSON-LD and RDF rules.</div></div><div class=""><br class=""></div><div class="">Note however that there may be additional rules needed for processing the RDF data which are unfortunately not easy to define in either space.</div><div class=""><br class=""></div><div class="">For instance, it might make sense for a value like ‘sub’ or ‘jti’ or ‘iss’ to be treated as the base IRI of the RDF data, but _which_ one is appropriate (or even whether they are required to be declared as a URI value in the JWT claim) is not something we can specify.</div><div class=""><br class=""></div><div class="">Likewise, the VC data may still need to make sure the `sub` in the JWT is a URI which corresponds to the @id of the credentialSubject within the VC. Since the VC data is isolated from the JWT, this may lead for extra processing around the RDF data embedded within a JWT for VC/VP use cases.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2021, at 6:25 PM, Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">In our discussions over the past few months, it’s become clear that there are multiple use cases where different forms of W3C Verifiable Credential objects will be communicated as JWT claims (or as UserInfo Endpoint claims). I had a useful conversation with Oliver Terbu and Kristina Yasuda this week during which we agreed that it would be useful to write a short, focused specification defining and registering JWT claims enabling standard representations for this purpose. These claims could be used both by SIOP use cases and other use cases.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Bear in mind that the W3C Verifiable Credentials specification defines two representations of the objects that it defines – JWT and JSON-LD and it also orthogonally defines two kinds of objects – Verifiable Credentials and Verifiable Presentations. Thus, there are actually four different data types that these use cases might want to utilize.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I would therefore propose the following four claim definitions for these purposes:<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><ul type="disc" style="margin-bottom: 0in; margin-top: 0in;" class=""><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;"><b class=""><span style="font-family: "Courier New";" class="">vc_jwt</span></b>: A claim whose value is a W3C Verifiable Credential object using the JWT representation, which is a JSON string. The claim’s value may also be an array of W3C Verifiable Credential objects using the JWT representation if the use case calls for multiple JWT VCs.<o:p class=""></o:p></li><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;"><b class=""><span style="font-family: "Courier New";" class="">vp_jwt</span></b>: A claim whose value is a W3C Verifiable Presentation object using the JWT representation, which is a JSON string. The claim’s value may also be an array of W3C Verifiable Presentation objects using the JWT representation if the use case calls for multiple JWT VPs.<o:p class=""></o:p></li><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;"><b class=""><span style="font-family: "Courier New";" class="">vc_ld</span></b>: A claim whose value is a W3C Verifiable Credential object using the JSON-LD representation, which is a JSON object. The claim’s value may also be an array of W3C Verifiable Credential objects using the JSON-LD representation if the use case calls for multiple JSON-LD VCs.<o:p class=""></o:p></li><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;"><b class=""><span style="font-family: "Courier New";" class="">vp_ld</span></b>: A claim whose value is a W3C Verifiable Presentation object using the JSON-LD representation, which is a JSON object. The claim’s value may also be an array of W3C Verifiable Presentation objects using the JSON-LD representation if the use case calls for multiple JSON-LD VPs.<o:p class=""></o:p></li></ul><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Let’s discuss this proposal during the European-friendly Connect call ~13.5 hours from now.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> -- Mike<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Openid-specs-ab mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:Openid-specs-ab@lists.openid.net" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Openid-specs-ab@lists.openid.net</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div></blockquote></div><br class=""></div></div></div></body></html>