<div dir="ltr">It;s hard to add much to what Orie says, except these strike me as important.<div><br></div><div><ol><li>The OID4xxx specs do not address the majority uses of the wallet which will be in person.</li><li>The OID4xxx spec is not inclusive, it only appeals to the geek and cannot be used by at least 20% of the population.</li><li>The OID4VP is not workable for the small verifiers who are critical to the success of any wallet.</li></ol></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="-apple-system, system-ui, system-ui, Segoe UI, Roboto, Helvetica Neue, Fira Sans, Ubuntu, Oxygen, Oxygen Sans, Cantarell, Droid Sans, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Lucida Grande, Helvetica, Arial, sans-serif" color="#38761d"><span style="font-size:14px;background-color:rgb(242,242,242)">Peace ..tom jones</span></font></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2024 at 8:53 AM Orie Steele via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<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">Hi all,<br><br>BLUF: I don't think this document is ready to be implemented, or that the working group has addressed the issues necessary to clear a WGLC quality bar, although I readily admit, I am not an active contributor to OIDF working groups.<br><br>My main concern is regarding the vast number of different formats that it aims to support using Presentation Exchange, coupled with the changes that have only recently landed in many of those "formats".<br><br>The essence of this objection is that the document does not describe in sufficient detail what an implementer would need to do, in order to achieve interoperability, and that the document relies on normative references to external specifications which are subject to change, have recently changed, or both.<br><br>See below for details:<br><br><a href="https://github.com/openid/OpenID4VP/pull/297/files#r1821662480" target="_blank">https://github.com/openid/OpenID4VP/pull/297/files#r1821662480</a><br><br>Regarding the use of the "format" selector, which operates on text strings (not media types).<br><br>This recent comment on the RATS list is relevant to that design decision:<br><br><a href="https://mailarchive.ietf.org/arch/msg/rats/rluJsmcttd5i9YWC8LmQwD9yL4A/" target="_blank">https://mailarchive.ietf.org/arch/msg/rats/rluJsmcttd5i9YWC8LmQwD9yL4A/</a><br><br>Changing the allowed values for "format" in a Presentation Definition is a breaking change, because it causes requests that were previously valid to become invalid according to the updated JSON Schema, consider the following updated example from the PR:<br><br>{<br> "definition_id": "example_di_vc",<br> "id": "example_di_vc_presentation_submission",<br> "descriptor_map": [<br> {<br> "id": "id_credential",<br> "path": "$",<br> "format": "di_vp",<br> "path_nested": {<br> "format": "di_vc",<br> "path": "$.verifiableCredential[0]"<br> }<br>}<br><br><br>Here the string "di_vc" matches the media type application/vc (with a data integrity proof implied to be present)<br>The string "di_vp" matches the media type application/vp (with a data integrity proof implied to be present)<br><br>If W3C VCWG had chosen to register media types for VCs and VPs secured with data integrity proofs, those media types could be used here to clearly communicate that these presentation and credential formats are secured with data integrity proofs.<br><br>The group decided to not do that, so "application/vc" and "application/vp" MAY contain "proof" and when present, it is interpreted as a data integrity proof.<br><br>This is of course repeating the mistake of "alg" none for the application/vc and application/vp media types, in just the same way that application/jwt can be "unsecured" using "alg: none" in the header.<br><br>These points regarding W3C media types are not for OIDF DCP to solve, but they create security and interoperability problems if the protocol is aiming to support the W3C VCDMv2.<br><br>I question the accuracy of this "JOSE" example from PR 297:<br><br>{<br> "definition_id": "example_jose_vc",<br> "id": "example_jose_vc_presentation_submission",<br> "descriptor_map": [<br> {<br> "id": "id_credential",<br> "path": "$",<br> "format": "jose_vp",<br> "path_nested": {<br> "path": "$.verifiableCredential[0]",<br> "format": "jose_vc"<br> }<br> }<br> ]<br>}<br><br>Consider a W3C VP in JWT format, containing a VC in JWT format, according to the v2 definitions:<br><br>eyJraWQiOiJrZXktNDIiLCJhbGciOiJFUzM4NCIsInR5cCI6InZwK2p3dCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0sImhvbGRlciI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjoiaHR0cHM6Ly93d3cudzMub3JnL25zL2NyZWRlbnRpYWxzL3YyIiwiaWQiOiJkYXRhOmFwcGxpY2F0aW9uL3ZjK2p3dDtleUpyYVdRaU9pSnJaWGt0TkRJaUxDSmhiR2NpT2lKRlV6TTROQ0lzSW5SNWNDSTZJblpqSzJwM2RDSjkuZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlMQ0pvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2Ym5NdlkzSmxaR1Z1ZEdsaGJITXZaWGhoYlhCc1pYTXZkaklpWFN3aWFXUWlPaUpvZEhSd09pOHZkVzVwZG1WeWMybDBlUzVsZUdGdGNHeGxMMk55WldSbGJuUnBZV3h6THpNM016SWlMQ0owZVhCbElqcGJJbFpsY21sbWFXRmliR1ZEY21Wa1pXNTBhV0ZzSWl3aVJYaGhiWEJzWlVSbFozSmxaVU55WldSbGJuUnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTkxYm1sMlpYSnphWFI1TG1WNFlXMXdiR1V2YVhOemRXVnljeTgxTmpVd05Ea2lMQ0p1WVcxbElqb2lSWGhoYlhCc1pTQlZibWwyWlhKemFYUjVJbjBzSW5aaGJHbGtSbkp2YlNJNklqSXdNVFV0TURVdE1UQlVNVEk2TXpBNk1EQmFJaXdpWTNKbFpHVnVkR2xoYkZOMVltcGxZM1FpT25zaWFXUWlPaUprYVdRNlpYaGhiWEJzWlRwbFltWmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaUxDSmtaV2R5WldVaU9uc2lkSGx3WlNJNklrVjRZVzF3YkdWQ1lXTm9aV3h2Y2tSbFozSmxaU0lzSW5OMVluUjVjR1VpT2lKQ1lXTm9aV3h2Y2lCdlppQlRZMmxsYm1ObElHRnVaQ0JCY25SekluMTlmUS4wMUlDRDVRd2IzR2hWMzFwYktIT2N2SXd4VjJ3eGJuRnZrQ0xFcXNNTFlIdklaaERXYXZSN19nRGhUbk1JU0hGWngtNUI1dk9vcldFOXhYdUszVUtQZjJPNDZqNjd6UVYyVnFQZWp5X2hPWEZvNDJRX0JVRDlYNDA2QXFpb2FRTCIsInR5cGUiOiJFbnZlbG9wZWRWZXJpZmlhYmxlQ3JlZGVudGlhbCJ9XX0.fFEnMO-JjUyfE8zmjla9mVv_5e6hMIY1eUtZUXvoCvYHDfhgL1hb63yyB3TD-ubvXI7eePpYeKAY4lhSQUJI6AdDcOVQi8p8MdkRPT3-H3-lXEa_O4CMl-z3F1xlpb87<br><br><br>This part:<br><br>"path": "$",<br>"format": "jose_vp",<br><br>If the string at $ is actually application/vp+jwt, then format is just an alias for "application/vp+jwt".<br><br>But inside the "path nested" part:<br><br>"path": "$.verifiableCredential[0]",<br>"format": "jose_vc"<br><br>The first element of the "verifiableCredential" property of a decoded application/vp+jwt payload is:<br><br>{<br> "@context": "<a href="https://www.w3.org/ns/credentials/v2" target="_blank">https://www.w3.org/ns/credentials/v2</a>",<br> "id": "data:application/vc+jwt;eyJraWQiOiJrZXktNDIiLCJhbGciOiJFUzM4NCIsInR5cCI6InZjK2p3dCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTUtMDUtMTBUMTI6MzA6MDBaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsInN1YnR5cGUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ.01ICD5Qwb3GhV31pbKHOcvIwxV2wxbnFvkCLEqsMLYHvIZhDWavR7_gDhTnMISHFZx-5B5vOorWE9xXuK3UKPf2O46j67zQV2VqPejy_hOXFo42Q_BUD9X406AqioaQL",<br> "type": "EnvelopedVerifiableCredential"<br>}<br><br>Which implies that "jose_vc" is actually related to the RDF type "EnvelopedVerifiableCredential"... and not the media type "data:application/vc+jwt".<br><br>As an aside, I don't know what media type you would use to assign to the JSON object shown above, but application/json or application/ld+json seem like possibilities.<br><br><b><i>I realize these are problems with presentation exchange and the w3c vcdmv2, and not necessarily openid for vp</i></b>, but it MUST be clear how to parse the outer and inner media types, to get to JSON elements, or the entire point of presentation exchange as a specification is lost... and openid 4 vp does not provide any interoperability, without heavy profiling.<br><br>Regarding the W3C VCDM, in a general sense, you have media types for "secured objects" like application/vc+jwt or application/vp+jwt... and after verifying them and decoding and parsing their payload, you end with application/vc or application/vp, which in turn can contain RDF graph node id's that contain data uri's, that can contain more "secured objects".<br><br>There is even a brand new invention called "EnvelopedPresentations" - <a href="https://www.w3.org/TR/vc-data-model-2.0/#enveloped-verifiable-presentations" target="_blank">https://www.w3.org/TR/vc-data-model-2.0/#enveloped-verifiable-presentations</a><br><br>This "nesting / enveloping / decoding" structure needs to be accounted for in presentation definitions, or you cannot select claims from credentials...<br><br>Using the example I gave above, here is some awkward syntax highlighting how you might obtain a claim from a credential inside that specific application/vp+jwt:<br><br>decodeJwt ( decodeDataUri( decodeJwt(vp_jwt).payload.verifiableCredential[0].id ) ).credentialSubject.degree.subtype -> Bachelor of Science and Arts<br><br>... if for some reason, someone decided to send the "vp_jwt" inside an application/vp as an "Enveloped Presentation"... You would need to add another layer of parsing JSON and decoding Data URIs.<br><br>After thinking about this for a bit, I don't see how the current Presentation Definitions can support the VCDM v2 data model without changes to both the "path" and "format" parameters.<br><br>If OIDC4VP was limited to a few mandatory to implement media types, the combinatorics problems implied by the above text would be substantially reduced, interoperability would be massively improved, and perhaps the limitations of "path" and "format" would not be so catastrophic.<br><br>I would propose the only allowed formats be "sd_jwt / application/sd-jwt" or more specific subtypes and "whatever media type / format is used for mDocs".... and make one of them mandatory and the other optional.<br><br>Another solution could be to simply <b><i>provide correct complete concrete examples for as many media types as the group knows the protocol needs to support</i></b>... which seems to be the direction that PR 297 is headed... in which case, I think there is still a lot of ground to cover before the document is ready for implementation... and the new concepts of "EnvelopedVerifiableCredential" and "EnvelopedPresentations" need to be addressed, or the W3C VCDMv2 examples need to be removed.<br><br>Pretending that the protocol supports the W3C VCDMv2 will do more damage in the long run, than being clear that the protocol does not support that data model currently, and leaving the changes necessary to support it to future work.<br><br>I'd recommend reducing scope, and getting full coverage for supported "formats" or "media types", and then asking implementers to confirm support for mandatory and optional formats.<br><br>If the document proceeds with the current range of formats, please consider reducing them before final publication, and expect a similar objection citing this thread if that is not the case.<br><br>Regards,<br><br>OS<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2024 at 3:30 PM Micha Kraus via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I support starting the Implementer's draft approval process.<br>
<br>
Thanks,<br>
Micha<br>
<br>
Am 28.10.2024 08:39 schrieb Pedro Felix via <br>
Openid-specs-digital-credentials-protocols:<br>
> I support starting the Implementer's draft approval process.<br>
> <br>
> Regards,<br>
> <br>
> Pedro<br>
> <br>
> On Mon, Oct 28, 2024 at 2:00 AM Tobias Looker via<br>
> Openid-specs-digital-credentials-protocols<br>
> <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br>
> <br>
>> I support starting the Implementer's draft approval process.<br>
>> <br>
>> Thanks,<br>
>> <br>
>> [2]<br>
>> <br>
>> TOBIAS LOOKER<br>
>> <br>
>> MATTR<br>
>> <br>
>> +64 273 780 461<br>
>> tobias.looker@mattr.global<br>
>> <br>
>> [2]<br>
>> <br>
>> [3]<br>
>> <br>
>> [4]<br>
>> <br>
>> [5]<br>
>> <br>
>> This communication, including any attachments, is confidential. If<br>
>> you are not the intended recipient, you should not read it –<br>
>> please contact me immediately, destroy it, and do not copy or use<br>
>> any part of this communication or disclose anything about it. Thank<br>
>> you. Please note that this communication does not designate an<br>
>> information system for the purposes of the Electronic Transactions<br>
>> Act 2002.<br>
>> <br>
>> FROM: Openid-specs-digital-credentials-protocols<br>
>> <br>
> <<a href="mailto:openid-specs-digital-credentials-protocols-bounces@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols-bounces@lists.openid.net</a>><br>
>> on behalf of torsten--- via<br>
>> Openid-specs-digital-credentials-protocols<br>
>> <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br>
>> DATE: Saturday, 26 October 2024 at 10:19 PM<br>
>> TO: <a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
>> <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>,<br>
>> Digital Credentials Protocols List<br>
>> <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br>
>> CC: <a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a> <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br>
>> SUBJECT: Re: [Openid-specs-digital-credentials-protocols] FW:<br>
>> Working group last call for proposed OpenID4VP Implementer's Draft<br>
>> <br>
>> EXTERNAL EMAIL: This email originated outside of our organisation.<br>
>> Do not click links or open attachments unless you recognise the<br>
>> sender and know the content is safe.<br>
>> <br>
>> +1<br>
>> <br>
>> Am 26. Okt. 2024, 10:54 +0200 schrieb Paul Bastian via<br>
>> Openid-specs-digital-credentials-protocols<br>
>> <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>:<br>
>> <br>
>>> I support commencing the Implementer’s draft approval process.<br>
>>> <br>
>>> Paul<br>
>>> --<br>
>>> Openid-specs-digital-credentials-protocols mailing list<br>
>>> <a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
>>> <br>
>> <br>
> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
>>> [1]<br>
>> --<br>
>> Openid-specs-digital-credentials-protocols mailing list<br>
>> <a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
>> <br>
> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
>> [1]<br>
> <br>
> <br>
> Links:<br>
> ------<br>
> [1]<br>
> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
> [2] <a href="https://mattr.global/" rel="noreferrer" target="_blank">https://mattr.global/</a><br>
> [3] <a href="https://www.linkedin.com/company/mattrglobal" rel="noreferrer" target="_blank">https://www.linkedin.com/company/mattrglobal</a><br>
> [4] <a href="https://twitter.com/mattrglobal" rel="noreferrer" target="_blank">https://twitter.com/mattrglobal</a><br>
> [5] <a href="https://github.com/mattrglobal" rel="noreferrer" target="_blank">https://github.com/mattrglobal</a><br>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote></div><br clear="all"><div><br></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>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote></div>