[Openid-specs-digital-credentials-protocols] Minutes DCP WG Meeting April 17th
Joseph Heenan
joseph at authlete.com
Mon Apr 28 22:40:47 UTC 2025
Dear Steffen
Unfortunately I’m finding it a little difficult to follow this email. Can you clarify which spec(s) you are referring to in points 1 & 2 please?
I think dwelling on the past is not helpful here. I have said it before, but it feels like there could still confusion over it: any agreement that happens outside of the context of the working group does not represent a decision of the working group. This is true even when working group chairs are involved in such a discussion.
I also want to make clear that everyone (that has signed the contribution agreement and behaves in a constructive manner) is welcome to contribute in the working group, and all working group discussions happen in the open. I don’t believe the working group has ever rejected a proposal without providing an explanation, but if it has happened then I assume it was likely an oversight for which I apologise and if you point me at the relevant GitHub issue / PR I will do my best to find the explanation.
It is common for the original goals of a particular issue/PR to shift as it is discussed and investigated and different solutions are considered by the working group. It has happened to a number of issues & PRs I have raised and is a sign of healthy debate and careful consideration.
I think we should focus on how to move forward from where we are.
On point 3 - If there are problems with what ended up in the OpenID4VP spec then (as discussed) we need the details on use cases that aren't possible logged into an issue please.
Any solution is possible - if the result of testing SD-JWT VCLD as currently specified ends up showing that it’s a long way from what’s needed then nothing stops the working group from throwing away the problematic part(s) of the specification and starting again. This is a decision purely made by working group consensus. But the first step is to get good deep details on what doesn’t currently work, for what use case, and why it doesn’t work - and log it into an issue in GitHub, including details like the relevant real-world JSON-LD payloads. Do you know when someone will be able to do that?
Thanks
Joseph
> On 23 Apr 2025, at 08:41, steffen schwalm via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
> Dear Jan,
>
> thanks a lot for the minutes. Unfortunately, they do not fully reflect the discussed results reg. PR 459.
>
> 1. The contributions from EBSI/Europe (Sancho, Lluis, Nacho, Alen in CC) so specs. Requirements, analysis on incompatibilities were shared with e.g. Torsten, Kristina, Daniel and Oliver during the collaboration within the last 1,5 years.
>
> - August 2023 after meeting with Kristina, Oliver
> - 24.09.2024 after meeting with Daniel
> - 15.11.2024 after meeting with Daniel, Brian, Oliver
> - 19.12.2024 after meeting with Daniel, Kristina, Torsten, Oliver, Brian
> - 25.02.2025 after session of whole DCP WG
>
> As we guess that
>
> a) OIDF or the chairs Torsten & Kristian or at least
>
> b) Daniel has well organized repository
>
> we kindly as the opinion leading Team Torsten, Kristina, Daniel, Oliver to share those documents with the WG again. Alen provided the information also in February to the WG. So those contributions/Specifications do not need to be shared again and again if the DCP WG is really interested in.
>
> There was a collaboration between the opinion leading Team Torsten, Kristina, Daniel, Oliver on the SD-JWT and -VCDM subject since August 2023 where we finally agreed to include W3VCDM in SD-JWT VC:
>
> - ability to reuse existing vcdm 1.1 code is important
> - ability to transition from vcdm 1.1 code to sd-jwt vcdm code is important
> - strict compliance to vcdm 2.0 is not necessary
> - should work both with and without json-ld processing
>
> or stated more precisely in minutes of DC WG:
>
> https://docs.google.com/document/d/1y3milcqMkAHqf4862ANoCA7irg6gNaDI3aNOVaZMoVY/edit?tab=t.0
>
> “The goal is to add W3C VCDM data model and processing to this defined credential - secured by SD JWT”
> recognizing the material shared by Alen on 25.02.2025 to the WG.
>
> We also clearly state that during exchanges on the subject no facts from the editors of the PR nor Torsten or Kristina or anybody else were mentioned that the proposed spec from Alen & Lluis violates existing specifications. Since the PR is based on the spec from Alen & Llluis we wonder how Daniel came to his unjustified claim as he participated in the development of first PR based on Alen/Lluis`s specification in November 2024.
>
> So since we experience those unjustified claims and request to provide same subject again and again since 2023 especially from the Team from SPRIND (Torsten, Kristina, Daniel) and Oliver we increasingly have the impression that those contributions are not welcome without notice nor technical justification. This makes an open discussion quite difficult.
>
> 2. We clearly state that the specification from Lluis & Alen was basement of the PR and request to mention both as this seems to be an IPR issue.
>
> As the spec from Lluis & Alen was developed with EU funding I guess it`s politically sensitive to mention their contribution too – especially after this was seemingly forgotten in the beginning of this PR too. We request to mention them and only delete them by request from Alen and Lluis.
>
> 3. We agreed in WG on following:
>
> - We`ll EBSI) will test the SD-JWT VCLD to give comprehensive overview what from SD-JWT VCLD does not work within the use cases
> - Based on results a further discussion may be started
>
> We do not agree that any Change of current SD-JWT VCLD must fully recognize the current version as this would be grotesque, since the possible CR would aim precisely at changing certain parts of the VCLD spec.
>
> If especially the passage that any Change of current SD-JWT VCLD must fully recognize this version of the spec is not changed we would assume that a future CR of any form is obviously not welcome by the editors and opinion-leading party (Torsten, Kristina, Daniel, Oliver).
>
> 4. Following selected parts are from the current point of view clearly incompatible with VCDM that`s why SD- JWT VCLD is ironically the correct term.
>
> - Spec was renamed to VCLD as it clear not covers VCDM
> o As Markus mentioned the goal of SD-JWT is enabling JSON-LD payload with SD.-JWT VC only
> o Processing W3CVCDM as JSON-LD is only one option in W3CVCDM, the obvious binding to JSON-LD limits applicability of SD-JWT VCLD for most use cases
> - no DID possible as the PR shows (and as it relies on SD-JWT VC spec https://github.com/openid/OpenID4VP/pull/459#issuecomment-2814088690
> o confirmed by Daniel in several meetings (that´s why this extension points were added in VC Spec…)
> - Atomic/Micro Credential as specified in W3CVCDM
> o No bundling of credentials possible
> o Normal as “VCT” value defined in VCLD Spec MUST be a case-sensitive StringOrURI while Credential type in W3CVCDM MUST contain a "type" property. The value of the "type" property MUST be one or more terms and absolute URL strings. Some other reasons are:
> § VCT also does not allow any transformation nor canocalization
> § The bundling acc. to 8.5/9.5 requires e.g. functionalities of section B2 VCDM v1.1 and 8,5 v1.1 resp. 9.5 v2.0 which is among other things needed for atomization of credentials.
> § The therefore needed type value was deleted and replaced by VCT
> § The atomization (as well as the possible reconversation) are de facto transformations excluded in the current VCLD Spec
> o That “VCT” is not enough for Micro credentials was confirmed by Daniel Fett in meeting on 06.12.2024
> - OID4VP B1 as proposed by Daniel does not help at the time of presentation is too late. The credentials need to be bundled at time of issuance
> due to legal and business requirements
> - We apologize that the legal and technical requirements from Industry, Manufacturing, HR, creative industry, Data Act, Banking/Finance, Health etc.) do not match with the mental model of SD-JWT VCLD in its current form.
>
> - That Micro Credentials as defined in W3CVCDM v1.1/v2.0 not covered was confirmed by Torsten, Daniel, Joseph several times
>
> - Torsten 11.04. in DCP WG Meeting: Claiming it`s new requirement
> - Joseph: last week see GitHub (claiming those requirements were allegedly not submitted, while they were since 1,5 years)
> - Daniel: 16.04.
>
> beside the fact that coverage serves the agreed goal to include VCDM in SD-JWT VC) and that the requirements agreed by DCP WG on 25.02.2025.
>
> As not only Micro Credentials mainly focused on legal entities and B2B use cases and taking into account as Torsten mentioned that OIDF focus on citizens:
>
> If you do not want to cover those subjects, which could be understandable, the SD-JWT VCLD spec shall mention the limitation to use inclusion of JSON-LD and coverage of use cases related to identification of natural entities only.
>
> Beside this e..g. also other subjects missed in VCLD (selection from agreed requirements and properties of VCDM):
>
> - Multi-language support of claim values is undefined (only multi-language support for the claim names is there)
> - issuer identifiers are not addressed
> - Subject claims to be grouped and supports hierarchical/complex structure.
> - Audience restriction (advanced)/ Terms of use: support to express sharing and presentation policies, restrictions and similar information --> no property for this defined
>
> Against this background we clearly state that the aim agreed in DCP WG to include VCDM in SD-JWT VC as OIDF also agreed with European Commission is currently not achieved.
>
> Also, the requirements presented by Alen in February and stated more precisely in minutes of DC WG
>
> https://docs.google.com/document/d/1y3milcqMkAHqf4862ANoCA7irg6gNaDI3aNOVaZMoVY/edit?tab=t.0
>
> “The goal is to add W3C VCDM data model and processing to this defined credential - secured by SD JWT”
>
> are currently not achieved as also the editors and opinion-leading party (Torsten, Kristina, Daniel, Oliver) already confirmed that certain mentioned subjects are not covered.
>
>
>
> Best
>
> Steffen
>
> On Fri, Apr 18, 2025 at 8:08 AM Jan Vereecken 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:
>> Hi all,
>>
>> Please find below the minutes of yesterday's meeting.
>>
>> # Attendees
>>
>> - Steffen Schwalm
>> - Torsten Lodderstedt
>> - Timo Glastra
>> - Kristina Yasuda
>> - Steffen Schwalm
>> - Martijn Haring
>> - Daniel Fett
>> - Geroge Fletcher
>> - Christian Bormann
>> - Aarom Parecki
>> - David Waite
>> - Peter Sorotokin
>> - Joseph Heenan
>> - Michael Jones
>> - Mirko Mollik
>> - Lee Campbell
>> - Nick Steele
>> - David Chadwick
>> - Tim Cappalli
>> - Juda Saadi
>> - Yuval Glasner
>> - Oliver Terbu
>> - Tom Jones
>> - Rajvardhan Deshmuk..
>> - Bjorn Hjelm
>> - Gareth Oliver
>>
>> # Agenda
>>
>> 1. OIDF Antitrust Policy at www.openid.net/antitrust <http://www.openid.net/antitrust> applies / IPR reminder
>> 2. Formal security analysis: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250414/4b84c5d0/attachment-0001.pdf
>> [as far as I’m aware, no further agenda items were communicated in advance]
>>
>> # Notes
>>
>> ## Formal Security Analysis
>>
>> The deliverable has been formally accepted by the WG
>>
>> ## EIC
>>
>> Register for the in-person & virtual meetings at:
>>
>> https://DCPWG_EIC_05MAY25.eventbrite.co.uk <https://dcpwg_eic_05may25.eventbrite.co.uk/>
>> https://DCP-WG-Mtg-Post_EIC_08May25.eventbrite.co.uk <https://dcp-wg-mtg-post_eic_08may25.eventbrite.co.uk/>
>>
>> ## Japan Friendly Meeting time
>>
>> New Japan/Asia friendly call scheduled every two weeks, first call April 24th
>> Existing “APAC friendly” is renamed to “Americas friendly” and remains.
>> Note that every forthnight there will be 3 WG meetings.
>>
>> ## OpenID4VP - PR546 - Remove references to 18013-7 from OpenId4VP
>> https://github.com/openid/OpenID4VP/pull/546
>>
>> No objections from the WG. Merged into main.
>>
>> ## OpenID4VP - PR551 - clarify that client identifier prefix specific parameters got to the header in multi RP DC API requests
>> https://github.com/openid/OpenID4VP/pull/551
>>
>> Approvals received during call. Nobody needed additional time to review. Merged into main.
>>
>> ## OpenID4VP - PR555 - Revert to JARM style use of authorization_encrypted_response_alg
>> https://github.com/openid/OpenID4VP/pull/555
>>
>> Mike stressed the need for consistent approach wrt other specs.
>> WG targets to merge on April 22nd.
>>
>> ## OpenID4VP - PR556 - Error responses for DC API
>> https://github.com/openid/OpenID4VP/pull/556
>>
>> Gareth aims to add privacy part before next call (April 22nd).
>> Discussion on the subtle privacy issues that can occur when requests contain, for example, value matching and some privacy sensitive information could be returned.
>>
>> ## OpenID4VP - PR553 - clarify issuer_signed_alg_values and device_signed_alg_values
>> https://github.com/openid/OpenID4VP/pull/553
>>
>> Discussion between Kristina and Martijn on the direction. Conclusion recorded in the ticket.
>>
>> ## OpenID4VP - PR459 - add sd-jwt vcld
>> https://github.com/openid/OpenID4VP/pull/459
>>
>> Torsten introduced the topic. Generalised approach on how SD-JWT VC can be used with json-ld, without explicitly linking it to, for example, VCDM 1.1 or VCDM 2.0.
>> Steffen points out that it is crucial that all VCDM functionality, in its completeness, can be used. It is not possible with this approach.
>>
>> Conclusion after a long discussion:
>>
>> Authors of the PR believe that all properties of VCDM are maintained, but Steffen representing the EBSI project disagrees.
>> The WG asks for technical details as to why it does not work for the EBSI project.
>> The WG asks for concrete proposals that take into account existing specifications (i.e. following PR)
>>
>> PR is merged. WG agrees to test this approach and refine the outcome.
>>
>> ## Plan for WGLC
>>
>> 5 PRs remaining. Almost there! Joseph to send mail to mailing list.
>>
>> Happy easter.
>>
>> –Jan
>>
>>
>> <https://www.meeco.me/>
>>
>> Jan Vereecken, Chief Product Officer, Meeco
>> +32 473 93 61 03 | jan.vereecken at meeco.me <mailto:jan.vereecken at meeco.me>
>> twitter/x: @janvereecken <https://twitter.com/janvereecken> | linkedin: janvereecken <http://www.linkedin.com/in/janvereecken>
>>
>>
>> Discover Meeco at meeco.me <https://www.meeco.me/> or read our blog, case studies, and industry reports on our Insights <https://www.meeco.me/insights> page.
>> We are on LinkedIn @meeco_me <https://www.linkedin.com/company/meeco-me/mycompany/> and X @meeco_me <https://twitter.com/meeco_me>
>>
>> This email is confidential and may contain legally privileged information. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this email in error, please notify us immediately by return email and delete the document.
>>
>> --
>> 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
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250428/20db667a/attachment-0003.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list