<div dir="ltr"><div dir="ltr"><snip></div><div dir="ltr"><br></div><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 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 dir="ltr"><div class="gmail_quote"><div>Holder supplied claims, as I indicated in the previous email.<br>Also individual credentials, each which could also have internal disclosures.<br></div></div></div></blockquote><div><br></div><div>None of that needs or even benefits from selective disclosure at the layer of securing Verifiable Presentations.</div></div></div></blockquote><div><br></div><div>The benefit is that if you were only speaking SD-JWT, you don't need another format for presentations... Although, in this case, the only difference might be a trailing tilde on the outermost token.</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 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 dir="ltr"><div class="gmail_quote"><div>And since it's on the horizon, you can nest SD-CWT just as easily as SD-JWT, if not easier because of no string binary inflation.</div><div><br>The argument reduces to an argument against nested tokens, regardless of disclosability... nested tokens have use cases.<br></div></div></div></blockquote><div><br></div><div>That may be an argument to be had but it is absolutely not the one I'm trying to make here. </div></div></div></blockquote><div><br></div><div>I don't think you are arguing this, I think you are presuming it... A VP of a few VCs is simply a nested token with some special claim semantics.<br><br>If you implemented SD-JWT, you already implemented JWT, and therefore you already have to choose the token type for any nesting cases in profiles:<br><br>JWT -> SD-JWT -> JWT ...<br>SD-JWT -> JWT -> SD-JWT ...<br>SD-JWT -> SD-JWT -> SD-JWT ...<br>JWT -> JWT -> JWT ...<br><br>Were it not for the tilde, all of these could have just been the last one, with different crit headers.<br><br>I've taken us off the core issue of VCs and VPs, because I care more about the cryptographic building blocks, than their assembly in a specific W3C profile.<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"><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 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 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 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 dir="ltr"><div class="gmail_quote"><div>As I said over in <a href="https://github.com/w3c/vc-jose-cose/pull/270#issuecomment-2108832855" target="_blank">this PR</a> (which I'm now regretting having gotten involved in),maybe I'm not seeing the grand vision or something but securing a VP with SD-JWT doesn't really make sense to me. </div></div></div></blockquote><div><br>Because VPs don't make sense? or because JWT / COSE is a better path to secure them?<br></div></div></div></blockquote><div><br></div><div>Maybe we are saying the same thing...</div></div></div></blockquote><div><br>I think we might be : )<br></div></div></div></blockquote><div><br></div><div>Maybe? Maybe not? I'm not sure anymore :)<br></div></div></div></blockquote><div><br>I think we agree that VPs are confusing, but we seem to disagree that limiting the securing format for them is less confusing.<br>Perhaps I am biased by my past experience at W3C and other SDOs, where it often takes more text to explain things, and the outcome is not necessarily better clarity.<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"><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 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 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 dir="ltr"><div class="gmail_quote"><div>To me, it's JSON with a media type, I am not sure it needs a grand vision beyond that.<br><br>There are important protocol considerations for VPs though, which are described here:<br><br><a href="https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#presentations-including-holder-claims" target="_blank">https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#presentations-including-holder-claims</a><br><br>You can't have compatibility with this part of the W3C Technical recommendation if you don't enable a way to secure VPs with JWT, SD-JWT, COSE or ...<br></div></div></div></blockquote><div><br></div><div>Again, even to have compatibility with that part of the W3C Technical recommendation or however that is said, specifically the very concept or need to secure VPs with SD-JWT is a piece that seems nonsensical. </div></div></div></blockquote><div><br>If the VCWG sees value in securing holder supplied claims with JWT, I don't see why it would not make sense to secure them with SD-JWT,</div></div></div></blockquote><div><br></div><div>Mostly because it doesn't make sense and there's a real cost to having yet another option in an arena where there are arguably way too many options already.</div></div></div></blockquote><div><br>If you are processing an application/vp+ld+json+jwt (sigh)... of an application/vc+ld+json (data integrity) and an application/vc+ld+json+sd-jwt (sd-jwt+kb) and an application/vc+ld+json+cose....<br>Yes, you're paying (in CPU cycles and CVE attack surface) for the indecision of the W3C VCWG... but I don't think limiting the securing formats of a VP saves you much... That's like $5 off a $10k purchase.<br><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"><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 dir="ltr"><div class="gmail_quote"><div> unless the goal was to show that SD-JWT is less useful for presentations and more useful for credentials... <br></div></div></div></blockquote><div><br></div><div>I have no idea about the goal(s) of the VCWG but SD-JWT is absolutely less useful for presentations and more useful for credentials (at least in the way vc-jose-cose and VCDM seem to be wanting to do things).<br></div></div></div></blockquote><div><br>: ) the purpose of "vc-jose-cose" is to secure the media types defined in the core data model (application/vp+ld+json, and application/vc+ld+json), using the most natural standard cryptographic building blocks from IETF.<br><br>SD-JWT is included because it is presumed to be a future IETF standard with lots of implementations and adoption in use cases that will care about the media types above.<br><br>If a sufficient number of implementers of those use cases showed up to W3C and requested SD-JWT to be limited to credentials, I imagine the W3C Editors would be forced to make those updates.<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"><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 dir="ltr"><div class="gmail_quote"><div>This seems like generic feedback for the VCWG...</div></div></div></blockquote><div><br></div><div>You are right, of course, but I've not found a way to engage with that WG that feels productive. Your email on this thread came across my inbox and it seemed like a decent opportunity in a different forum to try and ask about the motivation/rational behind <a href="https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/#securing-json-ld-verifiable-presentations-with-sd-jwt" target="_blank">3.2.2 Securing JSON-LD Verifiable Presentations with SD-JWT</a>, which I thought you had written. But I just tried to look at some of the associated history in <a href="https://github.com/w3c/vc-jose-cose" target="_blank">https://github.com/w3c/vc-jose-cose</a> and it would seem my assumption of your authorship is wrong. So me asking you to explain something you didn't do doesn't make a lot of sense either. Sorry! At least it adds one more point of confusion to an already confusing thread :)</div></div></div></blockquote><div><br></div><div>I wrote some of the text in those sections, but I don't control the design of the VCWG.<br><br>If I had a magic wand I could wave to help industries adopt digital credentials this is what I would do:<br><br>1. Move the parts of mDoc that are not already at IETF to IETF so people could easily read them.<br>2. Leave SD-JWT where it is, but explain in slightly more detail that it's meant for use cases where CBOR and mDoc can't be used, including cases where the claimset is a special flavor of JSON, or the issuer and verifier ecosystem can't afford to upgrade to CBOR, but holders could benefit from more control and autonomy.<br>3. Have the W3C VCWG only define the structure of credential claimets in JSON-LD, make securing them with COSE a MUST and securing them with SD-JWT a SHOULD, allow other approaches, but make them NOT RECOMMENDED.<br>4. Ship a simpler version of presentation exchange much earlier that worked for SD-JWT and mDoc.<br><br>What makes W3C VCs and VPs confusing is that their scope is large, and there is built in extensibility at every layer, except for JSON-LD (notice the +ld+json on the media types)...<br><br>Identity: Certificates, DID Documents, Issuer/Holder Metadata<br>Credentials: JSON-LD<br>Presentations: JSON-LD<br>Extensions (Schema or Status): JSON-LD<br>Security: DataIntegrity (only for JSON-LD), JWT (only for JSON), SD-JWT  (only for JSON), COSE (could secure other media types, beyond +json), ... (implicitly anything that secures JSON-LD, could be used to create VCs and VPs) </div><div><br>Early versions of vc-jose-cose were just COSE and SD-JWT... JWT was added because selective disclosure appeared to not be an essential requirement, and there were concerns that SD-JWT might not be widely enough adopted to be an easy way to secure the core data model.... We might argue that in 2024 every credential should support selective disclosure and key binding, but I doubt that argument is winnable at W3C.<br><br>W3C WGs have charters that expire, and work needs to be done within the window, this makes coordinating with other organizations potentially difficult, since normative dependencies may not be stable in time for publication, or production rollouts.<br><br>This impacts what is included in the TR, it's often stuff that *might* gain adoption in the gap between chartering (did:web gained adoption between DID Core charters), and it's often framed in such as way that if a few options fail, there is still at least one solution which the market can rely on... at least that's been my observation of W3C DIDs and VCs. <br><br>It will be interesting to see what happens between the current VCWG charter for 2.0 and 3.0... I don't have a crystal ball, but I would suspect there will be more adoption of cose (which is what mdoc is), sd-jwt and data integrity.</div><div><br>Even if there is a "clear winner", some parts of the industry will continue to rely on other formats, I'm still reviewing drafts that rely on XMLDSig at IETF... <br>Perhaps 10 years from now, someone will be sighing and reviewing VPs in SD-JWT format : )<br><br></div><div><snip the rest><br><br>So where does this leave OIDC4VP?<br><br>Any protocol that can carry VCDM v2.0 Verifiable Presentations can carry SD-JWT VPs...<br>Regardless of if that is a thing that makes sense for the use case the protocol is deployed to support.<br><br><a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-03#section-3.2.2.1.1">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-03#section-3.2.2.1.1</a><br><br>Defines the "vct" claim, which expresses the type of verifiable credential, which is analogous to <a href="https://w3c.github.io/vc-data-model/#types">https://w3c.github.io/vc-data-model/#types</a><br><br>AFAIK, there is no "vpt" claim, because as we have discussed, W3C VPs don't make much sense to folks who are not working in JSON-LD.<br><br>Luckily, v2.0 of the VCDM has addressed this problem, by making the payload of an application/vp+ld+json+sd-jwt a media type defined in the core data model: application/vp+ld+json<br><br>So if you wanted to "type" your SD-JWT JSON-LD VP, you can do so using the same approach you would use to "type" your JSON-LD VC.<br><br>DIF presentation exchange already used this mechanism:<br><br><a href="https://identity.foundation/presentation-exchange/#presentation-submission---verifiable-presentation-2">https://identity.foundation/presentation-exchange/#presentation-submission---verifiable-presentation-2</a><br><br>"""<br>{<br>  "@context": [<br>    "<a href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>",<br>    "<a href="https://identity.foundation/presentation-exchange/submission/v1">https://identity.foundation/presentation-exchange/submission/v1</a>"<br>  ],<br>  "type": [<br>    "VerifiablePresentation",<br>    "PresentationSubmission"<br>  ],<br>...<br>"""<br><br>And folks working on supply chain traceability also use this mechanism:<br><br><a href="https://w3c-ccg.github.io/traceability-vocab/#workflow-instance">https://w3c-ccg.github.io/traceability-vocab/#workflow-instance</a><br><br>"""<br>{<br>  "@context": [<br>    "<a href="https://www.w3.org/2018/credentials/v1">https://www.w3.org/2018/credentials/v1</a>",<br>    "<a href="https://w3id.org/traceability/v1">https://w3id.org/traceability/v1</a>"<br>  ],<br>  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",<br>  "type":<br>  [<br>    "VerifiablePresentation",<br>    "TraceablePresentation"<br>  ],<br>"""<br><br>This approach is compatible with one of the original links you provided:<br><br><a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.2.3-5">https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.2.3-5</a><br><br>With the only caveat that "data integrity proofs" are not the only mechanism for securing VCDMv2 conformant Verifiable Presentations, as we've hopefully now demonstrated... for better or worse.<br><br>Happy to answer any questions about this, or if you fear a public list discussion, you may DM me directly.<br><br>Regards,<br><br>OS<br><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:10pt 0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">ORIE STEELE</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap"><br></span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Chief Technology Officer</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span><span style="font-size:8pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">www.transmute.industries</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:0pt 0pt 10pt"><a href="https://transmute.industries" target="_blank"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></a><br></p></span></div></div></div></div></div></div></div>