Dear colleagues, While each credential format, such as W3C VCDM (JSON-LD), SD-JWT VC, and ISO mdoc, utilizes different syntax and encoding, they are fundamentally unified by a shared architectural dependency: the Semantic Supply Chain. Whether the link to external meaning is explicit (as in a JSON-LD `@context`) or abstracted (as in an SD-JWT `vct` or an mdoc `namespace`), the underlying security requirement remains identical. High-assurance verification must ensure that the machine-readable definitions used to interpret the credential are as integrity-protected, versioned, and authorized as the signed payload itself. By abstracting these models, it becomes clear that the threats, such as * semantic substitution, * metadata tracking, and * unauthorized type-definition are universal. Consequently, I will focus first on defining a "Semantic Assurance Profile" and its associated controls. This approach allows us to apply the same rigorous assurance levels across all formats, shifting the conversation from a debate over "links" to a unified strategy for securing semantic distribution. By normalizing these security controls, we can move past the "JSON-LD is unsafe" narrative and uncover the distinct advantages of the Linked Data model. For semantically rich use cases, such as complex supply chains, professional qualifications, cross-domain business identity, data spaces or trusted AI, JSON-LD provides superior expressiveness and native extensibility. Even for simpler credentials, the ability to map terms to global vocabularies ensures that 'name' or 'identifier' carries the same legal and technical meaning across borders. This provides a level of native interoperability that abstracted models struggle to match without heavy out-of-band coordination, a hurdle that may be manageable for natural person identity cards, but which Trace4EU findings suggest fails for more complex domains like educational credentials. Ultimately, the controls and governance required to secure the semantic supply chain are fundamentally similar across all formats; there is no inherent superiority in the governance processes themselves, only in how explicitly they are bound to the credential types. Next steps (with some more focus on "Semantic Assurance Profile"): # Task Description / Key Details 1 One-page problem statement State that W3C VCDM JSON-LD is already present in ETSI TS 119 472, but lacks a consolidated high-assurance interoperability profile for OpenID4VC-based regulated use ==> Align with W3C VC WG / Business Wallet TF 2 Gap analysis against OIDF HAIP Focus specifically on section 6 credential format profiles 3 Gap analysis against ETSI TS 119 472-1/2/3 Highlight what ETSI already covers and identify what still needs profiling 4 Create a risk register Include JSON-LD contexts, canonicalisation, proof suites, holder binding, trust anchors, status, privacy, and conformance 5 Define mandatory-to-implement choices Without these defined choices, the profile will not solve interoperability 6 Decide the formal name later Use HAIP4W3C as a working name and dicuss in the team later I am also already checking if and how this work can be aligned with the W3C VC WG. Carsten Von: Steffen Schwalm via HAIP4W3C <haip4w3c@eid.as> Gesendet: Sonntag, 3. Mai 2026 09:15 An: Detlef Hühnlein (ecsec GmbH) <detlef.huehnlein@ecsec.de>; haip4w3c@eid.as Betreff: [HAIP4W3C] Re: Towards a HAIP for W3C VCDM JSON-LD Hi all, Your proposal sounds reasonable Detlef. Let's do it. Personally I prefer W3C or ETSI for formal standardization as W3C already responsible for VCDM resp ETSI because main need for profile is in Europe due to EIDAS resp EU Business Wallet. But let's do homework first as you suggested earlier. Best Gesendet von Outlook für Android <https://aka.ms/AAb9ysg> _____ From: Detlef Hühnlein (ecsec GmbH) via HAIP4W3C <haip4w3c@eid.as> Sent: Sunday, May 3, 2026 7:53:12 AM To: haip4w3c@eID.AS <haip4w3c@eID.AS> Subject: [HAIP4W3C] Re: Towards a HAIP for W3C VCDM JSON-LD Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk always remains. Only open attachments and links from known and trusted senders. Good Morning Mirko, thank you for your message. The name can certainly be adjusted to avoid confusion. As the overall goal here is indeed very similar to the existing HAIP, it seems to be worth to consider in detail, whether simply defining a W3C VCDM JSON-LD profile in a new clause 6.2 of HAIP 1.x [1] would do the job. I would suggest, that we first do our homework here, before we scare the HAIP authors with our vague ideas. This includes 1) the discussion and clarification of the goals 2) the risk assessment mentioned by Carsten on LinkedIn 3) the development of mitigation measures, if necessary Dear all, what is your view on this? Best Regards, Detlef [1] https://openid.github.io/OpenID4VC-HAIP/openid4vc-high-assurance-interoperab ility-profile-1_1-wg-draft.html#section-6 Am 02.05.2026 um 15:11 schrieb Mirko Mollik: Dear Detlef, I am recommending to not call it HAIP since this term is already used and could lead to confusion. When it has basically the same requirements for oid4vci as the existing one, I would recommend to just define the credential profile for vcdm 2.0 in the ietf there. Better go with any other name that maybe even includes business wallet to avoid any confusion Cheers Am 01.05.2026 23:05 schrieb "Detlef Hühnlein (ecsec GmbH) via HAIP4W3C" <mailto:haip4w3c@eid.as> <haip4w3c@eid.as>: Dear Colleagues, you should have been subscribed to the mailinglist haip4w3c@eID.AS <mailto:haip4w3c@eID.AS> , which might be helpful for our forthcoming discussions around this topic.

