[Openid-specs-digital-credentials-protocols] FW: Working group last call for proposed OpenID4VP Implementer's Draft
Michael Jones
michael_b_jones at hotmail.com
Tue Nov 12 22:06:47 UTC 2024
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:openid-specs-digital-credentials-protocols at lists.openid.net>
>> <openid-specs-digital-credentials-protocols at lists.openid.net<mailto:openid-specs-digital-credentials-protocols at lists.openid.net>>,
>> Digital Credentials Protocols List
>> <openid-specs-digital-credentials-protocols at lists.openid.net<mailto:openid-specs-digital-credentials-protocols at lists.openid.net>>
>> CC: torsten at lodderstedt.net<mailto:torsten at lodderstedt.net> <torsten at lodderstedt.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241112/8b3f9930/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list