[Openid-specs-digital-credentials-protocols] FW: Working group last call for proposed OpenID4VP Implementer's Draft
Orie Steele
orie at transmute.industries
Thu Oct 31 15:52:50 UTC 2024
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241031/48ade618/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list