My objective would be to move this work under W3C and into this repo (as a second step): https://github.com/w3c/vc-dpp-bw

@Carsten, yes contributing our work later on to W3C would certainly be a very valid one option. As the HAIP4W3C profile will especially be used in the scope of the forthcoming European Business Wallet Regulation [1] and maybe also in the scope of the eIDAS-Regulation [2], it would also be an option to submit our joint work later on to ETSI ESI. I think both options are conceivable and both may have certain advantages and disadvantages. I would propose to start the work and later on decide which way to go, or whether a combination is even better. The work on XML-DSig [3] and XAdES [4,5], which was produced two decades ago jointly at W3C and ETSI ESI shows that a close and fruitful collaboration of W3C and ETSI ESI is very well possible. Juan-Carlos could certainly provide more details and insights how this worked out, and whether there have been any pitfalls to watch. Best Regards / have a wonderful weekend, Detlef [1] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52025PC0838 [2] https://eID.AS [3] https://www.w3.org/TR/xmldsig-core1/ [4] https://www.w3.org/TR/XAdES/ [5] https://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.03.01_60/en_3 1913201v010301p.pdf Am 30.04.2026 um 08:19 schrieb carsten.stoecker@spherity.com <mailto:carsten.stoecker@spherity.com> : cstoecker <mailto:detlef.huehnlein@ecsec.de> @Detlef Hühnlein (ecsec GmbH): My objective would be to move this work under W3C and into this repo (as a second step): https://github.com/w3c/vc-dpp-bw Von: Ignacio Alamillo <mailto:ignacio.alamillo@logalty.com> <ignacio.alamillo@logalty.com> Gesendet: Donnerstag, 30. April 2026 08:15 An: Detlef Hühnlein (ecsec GmbH) <mailto:detlef.huehnlein@ecsec.de> <detlef.huehnlein@ecsec.de>; Steffen Schwalm <mailto:Steffen.Schwalm@msg.group> <Steffen.Schwalm@msg.group>; Mikael.afHallstrom@vero.fi <mailto:Mikael.afHallstrom@vero.fi> ; carsten.stoecker@spherity.com <mailto:carsten.stoecker@spherity.com> ; Werner.Folkendt@de.bosch.com <mailto:Werner.Folkendt@de.bosch.com> ; Michael.Jochem@de.bosch.com <mailto:Michael.Jochem@de.bosch.com> ; ronald.koenig@spherity.com <mailto:ronald.koenig@spherity.com> ; nalamillo@cgcom.es <mailto:nalamillo@cgcom.es> Cc: lluisalfons.arino@urv.cat <mailto:lluisalfons.arino@urv.cat> ; go@eID.AS <mailto:go@eID.AS> ; 'EUBW@eID.AS <mailto:EUBW@eID.AS> ' <mailto:eubw@eid.as> <eubw@eid.as>; Mirko Mollik <mailto:mirko.mollik@eudi.sprind.org> <mirko.mollik@eudi.sprind.org>; 'Varga Viktor' <mailto:viktor.varga@microsec.com> <viktor.varga@microsec.com>; Juan Carlos Cruellas <mailto:cruellas@ac.upc.edu> <cruellas@ac.upc.edu> Betreff: Re: Towards a HAIP for W3C VCDM JSON-LD Hi, My github name is nalamillo <https://www.logalty.com/> Dr. Ignacio Alamillo, CISA, CISM, CDPSE Advisor +34 663 087 606 C/ de Cantabria, 2 (Ed. Amura) 28108 Alcobendas <https://www.twitter.com/@NachoAlamillo> <https://www.linkedin.com/in/nachoalamillo/> En Logalty trabajamos de forma flexible por lo que, si recibes un correo mío fuera del horario laboral, no espero que lo leas o me contestes hasta tu horario laboral habitual. Gracias De: Detlef Hühnlein (ecsec GmbH) <detlef.huehnlein@ecsec.de <mailto:detlef.huehnlein@ecsec.de> > Fecha: jueves, 30 de abril de 2026, 8:04 Para: Steffen Schwalm <Steffen.Schwalm@msg.group <mailto:Steffen.Schwalm@msg.group> >, Mikael.afHallstrom@vero.fi <mailto:Mikael.afHallstrom@vero.fi> <Mikael.afHallstrom@vero.fi <mailto:Mikael.afHallstrom@vero.fi> >, carsten.stoecker@spherity.com <mailto:carsten.stoecker@spherity.com> <carsten.stoecker@spherity.com <mailto:carsten.stoecker@spherity.com> >, Werner.Folkendt@de.bosch.com <mailto:Werner.Folkendt@de.bosch.com> <Werner.Folkendt@de.bosch.com <mailto:Werner.Folkendt@de.bosch.com> >, Michael.Jochem@de.bosch.com <mailto:Michael.Jochem@de.bosch.com> <Michael.Jochem@de.bosch.com <mailto:Michael.Jochem@de.bosch.com> >, ronald.koenig@spherity.com <mailto:ronald.koenig@spherity.com> <ronald.koenig@spherity.com <mailto:ronald.koenig@spherity.com> >, nalamillo@cgcom.es <mailto:nalamillo@cgcom.es> <nalamillo@cgcom.es <mailto:nalamillo@cgcom.es>

