[Openid-specs-digital-credentials-protocols] FW: Working group last call for proposed OpenID4VP Implementer's Draft
Orie Steele
orie at transmute.industries
Tue Nov 12 23:07:06 UTC 2024
The main issue is what starts on this thread here:
https://github.com/openid/OpenID4VP/pull/297/files#r1838819835
I don't know if there is energy or agreement to make changes to the format
parameter... to align it with media types, or to establish a registry for
it, or to simply stick with the current string representations.
The other issue is regarding "enveloped" credentials and presentations.
I left a related comment here already:
https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20241028/000525.html
Depending on how the group plans to address format, it might be easier to
address the "enveloped" topic.
At a minimum, the group would need to explain how to parse data URIs that
match media types, and how this is related to "format"... in order for W3C
VCDMv2 credentials to make sense.
If the goal is to support the W3C VCDMv2... it will probably take several
PRs, and I might recommend merging 297 as a starting point.
OS
On Tue, Nov 12, 2024 at 4:06 PM Michael Jones <michael_b_jones at hotmail.com>
wrote:
> Hi Orie,
>
>
>
> On today’s DCP call, I agree to take over as owner of
> https://github.com/openid/OpenID4VP/pull/297 while Gabe has other fish to
> fry. Could you make change suggestions in the PR to address the issues you
> raise below?
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols-bounces at lists.openid.net> *On
> Behalf Of *Orie Steele via Openid-specs-digital-credentials-protocols
> *Sent:* Thursday, October 31, 2024 8:53 AM
> *To:* Digital Credentials Protocols List <
> openid-specs-digital-credentials-protocols at lists.openid.net>
> *Cc:* Orie Steele <orie at transmute.industries>
> *Subject:* Re: [Openid-specs-digital-credentials-protocols] FW: Working
> group last call for proposed OpenID4VP Implementer's Draft
>
>
>
> Hi all,
>
> 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.
>
> 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".
>
> 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.
>
> See below for details:
>
> https://github.com/openid/OpenID4VP/pull/297/files#r1821662480
>
> Regarding the use of the "format" selector, which operates on text strings
> (not media types).
>
> This recent comment on the RATS list is relevant to that design decision:
>
> https://mailarchive.ietf.org/arch/msg/rats/rluJsmcttd5i9YWC8LmQwD9yL4A/
>
> 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:
>
> {
> "definition_id": "example_di_vc",
> "id": "example_di_vc_presentation_submission",
> "descriptor_map": [
> {
> "id": "id_credential",
> "path": "$",
> "format": "di_vp",
> "path_nested": {
> "format": "di_vc",
> "path": "$.verifiableCredential[0]"
> }
> }
>
>
> Here the string "di_vc" matches the media type application/vc (with a data
> integrity proof implied to be present)
> The string "di_vp" matches the media type application/vp (with a data
> integrity proof implied to be present)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> I question the accuracy of this "JOSE" example from PR 297:
>
> {
> "definition_id": "example_jose_vc",
> "id": "example_jose_vc_presentation_submission",
> "descriptor_map": [
> {
> "id": "id_credential",
> "path": "$",
> "format": "jose_vp",
> "path_nested": {
> "path": "$.verifiableCredential[0]",
> "format": "jose_vc"
> }
> }
> ]
> }
>
> Consider a W3C VP in JWT format, containing a VC in JWT format, according
> to the v2 definitions:
>
>
> eyJraWQiOiJrZXktNDIiLCJhbGciOiJFUzM4NCIsInR5cCI6InZwK2p3dCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0sImhvbGRlciI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjoiaHR0cHM6Ly93d3cudzMub3JnL25zL2NyZWRlbnRpYWxzL3YyIiwiaWQiOiJkYXRhOmFwcGxpY2F0aW9uL3ZjK2p3dDtleUpyYVdRaU9pSnJaWGt0TkRJaUxDSmhiR2NpT2lKRlV6TTROQ0lzSW5SNWNDSTZJblpqSzJwM2RDSjkuZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlMQ0pvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2Ym5NdlkzSmxaR1Z1ZEdsaGJITXZaWGhoYlhCc1pYTXZkaklpWFN3aWFXUWlPaUpvZEhSd09pOHZkVzVwZG1WeWMybDBlUzVsZUdGdGNHeGxMMk55WldSbGJuUnBZV3h6THpNM016SWlMQ0owZVhCbElqcGJJbFpsY21sbWFXRmliR1ZEY21Wa1pXNTBhV0ZzSWl3aVJYaGhiWEJzWlVSbFozSmxaVU55WldSbGJuUnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTkxYm1sMlpYSnphWFI1TG1WNFlXMXdiR1V2YVhOemRXVnljeTgxTmpVd05Ea2lMQ0p1WVcxbElqb2lSWGhoYlhCc1pTQlZibWwyWlhKemFYUjVJbjBzSW5aaGJHbGtSbkp2YlNJNklqSXdNVFV0TURVdE1UQlVNVEk2TXpBNk1EQmFJaXdpWTNKbFpHVnVkR2xoYkZOMVltcGxZM1FpT25zaWFXUWlPaUprYVdRNlpYaGhiWEJzWlRwbFltWmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaUxDSmtaV2R5WldVaU9uc2lkSGx3WlNJNklrVjRZVzF3YkdWQ1lXTm9aV3h2Y2tSbFozSmxaU0lzSW5OMVluUjVjR1VpT2lKQ1lXTm9aV3h2Y2lCdlppQlRZMmxsYm1ObElHRnVaQ0JCY25SekluMTlmUS4wMUlDRDVRd2IzR2hWMzFwYktIT2N2SXd4VjJ3eGJuRnZrQ0xFcXNNTFlIdklaaERXYXZSN19nRGhUbk1JU0hGWngtNUI1dk9vcldFOXhYdUszVUtQZjJPNDZqNjd6UVYyVnFQZWp5X2hPWEZvNDJRX0JVRDlYNDA2QXFpb2FRTCIsInR5cGUiOiJFbnZlbG9wZWRWZXJpZmlhYmxlQ3JlZGVudGlhbCJ9XX0.fFEnMO-JjUyfE8zmjla9mVv_5e6hMIY1eUtZUXvoCvYHDfhgL1hb63yyB3TD-ubvXI7eePpYeKAY4lhSQUJI6AdDcOVQi8p8MdkRPT3-H3-lXEa_O4CMl-z3F1xlpb87
>
>
> This part:
>
> "path": "$",
> "format": "jose_vp",
>
> If the string at $ is actually application/vp+jwt, then format is just an
> alias for "application/vp+jwt".
>
> But inside the "path nested" part:
>
> "path": "$.verifiableCredential[0]",
> "format": "jose_vc"
>
> The first element of the "verifiableCredential" property of a decoded
> application/vp+jwt payload is:
>
> {
> "@context": "https://www.w3.org/ns/credentials/v2",
> "id":
> "data:application/vc+jwt;eyJraWQiOiJrZXktNDIiLCJhbGciOiJFUzM4NCIsInR5cCI6InZjK2p3dCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTUtMDUtMTBUMTI6MzA6MDBaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsInN1YnR5cGUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ.01ICD5Qwb3GhV31pbKHOcvIwxV2wxbnFvkCLEqsMLYHvIZhDWavR7_gDhTnMISHFZx-5B5vOorWE9xXuK3UKPf2O46j67zQV2VqPejy_hOXFo42Q_BUD9X406AqioaQL",
> "type": "EnvelopedVerifiableCredential"
> }
>
> Which implies that "jose_vc" is actually related to the RDF type
> "EnvelopedVerifiableCredential"... and not the media type
> "data:application/vc+jwt".
>
> 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.
>
> *I realize these are problems with presentation exchange and the w3c
> vcdmv2, and not necessarily openid for vp*, 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.
>
> 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".
>
> There is even a brand new invention called "EnvelopedPresentations" -
> https://www.w3.org/TR/vc-data-model-2.0/#enveloped-verifiable-presentations
>
> This "nesting / enveloping / decoding" structure needs to be accounted for
> in presentation definitions, or you cannot select claims from credentials...
>
> 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:
>
> decodeJwt ( decodeDataUri(
> decodeJwt(vp_jwt).payload.verifiableCredential[0].id )
> ).credentialSubject.degree.subtype -> Bachelor of Science and Arts
>
> ... 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.
>
> 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.
>
> 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.
>
> 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.
>
> Another solution could be to simply *provide correct complete concrete
> examples for as many media types as the group knows the protocol needs to
> support*... 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.
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
>
> OS
>
>
>
> On Mon, Oct 28, 2024 at 3:30 PM Micha Kraus via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
> I support starting the Implementer's draft approval process.
>
> Thanks,
> Micha
>
> Am 28.10.2024 08:39 schrieb Pedro Felix via
> Openid-specs-digital-credentials-protocols:
> > I support starting the Implementer's draft approval process.
> >
> > Regards,
> >
> > Pedro
> >
> > On Mon, Oct 28, 2024 at 2:00 AM Tobias Looker via
> > Openid-specs-digital-credentials-protocols
> > <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
> >
> >> I support starting the Implementer's draft approval process.
> >>
> >> Thanks,
> >>
> >> [2]
> >>
> >> TOBIAS LOOKER
> >>
> >> MATTR
> >>
> >> +64 273 780 461
> >> tobias.looker at mattr.global
> >>
> >> [2]
> >>
> >> [3]
> >>
> >> [4]
> >>
> >> [5]
> >>
> >> This communication, including any attachments, is confidential. If
> >> you are not the intended recipient, you should not read it –
> >> please contact me immediately, destroy it, and do not copy or use
> >> any part of this communication or disclose anything about it. Thank
> >> you. Please note that this communication does not designate an
> >> information system for the purposes of the Electronic Transactions
> >> Act 2002.
> >>
> >> FROM: Openid-specs-digital-credentials-protocols
> >>
> > <openid-specs-digital-credentials-protocols-bounces at lists.openid.net>
> >> on behalf of torsten--- via
> >> Openid-specs-digital-credentials-protocols
> >> <openid-specs-digital-credentials-protocols at lists.openid.net>
> >> DATE: Saturday, 26 October 2024 at 10:19 PM
> >> TO: openid-specs-digital-credentials-protocols at lists.openid.net
> >> <openid-specs-digital-credentials-protocols at lists.openid.net>,
> >> Digital Credentials Protocols List
> >> <openid-specs-digital-credentials-protocols at lists.openid.net>
> >> CC: torsten at lodderstedt.net <torsten at lodderstedt.net>
> >> SUBJECT: Re: [Openid-specs-digital-credentials-protocols] FW:
> >> Working group last call for proposed OpenID4VP Implementer's Draft
> >>
> >> EXTERNAL EMAIL: This email originated outside of our organisation.
> >> Do not click links or open attachments unless you recognise the
> >> sender and know the content is safe.
> >>
> >> +1
> >>
> >> Am 26. Okt. 2024, 10:54 +0200 schrieb Paul Bastian via
> >> Openid-specs-digital-credentials-protocols
> >> <openid-specs-digital-credentials-protocols at lists.openid.net>:
> >>
> >>> I support commencing the Implementer’s draft approval process.
> >>>
> >>> Paul
> >>> --
> >>> Openid-specs-digital-credentials-protocols mailing list
> >>> Openid-specs-digital-credentials-protocols at lists.openid.net
> >>>
> >>
> >
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
> >>> [1]
> >> --
> >> Openid-specs-digital-credentials-protocols mailing list
> >> Openid-specs-digital-credentials-protocols at lists.openid.net
> >>
> >
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
> >> [1]
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
> > [2] https://mattr.global/
> > [3] https://www.linkedin.com/company/mattrglobal
> > [4] https://twitter.com/mattrglobal
> > [5] https://github.com/mattrglobal
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries/>
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241112/fe98238c/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list