W3C-VCDM - preferred credential format for EUBW#26
Conversation
Expanded the document to detail the preferred EUBW attestation format, including context, decisions, and consequences related to semantic interoperability and use cases.
Clarified the limitations of current attestation formats regarding global semantic interoperability and emphasized the importance of using existing global vocabularies. Recommended using VCDM2.0 as the preferred attestation format to minimize complexity.
Updated the document to clarify the preferred attestation format and the requirements for use case owners. Enhanced descriptions of use cases and the implications of using different attestation formats.
Updated SC2 use case description to include details about credentials and authorization policies for the DSP protocol.
Update attestation formats and terminology in EUBW document
Expanded on the limitations of current attestation formats and emphasized the importance of semantic interoperability. Added details on the capabilities of JSON-LD and the benefits of using W3C-VCDM credentials.
|
I support ADR “W3C-VCDM – preferred credential format for EUBW – PR#26” and visualized my argument. The chart below shows why this is necessary. Industrial data for Industry 4.0, supply chains, DPPs and data spaces sits in a different dimension than personal data. It is high-volume, diverse and semantically rich. Personal data is low-volume and simple. A credential format designed for simple, low-volume personal IDs (e.g., "10 attributes on a personal identity cards") cannot support the data structures needed for industrial use cases. Recent research confirms this gap. The International Yearbook of Industrial Statistics 2023 (UN Industrial Development Organization) describes the scale and diversity of industrial data across global sectors. It spans sensors, compliance artefacts and operational documents. These data sets require strong semantic models and linking mechanisms. This aligns with the PR: SD-JWT and mDoc cannot express linked data structures or global vocabularies needed for used cases in industrial uses cases and professional / financial services. Studies from IBM Research show that industrial data lakes become unmanageable without semantic enrichment. Semantic models are needed to link heterogeneous data and avoid “data swamps.” This matches the PR’s argument that industrial attestations must support global vocabularies, JSON-LD framing, and canonicalization. Work from RWTH Aachen on data spaces (Gaia-X, IDS) also confirms that semantic interoperability is a core requirement. Industrial actors need credentials that can reference global vocabularies and link entities, devices and roles. This is central for KYC/KYB, authorization chains and automated actors. It is also central for SC1, SC2 and PA3 in WE BUILD. W3C-VCDM is the only format that provides JSON-LD (or the likes such as CBOR-LD, which will be considered as a further alternative for future refinements), semantic linking, framing and canonicalization. These capabilities are needed for corporate identity, delegation, KYC/KYS/AML structures, market roles, license to operate, EHS, certification credentials, "trusted AI", and cross-border interoperability. SD-JWT and mDoc alone cannot meet these needs. For these reasons, the PR’s proposal to define W3C-VCDM as the preferred attestation format for the EUBW is justified and necessary. 
|
|
Thank you for the detailed proposal. One clarification may help refine this ADR. W3C VCDM is a semantic data model, not an attestation format. It defines how claims are structured and semantically represented, but it does not prescribe the serialisation format, proof mechanism, signature scheme, or transport. VCDM-based claims can therefore be conveyed within several envelopes, including JWT-VC, SD-JWT-VC, or COSE-based formats. For this reason, it may be more accurate to frame the ADR as “Specify the Semantic Data Model and Attestation Formats for the EUBW EAA”. This allows a clear comparison of the attestation formats already used in the EUDI ecosystem, such as ISO/IEC mdoc and JSON-based formats like SD-JWT-VC or JWT-VC, while treating the semantic layer, including VCDM, as a separate concern. This avoids positioning VCDM as a competing format and maintains a clear separation between:
It also preserves flexibility for use-case owners to select suitable combinations without increasing the number of attestation models the wallet must support. |
Why a coherent EUBW VC stack is key for technical robustness, economic value and global B2B digital trust corridorsAcross European and global data‑space initiatives, global trade & customs, supply chain and Industry 4.0 ecosystem, W3C VCDM‑based verifiable credentials are already used in production and in large pilots. In these ecosystems, VCDM is not treated as a “purely semantic add‑on”, but as the effective credential format that wallets, connectors, and trust frameworks implement and test against. Ronald’s ADR is not about just another low‑volume (and low-value) "consumer" (or even a corporate director) use case like “opening a bank account” that the "current natural person EUDI wallet" communication often highlights. It is about the high‑volume, high‑value data transaction layer of the EU economy: business‑to‑business and machine‑to‑machine flows in data spaces, DPP infrastructures, Industry 4.0, supply chains, dual use goods, civilian-military-supply-chain, and ZTA‑driven critical infrastructure, exactly where the Commission now positions the European Business Wallet as “the cornerstone of doing business simply and digitally in the EU” and as a horizontal enabler to cut regulatory overhead. In its new International Digital Strategy, the Commission states that digital identity wallets and trust services based on the EU Digital Identity Wallet specifications should be “at the core of an interoperable and scalable suite of digital building blocks and solutions” in partner countries and enable seamless cross‑border use of trust services and digital public infrastructure with partners such as Canada, South Korea, Ukraine, Moldova, the Western Balkans, Japan, India and Egypt. Through digital partnerships and digital trade agreements with Japan, the Republic of Korea, Singapore, Canada and others, the EU is building de‑facto digital data‑sharing and trust corridors focused on trusted data flows, digital identity, digital trade and mutual recognition of electronic documents and signatures. For these corridors the real volume and macro‑economic value will come from B2B and M2M transactions, not from low‑volume consumer use cases, and they will only scale if the EUBW rests on widely and globally accepted standards for credentials and proofs for B2B and M2M that integrate cleanly with the VCDM‑based stacks industry and international partners are already deploying. The Commission’s own impact work expects that current fragmented reporting and compliance processes destroy productivity on the order of trillions per year, and that a common wallet (and EUBW + DPP infrastructure) for economic operators should reduce administrative burden, enable wallet‑by‑default regulatory interactions and support secure cross‑border data sharing for permits, licences, certificates and VAT registrations. This is exactly the space where a coherent VCDM + Data Integrity stack for the EUBW can deliver straight‑through processing (STP) of compliance controls and provenance, and where a nested, format‑fragmented approach would re‑create the very complexity and transaction costs the initiative is supposed to remove while establising enourmous technical adoption burdens. When we treat the EUBW as an identity meta‑platform in the sense of “Cooperation Beats Aggregation” – a shared trust fabric that sits behind and between DPPs, data spaces, ERP systems and OT networks – each additional ecosystem that adopts the same credential profile does not just add its own value, it multiplies the value of all others through network‑of‑networks effects. That is why we argue for an adoption strategy that plugs EUBW‑ready, VCDM‑based solutions into large industrial pilots and production ecosystems now (Catena‑X, energy data‑X, UNTP‑based DPPs, sectoral data spaces), so that the wallet can be battle‑tested at industrial scale, deliver immediate macro‑economic benefits, and build crypto‑agile foundations for the upcoming PQC transition in a single, coherent architecture instead of many incompatible layers. 1. Ecosystems already using W3C VCDM credentials1.1 Overview tableBelow is a non‑exhaustive, fact‑based table of ecosystems that depend on W3C VCDM credentials today.
Key observation: Across these ecosystems, VCDM + JSON‑LD is treated as the concrete credential format secured with a Data Integrity proof or a similar Linked Data‑oriented signature. The semantics and the proof are tightly coupled to JSON‑LD and RDF graphs. The semantics and the serialisation are what implementations actually depend on. For EUBW this implies: If an EUBW wallet cannot natively issue and verify VCDM JSON‑LD credentials with their own proofs, it cannot connect cleanly to UNTP DPPs, Gaia‑X credentials, Catena‑X data‑exchange contracts, or emerging energy data spaces. This would actually be very disadvantageous for adoption. 2. Why we recommend Data Integrity proofs (and not SD‑JWT / COSE) for EUBW2.1 What W3C and ETSI say about Data Integrity and VCDM 2.0
ETSI TR 119 476 (v1.2.1 and v1.3.1) is very explicit for the European context:
This is important: ETSI and ISO standardisation efforts are actively converging on VCDM JSON‑LD + Data Integrity + BBS+ as the path for:
2.2 Why Data Integrity is technically a better fit than SD‑JWT/COSE for EUBWFrom a technical perspective, Data Integrity proofs have properties that are critical for industrial/B2B environments:
For these reasons, we suggest that EUBW should treat “VCDM JSON‑LD + Data Integrity proofs” as the preferred cryptographic binding for its own credential format, especially for industrial and B2B scope. 3. Why SD‑JWT‑VC and mDoc are not “drop‑in” compatible with these ecosystemsFormally, you are right:
But the industrial ecosystems examples listed above have not adopted SD‑JWT‑VC or mDoc as their main formats:
SD‑JWT‑VC and mDoc have different assumptions:
Mapping from VCDM JSON‑LD to SD‑JWT‑VC or mDoc would require:
Some bridging profiles show how to combine SD‑JWT with W3C VCs, but that is done by additional mapping and profiles, not by native equivalence. For WE BUILD and EUBW, this means:
4. Why nested formats are technically disadvantageousBy “nested formats” we mean designs where:
4.1 Two layers of modelling and proof logicIn such designs, verification requires:
This doubles:
In Industry 4.0, supply chain, and data‑space runtimes, policy engines already assume VCs as the trust input. Adding a nested layer increases complexity without any real benefit for industrial use cases. 4.2 Catena‑X / DPP exampleCatena‑X DPP and PCF flows rely on:
If we embed VCDM‑style DPP credentials inside SD‑JWT‑VC, each participant must:
All existing tooling that expects top‑level JSON‑LD VCs must be updated. The risk of subtle bugs in signature verification and policy evaluation increases. 4.3 Energy data‑X / machine identity exampleFor energy data‑X:
If VCDM JSON‑LD credentials are the primary format:
If VCDM is nested or transformed into other formats, gateways must:
For critical infrastructure, this added complexity is a clear downside. 5. Credential chaining and why format switching breaks efficiencyCredential chaining is essential for EUBW:
Research and practical work on SSI and delegated authority underline the importance of chained credentials for scalable trust and provenance. If we mix formats in these chains, we introduce:
Using VCDM JSON‑LD + Data Integrity throughout the chain means:
Given that credential chaining is already hard, format switching inside chains adds unnecessary complexity and risk. 6. Security, Zero Trust Architecture (ZTA) and industrial B2BFor industrial ZTA, we need:
In practice, this means:
Data Integrity proofs help here because:
From a security engineering perspective, it is safer if industrial ZTA chains are built on one data model + one proof family. Right now, the only option that satisfies:
is VCDM JSON‑LD + Data Integrity proofs. 7. The “tiny red dot vs very huge orange ocean” – human vs industrial scopeNote: The following section refers to the 2x2 Matrix as depicted in my previous Github comment. We fully recognise:
But EUBW is driven by different needs:
In our diagram, the super tiny red dot is human‑centric PID/LPID with ~10 attributes. The super huge orange ocean is industrial data: multi‑layer graphs, high volume, rich semantics.
From a requirements point of view, we MUST:
Note: UNTP, Gaia‑X, Catena‑X and related data spaces have already done such evaluations and converged on VCDM JSON‑LD credentials as their base. 8. Why we still argue to position VCDM + Data Integrity as an attestation format for EUBWFormally:
From a wallet and ecosystem viewpoint, the combination:
For the EUBW architecture, it is therefore practical and accurate to speak of:
alongside, for example:
This respects your conceptual separation, but reflects how ecosystems, ecosystem adoption, and economic value realization actually work. 9. Process: requirement‑driven architecture and the ADRFinally, on process:
Our significant concern is that:
We therefore suggest the following principles of the ADR:
This approach:
This is exactly the thinking behind Ronald’s ADR: use standard engineering practice (requirements, alternatives, evaluation) and then make an informed decision that matches industrial needs, instead of deriving the industrial stack from human browser flows. Final ThoughtsThe conceptual analysis, reflects how ecosystems, ecosystem adoption, and economic value realization actually work. The RWOT “Cooperation Beats Aggregation” work on identity as a meta‑platform shows that open, shared standards for decentralized identity create network‑of‑networks effects: each additional ecosystem that plugs into the same identity and credential layer increases the total value for all others, not just linearly, but through cross‑terms between networks. If we let EUBW + EUDI + DPP + data spaces + Industry 4.0 + supply chain + ZTA converge on one coherent stack (VCDM JSON‑LD + Data Integrity), then every new data space, DPP scheme, or industrial network that adopts it does not just “join another platform” – it amplifies all existing ones by lowering onboarding and trust costs across contexts. A nested, fragmented credential approach works in the opposite direction: it forces each ecosystem to carry the cost of mapping and translation, favours large aggregators who can manage the complexity, and blocks the cooperative network‑of‑networks scaling law that decentralized identity was designed to unlock. For the EUBW, the macroeconomic opportunity is exactly here: to act as the identity meta‑platform for European industry and data sovereignty, where one technical standard for credentials and proofs lets many independent ecosystems cooperate without surrendering control, and where crypto‑agile Data Integrity proofs give us a clean path through the PQC transition without breaking those network effects. To close, we should be very clear: Europe needs one coherent technical stack across EUBW, DPPs, data spaces (including EU data sovereignty initiatives), Industry 4.0, supply chains, UNTP, and ZTA, with built‑in crypto agility to handle the PQC transition. If we fragment this with nested formats and parallel models, we push complexity and cost onto every industrial actor and lose the macro‑economic benefits that a common, reusable credential layer can create. A consistent VCDM + Data Integrity foundation lets industry reuse the same credentials and proofs across wallets, data spaces, digital product passports and Zero Trust control planes, while still allowing cryptosuite upgrades and PQC migration when needed. The EUBW is our chance to align these pieces once, at European scale, instead of forcing each ecosystem to solve the same hard problem in isolation. Engaging in the ultimate, existential race for Trusted AIIf we get this right, the EUBW can also become the missing trust layer for industrial AI. Industrial AI will only be as good as the data, context and provenance it can rely on. That means simple and consistent credential formats, strong semantics, A2A protocol integration, Zero Trust principles and robust credential chaining, from registries and data spaces all the way to models and agents. A coherent EUBW stack based on VCDM JSON‑LD and Data Integrity gives us exactly that: machine‑readable meaning, verifiable origin, and a graph of credentials that AI systems can consume directly for access control, risk evaluation and compliance. This is a strategic topic. It is one of the few levers (if not the only) Europe must deliver in the race for "trusted industrial AI". By aligning EUBW, DPPs, data spaces, AI, and ZTA on one simple and expressive credential stack now, we give European industry a common trust fabric that AI can build on, and we position Europe strongly in the global race for safe, explainable and regulator‑ready industrial AI. |
|
Having had payments and trade finance in my Nordea organisation I have not been able to imagine that EU is not going fully for linkable data with EUBWs.. and DC4EU is all for it.. |
|
EUBW and DPP : open international ecosystems for data sharing. Sharing data over and across international borders is the fundamental objective of both the Digital Product Passport (DPP) and the EU Business Wallet. This last is a fundamental enabler for the DPP, without which the mandatory capabilities of the DPP system cannot be achieved. Hence it is both logical and fundamental that both be built using similar technology stacks. The reference to controlled vocabularies providing the necessary context has already been the focus of consensual discussions in the standardisation committee mandated to deliver standards for the European DPP (CEN/CENELEC JTC-24). Reasons for adopting this approach are provided in the proposed system architecture developed by the CIRPASS project The very first recommendation for implementation made by the CIRPASS-2 consortium (see page 32) is to use the JSON-LD serialization format: CIRPASS-2 is actively developing core vocabularies to support this approach: Because of the importance of semantic interoperability in the DPP context, I recorded this youtube tutorial that explains this in simple terms. The arguments are the same for the EU BW. Carolynn Bernier, CIRPASS-2 project coordinator The CIRPASS and CIRPASS-2 projects respectively received and receives funding from the European Commission under the DigitalEurope Programme and is directly supervised by DG CONNECT. |
|
Great text, Fix the Typos in "Additional formats: SD‑JWT‑VC and mDoc MAY be supported as additional credential formats where human‑centric use cases justify them (e.g. low-volumen sole traders use cases such as openeing a bank account or government interaction), but they SHOULD NOT be the only or primary formats for EUBW legal‑person / B2B credentials." And also, these are not low-volume use cases in many geographies and should be treated as such. |
Just let me clarify. The ADR defines
Transport: The protocols for issuing and presenting credentials should be independent from the credential format. Therefore, I would like to separate this discussion. Just a remark: OID4VCI/OID4VP supports both In summary, the goal of the ADR is not to propose semantic modelling on top of mDoc and SD-JWT-VC. Rather, the goal is to enable the use of the |
|
Thanks, @cstoecker. Thanks for a good summary of why VCDM plus Data Integrity matters for industrial and B2B ecosystems. I agree that Catena X, Gaia X, UNTP and the data spaces work are critical reference points for the European Business Wallet. At the same time, I am concerned that we are drifting away from the concrete WE BUILD scope and use cases. I am aligned here with @fredriklinden's comments, but it's not a MAY, it's a SHALL IMHO. From what I see in WE BUILD Consortium WP2 and WP3, and from the EWC experience with age verification and similar flows, WE BUILD needs something concrete:
From this perspective, I see two key points that need to be addressed:
As a WE BUILD Consortium member, the starting point for WE BUILD should be:
In other words, I fully agree that VCDM JSON LD plus Data Integrity is a strong candidate for the industrial “orange ocean”. However, from a WE BUILD architecture point of view, I would prefer that our ADR:
Otherwise, we risk designing a Business Wallet that is optimised for industrial pilots but is hard to plug into the EIDAS 2.0 individual wallet stack and the concrete WE BUILD use cases that depend on it. |
@lalc, I just want to be sure I've got you right: According to the ADR's proposed decisions, no changes are needed.
Finally, W3C-VCDM works with SD-JWT. You can also use ECDSA-SD and BBS. So, selective disclosure and data minimisation isn't a problem. |
|
EUBWs naturally have to serve global trade. B2b and b2g credentials need to be supported with harmonised semantics and standardisation for deeper automation. Much work to do.
Bo Harald
… On 17. Nov 2025, at 11.14, carolynnbernier ***@***.***> wrote:
carolynnbernier
left a comment
(webuild-consortium/wp4-architecture#26)
<#26 (comment)>
EUBW and DPP : open international ecosystems for data sharing.
Sharing data over and across international borders is the fundamental objective of both the Digital Product Passport (DPP) and the EU Business Wallet. This last is a fundamental enabler for the DPP, without which the mandatory capabilities of the DPP system cannot be achieved. Hence it is both logical and fundamental that both be built using similar technology stacks.
The reference to controlled vocabularies providing the necessary context has already been the focus of consensual discussions in the standardisation committee mandated to deliver standards for the European DPP (CEN/CENELEC JTC-24).
Reasons for adopting this approach are provided in the proposed system architecture developed by the CIRPASS project
D3.2 DPP System Architecture <https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf>
D5.1 DPP Prototypes <https://cirpassproject.eu/wp-content/uploads/2024/05/D5.1-DPP-Prototypes.pdf>
The very first recommendation for implementation made by the CIRPASS-2 consortium (see page 32) is to use the JSON-LD serialization format:
D4.1 REFERENCE ARCHITECTURE – May 13, 2025 <https://zenodo.org/records/15467720>
CIRPASS-2 is actively developing core vocabularies to support this approach:
Ontology Requirements Specification for an EU DPP Core Ontology Proposal – March 12, 2025 <https://zenodo.org/records/15270342>
The second iteration of the core vocabularies has been published here:
CIRPASS-2 vocabularies <https://dpp.vocabulary-hub.eu/specifications>
Because of the importance of semantic interoperability in the DPP context, I recorded this youtube tutorial that explains this in simple terms. The arguments are the same for the EU BW.
Tutorial on Semantic Interoperability for Digital Product Passports – July 18, 2025 <https://www.youtube.com/watch?v=D08pUcBIDUU>
Carolynn Bernier, CIRPASS-2 project coordinator
The CIRPASS and CIRPASS-2 projects respectively received and receives funding from the European Commission under the DigitalEurope Programme and is directly supervised by DG CONNECT.
—
Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASJMQABJHSMSDCQ3QDNBH5335GGYTAVCNFSM6AAAAACMDFWQRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBQG4YTMNZTGQ>.
You are receiving this because you commented.
|
Introduction to Citizen vs Employee IdentityWhen an EUBW interacts with a Citizen Wallet, the use of EUDIW formats is given (PID/LPID with mDoc and SD‑JWT‑VC). This covers B2C e‑commerce and similar flows. There is no dispute here. No additional work is needed now, except integration work later when the solutions are mature and the timing is right. Integrating too early would create unnecessary friction. The situation is different when an EUBW interacts with an Employee Wallet in end‑to‑end (E2E) use cases. Employee wallets are not analysed at all in the EWC / WE BUILD work so far, although they will be central for many WE BUILD scenarios (e.g. delegated authority, field staff, operators of critical systems). New employees may be onboarded using their Citizen Wallet, but the day‑to‑day B2B workflows then run in an employment context with very different requirements. In this insights paper “Verifiable Credentials in ‘Private Individual’ vs ‘Employee’ Contexts (X2I vs X2E)” we show that these two contexts follow different rules. X = Government or Business. In the citizen (X2I) (we use the term private individuals in the paper instead of citizens, because the wallet should also cater for non‑citizens) case, the wallet is personal, the person acts in a private role, and privacy expectations are strict: data minimisation, low tracking, consent is voluntary, and the main goal is user autonomy. In the employee (X2E) case, the wallet is part of the employer’s operational environment: the person acts on behalf of an organisation, credentials encode roles and responsibilities, and some logging and “phoning home” is often required for safety, compliance, audit trails and ZTA. Consent is less symmetric, labour law and internal policy play a strong role, and the organisation must be able to enforce policies (e.g. revocation, rotation of roles, shift logging). Mixing these two patterns into one undifferentiated “natural person wallet” leads to governance and adoption problems, as the Vienna election case in the paper already illustrates. Ausweis nicht vergessen: Die Wien-Wahl bleibt analog. In WE BUILD we should therefore not by default assume that the same architectural choices that work for a Citizen Wallet will also work for an Employee Wallet. The regulatory picture for employee wallets is still unclear: we are between eIDAS/EUDIW on one side and labour law, health and safety, works councils, and sector rules as well as EUBW on the other. This regulatory gap makes it even more important to analyse requirements first before we lock in any technical decisions. B2B, M2M, A2A ConsensusIt is encouraging that there seems to be early consensus to use W3C VCDM with JSON‑LD for B2B, M2M and A2A use cases in WE BUILD. This is a strong basis for EUBW ↔ EUBW and EUBW ↔ data‑space / AI Agent interactions . It also gives us a natural candidate stack for Employee Wallets in an organisational context, because role‑based credentials, delegation chains and ZTA policy decisions need graph‑based semantics and credential chaining. Proposed methodology for WE BUILDBased on this, I would like to make the following proposal for next steps:
I believe this would help WE BUILD in three ways:
I would welcome feedback on this proposal and support from other partners to start a dedicated workstream on Employee Wallet requirements and B2E pilots inside WE BUILD. |
|
First history: BankID started as identification credential for employees sending corporate loan applications to insurance company net services in Finland in 1992. When Internet came these needs multiplied. One example was for teachers identifiying themselves when giving grades. This lead to somewhat political debate about how right it is to force employees to use a personal BankID at work. My counterargument was that they already use their personal passports, drivers licences and skill credentials at work. So it became an existing practise to use BankID also as a de-facto signing-on-behalf-of-employer tool. Now I agree with cstoecker that there is a need to analyse how the situation is changing for natural (privacy risks) and also virtual employees. This also links to ongoing LPID/LEI/vLei discussions. The backdrop is the "human right" for pre-employees to get all the credentials they need to their wallets for job applications and the duty for employers to have EUBWs to receive them - and use them to "upgrade" CVs. Also get clarity as to how business registers' role as to general power to act must be available in real time - completed with task-specific PoAs. |
|
There seems to be a consensus in this discussion that WE BUILD should embrace both Luckily, there already exists an interoperability profile that encompasses both formats. The Decentralized Identity Interop Profile (
The DIIP conformance test suite has been implemented using the same Interoperability Test Bed that the WE BUILD consortium is using (and that the EWC pilot used). It is maintained by the same people (especially @endimion).
It would make things simpler for everyone if WE BUILD just stated that the consortium uses the |
|
All for the easier DIIP-path |
Personally, I had hopes that one could combine the W3C VC Data Model (for semantic description of rich structures) and However, the W3C has opted to define a separate way of using
(See the end of section 1.2.) The Thus, in my opinion, it doesn't seem a best practice to separate the credential format and the proof mechanism as separate things you can pick-and-choose or mix-and-match. I see the temptation, but the devil is in the details of implementation. See FIDEScommunity/DIIP#67 as an example. |
|
All too technical for me, but I like the IHE way of testing. I do like the *Global ** EU ***National for each InteropSpec way-of-working. Having said this I also want to say I hate #InformationBlocking and we MUST not end up in that situation where the National and EU ITB diverge into oblivion. .....or the VLOP eg. https://fides.community/community-tools/personal-wallets/ or even SAP-Value-Networks or the like win the Specifications and Standards race based on unethical sponsoring of initiatives. A Use case/REQ from me as an employee could be to bring with me my Certificate of X (eg. Project mgt/Architecture education in method Y) when I leave my employer. It may come from either an internal or external certifier. It is in my EUBW and/or EUDI-wallet. When it comes to Ontologies (and Data models) I usually just reference ISO21838 and it is not yet part of the Rollingplan on ICT standardisation so no luck there yet in getting guidance. I am a fan of DLT (and EBSI) so anything moving us away from pure PKI/BankID is usually a positive. |
|
How much progress towards JSON-LD today?
… On 18. Nov 2025, at 10.59, Fredrik Lindén ***@***.***> wrote:
fredriklinden
left a comment
(webuild-consortium/wp4-architecture#26)
<#26 (comment)>
All too technical for me, but I like the IHE way of testing. I do like the *Global ** EU ***National for each InteropSpec way-of-working. Having said this I also want to say I hate #InformationBlocking and we MUST not end up in that situation where the National and EU ITB diverge into oblivion. .....or the VLOP eg. https://fides.community/community-tools/personal-wallets/ or even SAP-Value-Networks or the like win the Specifications and Standards race based on unethical sponsoring of initiatives. A Use case/REQ from me as an employee could be to bring with me my Certificate of X (eg. Project mgt/Architecture education in method Y) when I leave my employer. It may come from either an internal or external certifier. It is in my EUBW and/or EUDI-wallet.
When it comes to Ontologies (and Data models) I usually just reference ISO21838 and it is not yet part of the Rollingplan on ICT standardisation so no luck there yet in getting guidance. I am a fan of DLT (and EBSI) so anything moving us away from pure PKI/BankID is usually a positive.
—
Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASJMQAHZDIHDWFTS4XDNXMT35LNWBAVCNFSM6AAAAACMDFWQRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBWGI4TSNRXGE>.
You are receiving this because you commented.
|
|
I agree with @lalc comments — it is drifting away from the concrete WE BUILD scope and defined use cases. Here are reasons: This has implications for legal entity data: b. Legal Entity Organisation–Specific Data — Governance & Authority which has the purpose to define who is authorised to act on behalf of the entity. That’s why: If this is not achieved, SMEs cannot maintain multiple identity formats for identification and authorisation. Reason 2 — Legal Entity Process–Specific Data (Operations & Compliance) has the purpose to support operational, financial, and regulatory processes. Practical Example: A typical cross-border KYB between two partners requires 7–8 organisations: Reason 3 — Modular Scenario Design in WE BUILD Practical Example: A basic procurement + invoicing + payment flow involves over 20 organisations across 4 scenarios. Reason 4 — Legal Entity Product/Data (Domain-Specific) this covers product-level or sector-specific compliance information. My Recommendation |
|
I think this must be looked into now " cstoecker: "In the citizen (X2I) (we use the term private individuals in the paper instead of citizens, because the wallet should also cater for non‑citizens) case, the wallet is personal, the person acts in a private role, and privacy expectations are strict: data minimisation, low tracking, consent is voluntary, and the main goal is user autonomy. In the employee (X2E) case, the wallet is part of the employer’s operational environment: the person acts on behalf of an organisation, credentials encode roles and responsibilities, and some logging and “phoning home” is often required for safety, compliance, audit trails and ZTA. Consent is less symmetric, labour law and internal policy play a strong role, and the organisation must be able to enforce policies (e.g. revocation, rotation of roles, shift logging). Mixing these two patterns into one undifferentiated “natural person wallet” leads to governance and adoption problems, as the Vienna election case in the paper already illustrates. Ausweis nicht vergessen: Die Wien-Wahl bleibt analog." |
|
The Vienna election case is really interesting. If I understand correctly what happened, election volunteers did not want to use their own personal wallets to verify the identity of voters. Perhaps they did not trust that this would not leave any "trace". So the Austrian government would need to create "election volunteer" credentials (using either the volunteeer's paper ID or eID) for volunteers and an "election volunteer" wallet (=EBW) app. |
|
We should find time to sketch the why and how for b2e. As said before work use of personal tools - as own e-ID - is established practise here. |
|
Thanks for all your explanations and inputs. As representative of railway industry, I like to share with you our business needs regarding product data exchange: This statement bases on regulatory requirements with impact on credential format. new Construction Product Regulation (CPR)
Ecodesign for Sustainable Product Regulation (ESPR)
Proposal of European Business Wallet Regulation : Conclusion WE support ARD regarding W3C-VCDM that covers mentioned requirements. Please add W3C-VCDM to the list of available credential formats within We Build and let's test W3C-VCDM in use cases. |
|
W3C-VCDM for sure needed for industry and global trade - and EUs role there |
|
I think it is premature to identify a "winner". I don't have a problem including the vc2.0 model into the list of "should implement" but given the current state of play of zkp it is definitely premature to be absolutely sure about what will work and not. Somebody on this thread made the claim that dc4eu supports vc2.0. This is not strictly true. There were some parties in dc4eu who bet heavily on vc2.0 but certainly not everyone. If you look to the practical deployments related to higher education infra it is certainly not using vc2.0 at this point. I have several problems with vc2.0 as an implementer:
I do not want to dissuade from adopting vc2.0 as one of the data models - certainly not for a demo, poc or experiment - but to classify it as the main solution is imo irresponsable at this time. |
|
I do not think we should declare a "winner" but see to it that the needs of enterprises and global trade are supported. EU competitiveness is so important. Is ZKP problematic in b2b and g2b/b2g? How absolutely sure can one be in any case? |
|
Yes zkp will be used both in b2b and b2g cases. I am not arguing for excluding vc2.0 but I am arguing against an ADR that sais that vc2.0 is the primary format for the EUBW. |
|
Hi @DominicHurni I fully agree that product information and other relevant data need to be verifiable (also EUBW Proposal specify - "DPP product data will be exchanged securely and verifiably across borders") Only 25% of companies in EU deals with product and other data exchanges directly or indirectly. For example: if a company produces products and need to attest the instance need 10K-100K attestation to store and linked to others (DoC, PPWR)... It is unrealistic to expect that this volume of product-related data would be stored in the EuBW. In short: the EuBW should remain focused on identity, organization and legal compliance. |
|
We should lean on Carsten Stoecker's knowhow: "Now it takes courage and the unconditional entrepreneurial will for the global battle for Trusted Industrial AI. We are there. Who will go along with it? Industrial AI can only succeed with unconditional will, world-class teams, a high use of resources and interdisciplinary work. In the global competition for AI-powered cyber-physical systems, we have so far seen only a few companies in Europe that have all of this. If we lose this battle – including Science AI – Industry 4.0 will be ready for a museum. The marathon triple jump is decisive: Industrial AI → Trusted Industrial AI → real value creation. Trusted AI means: traceable models, robust data, audited processes, clear identities, verifiable digital powers of attorney for AI agents, auditability and liability capability. The Industrial AI Use Case incl. AI Functional Safety, The Trust Layer is not an optional extra, but an absolutely necessary prerequisite for operating license, certification and value creation in industrial infrastructures. This is exactly where Europe has a head start: eIDAS 2.0 and the European Business Wallet create a legally anchored trust layer for Industrial AI. " |
In your previous comment, you were worried that the ecosystem would get fragmented if multiple credential formats had to be supported. Having one credential store (business wallet) for identity/compliance credentials and another for product-related credentials is much more harmful fragmentation than a wallet supporting many credential formats. It would be akin to using different browsers for PNGs and SVGs. (There are reasons why there are various formats for presenting images online. There are also reasons why different use cases need different credential formats. Implementing support for multiple formats is an additional effort for software vendors. For users, it means that the format best suited for a task can be used.) |
|
@samuelmr The EuBW first requires a mutual authentication between actors, which is a fundamentally different for a tool rendering. Mutual authentication depends on strong, uniform trust anchors and not on format diversity. Otherwise, we could simply fall back to signed PDFs. The EUBW is for identity, trust and authentication, not for handling of product data, sustainability records...
Yes, in both cases we have a fragmentation - the question is which type of fragmentation has the lowest impact while still offering flexibility and support for scalability. Option 2: Keep the EuBW as identity layer and allow flexibility at the product/sector level
I’m not sure I fully understand this point. Are you referring here to the format for non-identity data? |
|
I am late to the conversation it seems, but i can add some small perspective from the PID/EBWOID (European Business Wallet Owner Identification Data) group. I would agree with Lal's comment earlier that we within WeBuild primarily serve the use-cases identified within WeBuild. Those use-cases who explicitly ask for the JSON-LD format should describe their needs here and then we can supply f.ex. a in that format. We will though start with SD-JWT since the PID/LPID group has - up to now - not heard from the official use-cases within WeBuild about needing JSON-LD, but a lot about wanting to test SD-JWTs and a some few voices about mDoc. |
|
In general I agree with the feedback by with @michelleludovici-ai, @leifj, @lalc. To move forward towards a use case-based decision for WE BUILD (not EBW in general): we now have a list of required attestations. Do these include any that require W3C VCDM 2.0? And for these, does SD-JWT VC suffice as a VCDM implementation, or are there requirements that can only be solved using JSON LD? |
13 participants
The purpose of this ADR is to clarify the use of the W3C-VCDM credential format within the context of the EUBW. For various reasons, it is recommended that W3C-VCDM be defined as the preferred credential format for the EUBW. It allows use case owners to select the most suitable credential format for their particular use case, as it removes the exclusive use of mDOC and SD-JWT-VC for PID, LPID and QEAA.