, Ignacio Alamillo <ignacio.alamillo@logalty.com <mailto:ignacio.alamillo@logalty.com> > CC: lluisalfons.arino@urv.cat <mailto:lluisalfons.arino@urv.cat> <lluisalfons.arino@urv.cat <mailto:lluisalfons.arino@urv.cat> >, go@eid.as <mailto:go@eid.as> <go@eID.AS <mailto:go@eID.AS> >, 'EUBW@eID.AS <mailto:EUBW@eID.AS> ' <eubw@eid.as <mailto:eubw@eid.as> >, Mirko Mollik <mirko.mollik@eudi.sprind.org <mailto:mirko.mollik@eudi.sprind.org> >, 'Varga Viktor' <viktor.varga@microsec.com <mailto:viktor.varga@microsec.com> , Juan Carlos Cruellas <cruellas@ac.upc.edu <mailto:cruellas@ac.upc.edu> > Asunto: Towards a HAIP for W3C VCDM JSON-LD

Dear Colleagues, thank you very much for the interesting and fruitful meeting yesterday. Following the discussion on LinkedIn this morning, <mailto:go@eID.AS> go@eID.AS kindly created the repository <https://github.com/eu-business-wallet/haip4w3c> https://github.com/eu-business-wallet/haip4w3c and sent out first invitations to some of the already known github usernames. Everybody who has not received an invitation yet and would like to contribute here, is kindly requested to provide the corresponding github username. Best Regards, Detlef Am 29.04.2026 um 14:47 schrieb Steffen Schwalm: Hi all, thanks for the fruitful and lively discussion. Beside the fact that we didn`t really discuss ETSI TS 119 482-3 as original topic we agreed that there`s need for a High Security Profile for W3CVCDM 2.0 JSON-LD (based on ETSI TS 119 472-1. The profile should be or could be part of current EN development under lead of Juan Carlos Crueallas. We agreed that relevant authorities and experts should be in the boat. <mailto:ignacio.alamillo@logalty.com> @Ignacio Alamillo I guess it might be helpful since Spain pushing W3CVCDM as well that maybe first input could be provided by Spanish experts. Beside this would recommend reaching out to Juan Carlos for alignment and next steps. We also had common sense that * currently nothing forbids a QTSP to issue QEAA using W3CVCDM JSON-LD as long as a CAB and Supervisory Body accepts it (which is case in certain member states) but sustainable solution would be mentioned Security Profile * that there´s currently a relationship between the Proposal for EU Business Wallet regulation and the 2024/2979 (IA on Art. 5a eIDAS) which is currently under revision as the proposal for EU Business Wallet regulation in current proposal refers to the IA on Art. 5a eIDAS for (Q)EAA formats * * if and how the relationship will be kept depends on final version of EU Business Wallet regulation and IA on Art. 5a eIDAS * ETSI EN 319 482-3 Additional wallet interfaces; Part 3: Interfaces and formats for the catalogue of Attestation Rulebooks and attributes (Rapporteur Viktor Varga) in very first draft states in * * SCH-SP-5.2-02: For an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA, the Scheme Provider shall specify that one or more of the following common formats is used for these attestations: * o * a) ISO/IEC 18013-5-compliant mdoc; * b) SD-JWT-based Verifiable Credentials. This can be interpreted in a way that W3C JSON-LD not allowed for QEAA. The standard is in very first version so that changes might be possible. Best Steffen -----Ursprünglicher Termin----- Von: <mailto:Mikael.afHallstrom@vero.fi> Mikael.afHallstrom@vero.fi <mailto:Mikael.afHallstrom@vero.fi> <Mikael.afHallstrom@vero.fi> Gesendet: Freitag, 24. April 2026 09:54 An: <mailto:Mikael.afHallstrom@vero.fi> Mikael.afHallstrom@vero.fi; <mailto:carsten.stoecker@spherity.com> carsten.stoecker@spherity.com; <mailto:Werner.Folkendt@de.bosch.com> Werner.Folkendt@de.bosch.com; <mailto:Michael.Jochem@de.bosch.com> Michael.Jochem@de.bosch.com; <mailto:ronald.koenig@spherity.com> ronald.koenig@spherity.com; <mailto:detlef.huehnlein@ecsec.de> detlef.huehnlein@ecsec.de; <mailto:Florin.Coptil@de.bosch.com> Florin.Coptil@de.bosch.com; Steffen Schwalm; <mailto:nalamillo@cgcom.es> nalamillo@cgcom.es Betreff: ETSI TS 119 482-3 Zeit: Mittwoch, 29. April 2026 14:00-15:00 (UTC+02:00) Helsinki, Kiew, Riga, Sofia, Tallinn, Wilna. Ort: Microsoft Teams -kokous Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk always remains. Only open attachments and links from known and trusted senders. Hi, we'll discuss the subjects raised in the email-discussion about ETSI TS 119 482-3 See you online Wednesday next week! br Micke WE BUILD LSP WP4 Semantics Lead ------------------------------------------------- Mikael af Hällström Development Specialist Product Management Unit Finnish Tax Administration phone +358-(0)40-8271301 email mikael.afhallstrom(at)vero.fi LinkedIN <https://www.linkedin.com/in/mikaelafhallstrom/> https://www.linkedin.com/in/mikaelafhallstrom/ ____________________________________________________________________________ ____ Microsoft Teams -kokous Liity: <https://teams.microsoft.com/meet/3212653313232?p=z3ncFxwqpNF5ha9Rqx> https://teams.microsoft.com/meet/3212653313232?p=z3ncFxwqpNF5ha9Rqx Kokoustunnus: 321 265 331 323 2 Tunnuskoodi: iu9Qv3fo _____ <https://aka.ms/JoinTeamsMeeting?omkt=fi-FI> Tarvitsetko apua? | <https://teams.microsoft.com/l/meetup-join/19%3ameeting_MmFmMDJmNTUtYmI0MS00 NDUwLTg0NGUtODU4ZDc0MDkzYTAy%40thread.v2/0?context=%7b%22Tid%22%3a%222fb0817 4-a150-479d-8d15-2174da71a11a%22%2c%22Oid%22%3a%22aebcd81f-60d1-4993-8f3c-ab 13c4f2292e%22%7d> Järjestelmäviittaus Liity puhelimella <tel:+358985626406,,170959911> +358 9 85626406,,170959911# Suomi, All locations <https://dialin.teams.microsoft.com/d5a67691-a1dc-4791-86b1-639d929dc8e0?id= 170959911> Etsi paikallinen numero Puhelinneuvottelun tunnus: 170 959 911# Järjestäjille: <https://teams.microsoft.com/meetingOptions/?organizerId=aebcd81f-60d1-4993- 8f3c-ab13c4f2292e&tenantId=2fb08174-a150-479d-8d15-2174da71a11a&threadId=19_ meeting_MmFmMDJmNTUtYmI0MS00NDUwLTg0NGUtODU4ZDc0MDkzYTAy@thread.v2&messageId =0&language=fi-FI> Kokousvaihtoehdot | <https://dialin.teams.microsoft.com/usp/pstnconferencing> Palauta soittamalla liittymisen PIN-koodi ____________________________________________________________________________ ____ -- Dipl. Inform. (FH) Dr. rer. nat. Detlef Hühnlein ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Phone +49 9571 948 1020 Mobile +49 171 9754980 Mail <mailto:detlef.huehnlein@ecsec.de> detlef.huehnlein@ecsec.de ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Registered at Court of Coburg HRB 4622 EUID: DED4401V.HRB4622 Directors: Tina Hühnlein Dr. Detlef Hühnlein This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses. <https://www.spherity.com/> Spherity GmbH | Emil-Figge-Straße 80 | 44227 Dortmund <https://www.linkedin.com/company/spherity> LinkedIn | <https://www.youtube.com/@spherity2407> YouTube Managing Directors: Dr. Carsten Stöcker, Dr. Michael Rüther Registered in Dortmund HRB 31566 -- Dipl. Inform. (FH) Dr. rer. nat. Detlef Hühnlein ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Phone +49 9571 948 1020 Mobile +49 171 9754980 Mail detlef.huehnlein@ecsec.de <mailto:detlef.huehnlein@ecsec.de> ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Registered at Court of Coburg HRB 4622 EUID: DED4401V.HRB4622 Directors: Tina Hühnlein Dr. Detlef Hühnlein This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses. -- Dipl. Inform. (FH) Dr. rer. nat. Detlef Hühnlein ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Phone +49 9571 948 1020 Mobile +49 171 9754980 Mail detlef.huehnlein@ecsec.de <mailto:detlef.huehnlein@ecsec.de> ecsec GmbH Sudetenstrasse 16 96247 Michelau Germany Registered at Court of Coburg HRB 4622 EUID: DED4401V.HRB4622 Directors: Tina Hühnlein Dr. Detlef Hühnlein This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses. -- Spherity GmbH <https://www.spherity.com/> | Emil-Figge-Straße 80 | 44227 Dortmund LinkedIn <https://www.linkedin.com/company/spherity> | YouTube <https://www.youtube.com/@spherity2407> Managing Directors: Dr. Carsten Stöcker, Dr. Michael Rüther Registered in Dortmund HRB 31566