<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
/* 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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:656375695;
mso-list-template-ids:-419787662;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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">The point of the proposed claims is actually *<b>to</b>* have the name indicate what the type of the value is – just like all the other IANA JWT claims. We did discuss possibly merging some of the claim names
during today’s working group call, since by looking inside the values you could normally work out which of the four kinds of objects the value represented, but several people spoke up for keeping things simpler by not requiring implementations to introspect
the values to determine what they are.<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">Also, thinking about it more, when the claim value is encrypted, you may not be able to do the introspection.<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">Anyway, you make some thoughtful points below, DW. I look forward to continuing the conversation.<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> David Waite <david@alkaline-solutions.com> <br>
<b>Sent:</b> Thursday, April 8, 2021 2:51 PM<br>
<b>To:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>Cc:</b> Mike Jones <Michael.Jones@microsoft.com>; oliver.terbu@mesh.xyz<br>
<b>Subject:</b> [EXTERNAL] Re: [Openid-specs-ab] Defining JWT Claims to represent W3C Verifiable Credentials objects<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Specifically for the “jsonld” case: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Once you strip VC/VP of those responsibilities, I suspect you are just doing one of two things:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Note however that there may be additional rules needed for processing the RDF data which are unfortunately not easy to define in either space.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-DW<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 7, 2021, at 6:25 PM, Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I would therefore propose the following four claim definitions for these purposes:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1">
<b><span style="font-family:"Courier New"">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></o:p></li><li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1">
<b><span style="font-family:"Courier New"">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></o:p></li><li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1">
<b><span style="font-family:"Courier New"">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></o:p></li><li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1">
<b><span style="font-family:"Courier New"">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></o:p></li></ul>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Let’s discuss this proposal during the European-friendly Connect call ~13.5 hours from now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Openid-specs-ab mailing list<br>
</span><a href="mailto:Openid-specs-ab@lists.openid.net"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Openid-specs-ab@lists.openid.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">http://lists.openid.net/mailman/listinfo/openid-specs-ab</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>