From 9febd5f4a21d1abe5d9330818e3d0349fb504d02 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Fri, 7 Nov 2025 17:38:07 +0100 Subject: [PATCH 1/8] Initial commit: EUBW attestation format Expanded the document to detail the preferred EUBW attestation format, including context, decisions, and consequences related to semantic interoperability and use cases. --- adr/EUBW-attestation-format.md | 71 ++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 adr/EUBW-attestation-format.md diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md new file mode 100644 index 00000000..aa68a1b7 --- /dev/null +++ b/adr/EUBW-attestation-format.md @@ -0,0 +1,71 @@ +# Preferred EUBW attestation format + +**Authors:** + +- Ronald Koenig, Spherity, Germany + +## Context + +The Architecture and Reference Framework (ARF) currently focuses on the EUDI wallet for natural persons. The specific requirements of an EU business wallet (EUBW) for legal entities are not being thoroughly considered. + +The ARF defines the following three attestation formats: +* The format specified in [ISO/IEC 18013-5] and generalised in [ISO/IEC 23220-2], +* The format specified in 'SD-JWT-based Verifiable Credentials' [SD-JWT VC], +* The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0]. +It also states that the third format is optional and intended for non-qualified EAAs only. This means that the wallet ecosystem must use one of the first two options for PID, LPID and QEAAs. + +Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5: https://www.iso.org/standard/69084.html]). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: + +* [eGoverment Core Vocabularies](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/e-government-core-vocabularies) +* [UN Transparency Protocol - UNTP Web Vocabularies](https://test.uncefact.org/vocabulary/untp/home) +* [European Union Agency for Railways](https://app.ontorail.org/ontorail) +* [Common data - schema.org](https://schema.org/) +* [DssC Dataspaces - Identity Credentials](https://dssc.eu/space/BVE2/1071254873/Building+on+Top+of+Foundational+Technical+Standards#2.1-Verifiable-Credentials) + +Furthermore, modelling the complex attestations for the following WeBuild use cases requires extensive conceptual modelling support: + +* BU1 'KYC/KYB/KYD/Due Diligence' regarding the semantic modeling of KYC credentials as well as authorisations for natural persons acting on behalf of legal persons +* SC1 'Authentication and access for transport' regarding semantic alignment with public global vocabularies (e.g. railways) +* SC2 'Trusted data sharing for data spaces' regarding complex policies for negotation and access as well as roles for automated actors and devices +* PA3 'Corporate banking and account opening': AML requires KYC and including delegation of authority + +Besides the semantic interoperability on business level, existing eco systems also require semantic compatibility on technical level: + +* Verifiable credentials: [Verfiable Credentials Vocabulary](https://www.w3.org/2018/credentials/) +* Linked Data: [JSON-based Serialization for Linked Data](https://www.w3.org/TR/json-ld11/) +* Decentralized Identifiers: [DID](https://www.w3.org/ns/did/v1) + +In addition to semantic interoperability at a business level, existing ecosystems also require semantic compatibility at a technical level. + +* Global Linking of nodes of attestation data +* Multi Key binding to nodes inside attestation data +* data transformation and canonicalisation +* semantic data processing +* data framing + +Restricting EUBW usage to mDoc and SD-JWT-VC would greatly reduce the range of supported ecosystems and implementation options. Furthermore, it becomes difficult or almost impossible to implement use cases requiring complex attestation, support for linked attestations, and interoperability with global semantic vocabularies. + +## Decision + +Define W3C VCDM 2.0 as the preferred attestation format for the EUBW. +Allow the use case owner to select the most suitable attestation format for their use case. + +## Consequences + +The range of supported use cases and ecosystems will increase significantly. +Reusing existing global vocabularies will improve cross-border interoperability and streamline the process of negotiating semantics across Europe, particularly with regard to finding common solutions to the different legal requirements of EU member states. +W3C provides a mature set of recommendations regarding verifiable credentials. Reusing existing standards will significantly reduce the specification effort and improve the quality of the solution. + +What will become more difficult? +Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (@context, @id and @type). While this can introduce unnecessary complexity for simple data, it improves semantic alignment. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. + +An interoperability profile based on existing standards (e.g. supported proof mechanisms, credential status methods, DID methods, etc.) should be defined to reduce complexity and testing effort. +Testing (ITB) needs to be conducted for all selected attestation formats. + +## Advice + +Once merged, this is our consortium’s decision. This does not mean all +participants agree it is the best possible decision. In the decision +making process, we have heard the following advice. + +- yyyy-mm-dd, Name, Affiliation, Country: OK or summary of advice From ca8946d66b5571649c79a66d6d73920ad1c17cb8 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Fri, 7 Nov 2025 17:51:30 +0100 Subject: [PATCH 2/8] Clarify attestation format limitations and recommendations 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. --- adr/EUBW-attestation-format.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index aa68a1b7..0f7ff380 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -14,7 +14,7 @@ The ARF defines the following three attestation formats: * The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0]. It also states that the third format is optional and intended for non-qualified EAAs only. This means that the wallet ecosystem must use one of the first two options for PID, LPID and QEAAs. -Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5: https://www.iso.org/standard/69084.html]). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: +Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html]). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: * [eGoverment Core Vocabularies](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/e-government-core-vocabularies) * [UN Transparency Protocol - UNTP Web Vocabularies](https://test.uncefact.org/vocabulary/untp/home) @@ -57,7 +57,7 @@ Reusing existing global vocabularies will improve cross-border interoperability W3C provides a mature set of recommendations regarding verifiable credentials. Reusing existing standards will significantly reduce the specification effort and improve the quality of the solution. What will become more difficult? -Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (@context, @id and @type). While this can introduce unnecessary complexity for simple data, it improves semantic alignment. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. +Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (`@context`, `@id` and `@type`). While this can introduce unnecessary complexity for simple data, it improves semantic alignment. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. An interoperability profile based on existing standards (e.g. supported proof mechanisms, credential status methods, DID methods, etc.) should be defined to reduce complexity and testing effort. Testing (ITB) needs to be conducted for all selected attestation formats. From fb4dd99f92b140394f1afa612b15d39ea3e92b15 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Fri, 7 Nov 2025 18:11:11 +0100 Subject: [PATCH 3/8] Refine language for semantic interoperability section --- adr/EUBW-attestation-format.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index 0f7ff380..306b069d 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -29,13 +29,13 @@ Furthermore, modelling the complex attestations for the following WeBuild use ca * SC2 'Trusted data sharing for data spaces' regarding complex policies for negotation and access as well as roles for automated actors and devices * PA3 'Corporate banking and account opening': AML requires KYC and including delegation of authority -Besides the semantic interoperability on business level, existing eco systems also require semantic compatibility on technical level: +In addition to semantic interoperability at a business level, existing ecosystems also require semantic compatibility at a technical level: * Verifiable credentials: [Verfiable Credentials Vocabulary](https://www.w3.org/2018/credentials/) * Linked Data: [JSON-based Serialization for Linked Data](https://www.w3.org/TR/json-ld11/) * Decentralized Identifiers: [DID](https://www.w3.org/ns/did/v1) -In addition to semantic interoperability at a business level, existing ecosystems also require semantic compatibility at a technical level. +Finally, JSON-LD, the chosen serialisation format for W3C Verifiable Credentials, has strong capabilities for handling and processing complex data: * Global Linking of nodes of attestation data * Multi Key binding to nodes inside attestation data From c872d7800cce68d7b0cb2b919da738cf3742e9ed Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Mon, 10 Nov 2025 13:18:47 +0100 Subject: [PATCH 4/8] Revise EUBW attestation format requirements and use cases 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. --- adr/EUBW-attestation-format.md | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index 306b069d..ab0e6d45 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -9,9 +9,9 @@ The Architecture and Reference Framework (ARF) currently focuses on the EUDI wallet for natural persons. The specific requirements of an EU business wallet (EUBW) for legal entities are not being thoroughly considered. The ARF defines the following three attestation formats: -* The format specified in [ISO/IEC 18013-5] and generalised in [ISO/IEC 23220-2], -* The format specified in 'SD-JWT-based Verifiable Credentials' [SD-JWT VC], -* The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0]. +* The format specified in [ISO/IEC 18013-5](https://www.iso.org/standard/69084.html) and generalised in [ISO/IEC 23220-2](https://www.iso.org/standard/86782.html), +* The format specified in 'SD-JWT-based Verifiable Credentials' [SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/), +* The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0](https://www.w3.org/TR/vc-data-model-2.0/). It also states that the third format is optional and intended for non-qualified EAAs only. This means that the wallet ecosystem must use one of the first two options for PID, LPID and QEAAs. Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html]). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: @@ -22,11 +22,11 @@ Unfortunately, the first two options only allow the data structure of the attest * [Common data - schema.org](https://schema.org/) * [DssC Dataspaces - Identity Credentials](https://dssc.eu/space/BVE2/1071254873/Building+on+Top+of+Foundational+Technical+Standards#2.1-Verifiable-Credentials) -Furthermore, modelling the complex attestations for the following WeBuild use cases requires extensive conceptual modelling support: +Furthermore, modelling the complex attestations for the following WeBuild use cases requires comprehensive conceptual modelling support. Neither the mDoc nor SD-JWT-VC format supports mapping to these models: -* BU1 'KYC/KYB/KYD/Due Diligence' regarding the semantic modeling of KYC credentials as well as authorisations for natural persons acting on behalf of legal persons +* BU1 'KYC/KYB/KYD/Due Diligence' regarding the semantic modeling of KYC credentials as well as complex authorisations schemes for natural persons acting on behalf of legal persons * SC1 'Authentication and access for transport' regarding semantic alignment with public global vocabularies (e.g. railways) -* SC2 'Trusted data sharing for data spaces' regarding complex policies for negotation and access as well as roles for automated actors and devices +* SC2 'Trusted data sharing for data spaces' regarding complex policies for negotation and access to shared data as well as roles for automated actors and devices * PA3 'Corporate banking and account opening': AML requires KYC and including delegation of authority In addition to semantic interoperability at a business level, existing ecosystems also require semantic compatibility at a technical level: @@ -35,7 +35,7 @@ In addition to semantic interoperability at a business level, existing ecosystem * Linked Data: [JSON-based Serialization for Linked Data](https://www.w3.org/TR/json-ld11/) * Decentralized Identifiers: [DID](https://www.w3.org/ns/did/v1) -Finally, JSON-LD, the chosen serialisation format for W3C Verifiable Credentials, has strong capabilities for handling and processing complex data: +Finally, integration of complex attestations into existing business solutions require strong capabilities for handling and processing semantic data. JSON-LD, the chosen serialisation format for W3C Verifiable Credentials, provides these capabilities: * Global Linking of nodes of attestation data * Multi Key binding to nodes inside attestation data @@ -48,19 +48,28 @@ Restricting EUBW usage to mDoc and SD-JWT-VC would greatly reduce the range of s ## Decision Define W3C VCDM 2.0 as the preferred attestation format for the EUBW. -Allow the use case owner to select the most suitable attestation format for their use case. + +Allow the use case owners to define the mandatory and optional attestation formats depending on the specific needs of their use cases. + +Testing (ITB) needs to be conducted for all mandatory and optional attestation formats. ## Consequences +**What becomes easier?** + The range of supported use cases and ecosystems will increase significantly. + Reusing existing global vocabularies will improve cross-border interoperability and streamline the process of negotiating semantics across Europe, particularly with regard to finding common solutions to the different legal requirements of EU member states. -W3C provides a mature set of recommendations regarding verifiable credentials. Reusing existing standards will significantly reduce the specification effort and improve the quality of the solution. -What will become more difficult? -Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (`@context`, `@id` and `@type`). While this can introduce unnecessary complexity for simple data, it improves semantic alignment. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. +W3C provides a mature set of recommendations regarding verifiable credentials. Reusing these standards will significantly reduce the specification effort, provide a mature conceptual foundation, ensure clear separation of credential meta data and domain specific subject claims, achieve semantic interoperability and improve the quality of the solution. + +**What will become more difficult?** + +Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. + +JSON-LD adds additional semantic information to JSON data (`@context`, `@id` and `@type`). While this can introduce additional complexity for simple data, it improves semantic alignment and avoids extra mapping between local defined vocabularies. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. An interoperability profile based on existing standards (e.g. supported proof mechanisms, credential status methods, DID methods, etc.) should be defined to reduce complexity and testing effort. -Testing (ITB) needs to be conducted for all selected attestation formats. ## Advice From c96afdc37bba8a605fa41d19ba5eddcbfdf71e49 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Thu, 13 Nov 2025 14:29:40 +0100 Subject: [PATCH 5/8] =?UTF-8?q?include=20comment=20from=20Torbj=C3=B6rn=20?= =?UTF-8?q?Ull?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updated SC2 use case description to include details about credentials and authorization policies for the DSP protocol. --- adr/EUBW-attestation-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index ab0e6d45..412f778e 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -26,7 +26,7 @@ Furthermore, modelling the complex attestations for the following WeBuild use ca * BU1 'KYC/KYB/KYD/Due Diligence' regarding the semantic modeling of KYC credentials as well as complex authorisations schemes for natural persons acting on behalf of legal persons * SC1 'Authentication and access for transport' regarding semantic alignment with public global vocabularies (e.g. railways) -* SC2 'Trusted data sharing for data spaces' regarding complex policies for negotation and access to shared data as well as roles for automated actors and devices +* SC2 'Trusted data sharing for data spaces' regarding credentials to support authorization policies for the three phases of the DSP protocol (Catalog Query, Contract Negotiation and Data Transfer) as well as roles for automated actors and devices * PA3 'Corporate banking and account opening': AML requires KYC and including delegation of authority In addition to semantic interoperability at a business level, existing ecosystems also require semantic compatibility at a technical level: From eb7815be2ab335a696e07ce46f0a87facec62b53 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Thu, 13 Nov 2025 15:36:23 +0100 Subject: [PATCH 6/8] Include comments from Rene Bonte Update attestation formats and terminology in EUBW document --- adr/EUBW-attestation-format.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index 412f778e..b5e1ad41 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -9,12 +9,14 @@ The Architecture and Reference Framework (ARF) currently focuses on the EUDI wallet for natural persons. The specific requirements of an EU business wallet (EUBW) for legal entities are not being thoroughly considered. The ARF defines the following three attestation formats: -* The format specified in [ISO/IEC 18013-5](https://www.iso.org/standard/69084.html) and generalised in [ISO/IEC 23220-2](https://www.iso.org/standard/86782.html), -* The format specified in 'SD-JWT-based Verifiable Credentials' [SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/), -* The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0](https://www.w3.org/TR/vc-data-model-2.0/). + +* `mDoc`: The format specified in [ISO/IEC 18013-5](https://www.iso.org/standard/69084.html) and generalised in [ISO/IEC 23220-2](https://www.iso.org/standard/86782.html), +* `SD-JWT-VC`: The format specified in 'SD-JWT-based Verifiable Credentials' [SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/), +* `W3C-VCDM`: The format specified in 'W3C Verifiable Credentials Data Model v2.0' [W3C VCDM 2.0](https://www.w3.org/TR/vc-data-model-2.0/). + It also states that the third format is optional and intended for non-qualified EAAs only. This means that the wallet ecosystem must use one of the first two options for PID, LPID and QEAAs. -Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html]). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: +Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html])). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: * [eGoverment Core Vocabularies](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/e-government-core-vocabularies) * [UN Transparency Protocol - UNTP Web Vocabularies](https://test.uncefact.org/vocabulary/untp/home) @@ -22,7 +24,7 @@ Unfortunately, the first two options only allow the data structure of the attest * [Common data - schema.org](https://schema.org/) * [DssC Dataspaces - Identity Credentials](https://dssc.eu/space/BVE2/1071254873/Building+on+Top+of+Foundational+Technical+Standards#2.1-Verifiable-Credentials) -Furthermore, modelling the complex attestations for the following WeBuild use cases requires comprehensive conceptual modelling support. Neither the mDoc nor SD-JWT-VC format supports mapping to these models: +Furthermore, modelling the complex attestations for the following WE BUILD use cases requires comprehensive conceptual modelling support. Neither the `mDoc` nor `SD-JWT-VC` format supports mapping to these models: * BU1 'KYC/KYB/KYD/Due Diligence' regarding the semantic modeling of KYC credentials as well as complex authorisations schemes for natural persons acting on behalf of legal persons * SC1 'Authentication and access for transport' regarding semantic alignment with public global vocabularies (e.g. railways) @@ -35,7 +37,7 @@ In addition to semantic interoperability at a business level, existing ecosystem * Linked Data: [JSON-based Serialization for Linked Data](https://www.w3.org/TR/json-ld11/) * Decentralized Identifiers: [DID](https://www.w3.org/ns/did/v1) -Finally, integration of complex attestations into existing business solutions require strong capabilities for handling and processing semantic data. JSON-LD, the chosen serialisation format for W3C Verifiable Credentials, provides these capabilities: +Finally, integration of complex attestations into existing business solutions require strong capabilities for handling and processing semantic data. JSON-LD, the serialisation format of `W3C-VCDM` Credentials, provides these capabilities: * Global Linking of nodes of attestation data * Multi Key binding to nodes inside attestation data @@ -43,11 +45,16 @@ Finally, integration of complex attestations into existing business solutions re * semantic data processing * data framing -Restricting EUBW usage to mDoc and SD-JWT-VC would greatly reduce the range of supported ecosystems and implementation options. Furthermore, it becomes difficult or almost impossible to implement use cases requiring complex attestation, support for linked attestations, and interoperability with global semantic vocabularies. +Last but not least, semantic modelling allows for: +* unambiguous interpretation of the data, +* giving stronger, legally sound transactions and +* more automation and reducing modelling (documentation) effort. + +Restricting EUBW usage to `mDoc` and `SD-JWT-VC` would greatly reduce the range of supported ecosystems and implementation options. Furthermore, it becomes difficult or almost impossible to implement use cases requiring complex attestation, support for linked attestations, and interoperability with global semantic vocabularies. ## Decision -Define W3C VCDM 2.0 as the preferred attestation format for the EUBW. +Define `W3C-VCDM` as the preferred attestation format for the EUBW. Allow the use case owners to define the mandatory and optional attestation formats depending on the specific needs of their use cases. @@ -65,7 +72,7 @@ W3C provides a mature set of recommendations regarding verifiable credentials. R **What will become more difficult?** -Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (VCDM2.0) is used to avoid extra mapping between formats. +Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (Ẁ3C-VCDM`) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (`@context`, `@id` and `@type`). While this can introduce additional complexity for simple data, it improves semantic alignment and avoids extra mapping between local defined vocabularies. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. From dc42aaeeb065d82b584ead43c2b5bc025a488c72 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Thu, 13 Nov 2025 15:39:25 +0100 Subject: [PATCH 7/8] Fix formatting for preferred attestation format reference --- adr/EUBW-attestation-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index b5e1ad41..a8315435 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -72,7 +72,7 @@ W3C provides a mature set of recommendations regarding verifiable credentials. R **What will become more difficult?** -Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (Ẁ3C-VCDM`) is used to avoid extra mapping between formats. +Supporting different attestation formats can result in extra mapping. Therefore, it is recommended that the preferred attestation format for EUBW (`W3C-VCDM`) is used to avoid extra mapping between formats. JSON-LD adds additional semantic information to JSON data (`@context`, `@id` and `@type`). While this can introduce additional complexity for simple data, it improves semantic alignment and avoids extra mapping between local defined vocabularies. The use case owner should carefully select the most suitable attestation format, striking a balance between simplicity and interoperability. From a1db7258b3a8852b221060bffe4aa91b3f3b4cb1 Mon Sep 17 00:00:00 2001 From: Ronald Koenig <89250770+rkxx@users.noreply.github.com> Date: Fri, 14 Nov 2025 10:33:34 +0100 Subject: [PATCH 8/8] include comments from Martin Westerkamp 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. --- adr/EUBW-attestation-format.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/adr/EUBW-attestation-format.md b/adr/EUBW-attestation-format.md index a8315435..67ff9c74 100644 --- a/adr/EUBW-attestation-format.md +++ b/adr/EUBW-attestation-format.md @@ -16,7 +16,7 @@ The ARF defines the following three attestation formats: It also states that the third format is optional and intended for non-qualified EAAs only. This means that the wallet ecosystem must use one of the first two options for PID, LPID and QEAAs. -Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html])). However, these formats are not suitable for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: +Unfortunately, the first two options only allow the data structure of the attestation to be defined. They do not support mapping to globally defined semantic vocabularies. Global semantic interoperability cannot be achieved with these formats. This is accceptable for personal attestations with simple data structures (usually a flat list of data elements, e.g. mDL), which only require local semantic interoperability (e.g. defined within a local namespace, directly in the specification alongside the coding of the data [ISO/IEC 18013-5]( https://www.iso.org/standard/69084.html])). However, these formats are not suitable for use cases requiring deeply structured and linked attestations, such as expressing the share holder structure of a company for AML (anti-money laundering) compliance, or for attestations requiring semantic interoperability with globally defined vocabularies, e.g.: * [eGoverment Core Vocabularies](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/e-government-core-vocabularies) * [UN Transparency Protocol - UNTP Web Vocabularies](https://test.uncefact.org/vocabulary/untp/home) @@ -39,16 +39,17 @@ In addition to semantic interoperability at a business level, existing ecosystem Finally, integration of complex attestations into existing business solutions require strong capabilities for handling and processing semantic data. JSON-LD, the serialisation format of `W3C-VCDM` Credentials, provides these capabilities: -* Global Linking of nodes of attestation data -* Multi Key binding to nodes inside attestation data -* data transformation and canonicalisation -* semantic data processing -* data framing +* Global Linking of nodes of attestation data (e.g. share holder structures) +* Multi Key binding to nodes inside attestation data (e.g. list of legal representatvies) +* data transformation and canonicalisation (e.g. RDF Dataset Canonicalization) +* semantic data processing (e.g. semantic mapping of claims into existing master data) +* data framing (e.g. selective disclosure and query of selected credentials and claims) -Last but not least, semantic modelling allows for: +Last but not least, `W3C-VCDM` credentials allows for: * unambiguous interpretation of the data, -* giving stronger, legally sound transactions and -* more automation and reducing modelling (documentation) effort. +* giving stronger, legally sound transactions, +* more automation and reducing modelling (documentation) effort, +* supporting eco systems which already use `W3C-VCDM` credentials (e.g. data spaces, DPP, supply chains, etc.) Restricting EUBW usage to `mDoc` and `SD-JWT-VC` would greatly reduce the range of supported ecosystems and implementation options. Furthermore, it becomes difficult or almost impossible to implement use cases requiring complex attestation, support for linked attestations, and interoperability with global semantic vocabularies.