[Openid-specs-digital-credentials-protocols] Minutes DCP WG Meeting April 17th
steffen schwalm
schwalm.steffen at googlemail.com
Wed Apr 23 07:41:58 UTC 2025
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> 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 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://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
>
>
> [image: Meeco] <https://www.meeco.me/>
>
> *Jan Vereecken*, Chief Product Officer, Meeco
> +32 473 93 61 03 | 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
>
> 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/20250423/f3c9303f/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list