From ef4023911f77d17d38e56df07e1598f10101e3fa Mon Sep 17 00:00:00 2001 From: DavSanOl Date: Tue, 21 Jul 2026 11:17:46 +0200 Subject: [PATCH 1/4] EBW QERDS first draft --- blueprint/appendix-ebw-definition.md | 33 ++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/blueprint/appendix-ebw-definition.md b/blueprint/appendix-ebw-definition.md index 5914c720..46689c80 100644 --- a/blueprint/appendix-ebw-definition.md +++ b/blueprint/appendix-ebw-definition.md @@ -90,6 +90,39 @@ To enable public and private sector information exchange, such as in B2G eGovern **_WE BUILD implementation note:_** _the WP4 QTSP group will explore delivering an interoperable pre-production QERDS, along with CIR (EU) 2025/1944 requirements, as a service to the WP4 Wallet Providers group, working with the WP4 Architecture group on cross-cutting concerns, such as interoperability specifications. This enables wallet providers to provide a business wallet to the use cases with a digital address and access to the designated QERDS. For reference, see the [QERDS documentation](#qerds-documentation)._ +##### When does QERDS apply + +_**TODO**_ + +##### High-level architecture + +````mermaid +flowchart LR + RP(Relying Party) -->|Validates delivery|QP[QERDS Provider] + QP -->|Provides the QERDS|BWU[Business Wallet Unit] + BA(Business Application) -->|Uses API|BWU + U(User) -->|Uses UI|BWU + BWU -->|Discovers services and capabilities|DD[Digital Directory] + BWU -.->|Shares data|Q1 + subgraph QERDS 4-corner secure channel + Q1[QTSP 1] -.-> Q2[QTSP2] + end + Q2 -.-> BWU2[Business Wallet Unit] +```` + +##### Communication protocol: WMP + +_**TODO**_ + +##### WE BUILD Conformance Specifications mapping + +_**TODO:** Add the conformance specs links below_ + + - Delivery validation — [CSXX: RP-QERDS validation]() + - QERDS Provider — [CSXX: Inter-QTSP Message Relay]() + - QERDS provision — [CSXX: EBW-QERDS API and protocol]() + - Services discovery — [CSXX: Digital Directory API]() + #### Access control mechanism To enable wallet owners, authorised representatives and other authorised users to access the business wallet while preventing unauthorised access, each business wallet implements role-based access control for the assets it protects, including digital documents and the secure communication channel. To identify, authenticate, and authorise wallet users, the access control mechanism relies on electronic identification means, such as digital identity wallets, and, potentially, on trust services for the electronic attestation of attributes. From 7b3a88bf31bd27072d6f6e59dc5d8aa69d6f4a81 Mon Sep 17 00:00:00 2001 From: DavSanOl Date: Wed, 22 Jul 2026 12:16:15 +0200 Subject: [PATCH 2/4] QERDS application table --- blueprint/appendix-ebw-definition.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/blueprint/appendix-ebw-definition.md b/blueprint/appendix-ebw-definition.md index 46689c80..093d302d 100644 --- a/blueprint/appendix-ebw-definition.md +++ b/blueprint/appendix-ebw-definition.md @@ -92,7 +92,12 @@ To enable public and private sector information exchange, such as in B2G eGovern ##### When does QERDS apply -_**TODO**_ +| QERDS applies when | QERDS does **not** apply when | +| --- | --- | +| Business documents and legal notifications needs to be exchanged. | The scenario is mainly a issuance/verification flow following a issuer-holder-verifier model. | +| A signed evidence handover is needed. | The flow only includes attestation of attributes. | +| The flow is wallet-centric or system-to-system. | The use case does not require handover evidence. | + ##### High-level architecture @@ -105,14 +110,19 @@ flowchart LR BWU -->|Discovers services and capabilities|DD[Digital Directory] BWU -.->|Shares data|Q1 subgraph QERDS 4-corner secure channel - Q1[QTSP 1] -.-> Q2[QTSP2] + Q1[QTSP 1] -.-> Q2[QTSP 2] end Q2 -.-> BWU2[Business Wallet Unit] ```` ##### Communication protocol: WMP -_**TODO**_ +````mermaid +flowchart LR + B1(Sender Business Wallet) -->|WMP|Q1[Sender QERDS] + Q1 -->|AS4| Q2[Recipient QERDS] + Q2 -->|WMP| B2(Recipient Business Wallet) +```` ##### WE BUILD Conformance Specifications mapping From c6bbe64c1b88e160f494dfcbb2a4c9d2b949b94e Mon Sep 17 00:00:00 2001 From: DavSanOl Date: Mon, 27 Jul 2026 10:12:50 +0200 Subject: [PATCH 3/4] Completed draft --- blueprint/appendix-ebw-definition.md | 39 +++++++++++++++++++--------- 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/blueprint/appendix-ebw-definition.md b/blueprint/appendix-ebw-definition.md index 093d302d..38446be4 100644 --- a/blueprint/appendix-ebw-definition.md +++ b/blueprint/appendix-ebw-definition.md @@ -88,19 +88,27 @@ For this purpose, the business wallet implements several applications, including To enable public and private sector information exchange, such as in B2G eGovernment notifications, B2B/B2G eProcurement business documents and other business use cases, a business wallet implements a secure communication channel with other business wallets, with users of digital identity wallets, or with alternative solutions provided through a gateway. This channel enables cross-border delivery and receipt of submissions and notifications with legal effect, and provides a trusted channel with public authorities and other regulated parties across the EU. The channel is implemented using a qualified electronic registered delivery service (QERDS). The digital address for the channel is registered in a standard digital directory. +Each exchange that requires legal-grade assurance produces qualified evidence of submission, relay, delivery, retrieval, and acceptance. Wallets remain the user-facing endpoints where authorised representatives and connected business applications read, approve, and manage messages; QERDS providers operate the delivery layer underneath, handling routing, inter-provider relay, and evidence creation. For the full technical flow and use-case scenarios, see the [Blueprint integration model — Secure Communication Channel](#04-integration-model) and the [QERDS documentation](#qerds-documentation). + **_WE BUILD implementation note:_** _the WP4 QTSP group will explore delivering an interoperable pre-production QERDS, along with CIR (EU) 2025/1944 requirements, as a service to the WP4 Wallet Providers group, working with the WP4 Architecture group on cross-cutting concerns, such as interoperability specifications. This enables wallet providers to provide a business wallet to the use cases with a digital address and access to the designated QERDS. For reference, see the [QERDS documentation](#qerds-documentation)._ ##### When does QERDS apply -| QERDS applies when | QERDS does **not** apply when | +QERDS is the mandatory secure legal communication channel for the European Business Wallet, although not every wallet interaction requires it. Immutable business documents should not be transferred as attestations but via QERDS (see [ADR: EAA for verifiable claims, (Q)ERDS for data transfer](https://github.com/webuild-consortium/wp4-architecture/blob/main/adr/adr-qeaa-attestations-qerds-documents.md)). + +The table below clarifies when implementations should use QERDS and when other wallet mechanisms, such as credential issuance and presentation (OpenID4VCI / OpenID4VP), are sufficient. + +| QERDS applies when | QERDS does *not* apply when | | --- | --- | -| Business documents and legal notifications needs to be exchanged. | The scenario is mainly a issuance/verification flow following a issuer-holder-verifier model. | -| A signed evidence handover is needed. | The flow only includes attestation of attributes. | -| The flow is wallet-centric or system-to-system. | The use case does not require handover evidence. | +| Business documents and legal notifications must be exchanged with delivery evidence. | The scenario is mainly an issuance or verification flow following an issuer–holder–verifier model (for example PID or QEAA presentation). | +| A signed evidence trail of submission, relay, delivery, retrieval, or acceptance is needed. | The flow only involves attestation of attributes, without document exchange semantics. | +| The flow is wallet-centric or system-to-system and requires automation or agent-based access. | The use case does not require registered-delivery evidence. | ##### High-level architecture +WE BUILD follows the [ETSI EN 319 522](https://www.etsi.org/deliver/etsi_en/319500_319599/31952201/01.02.01_60/en_31952201v010201p.pdf) four-corner model: each business wallet connects only to its own QERDS provider. Providers relay messages and evidences when both the sender and the recipient use different QTSP. The recipient's digital address and QERDS capabilities discovery uses common directory services. + ````mermaid flowchart LR RP(Relying Party) -->|Validates delivery|QP[QERDS Provider] @@ -115,23 +123,30 @@ flowchart LR Q2 -.-> BWU2[Business Wallet Unit] ```` +Data transmission, sending data and receiving data reference scenarios are described in [QERDS between wallets](https://github.com/webuild-consortium/wp4-qtsp-group/blob/main/docs/qerds/between-wallets.feature.md), which can be complemented with the corresponding sequence diagrams from [QERDS architecture overview](https://github.com/webuild-consortium/wp4-qtsp-group/blob/main/docs/qerds/architecture.md). + +Per [ADR: Separate the QERDS agent, log and relay](https://github.com/webuild-consortium/wp4-architecture/blob/main/adr/qerds-registry-relay.md), WE BUILD treats delivery agent (submission, reception, identity verification), delivery log (evidence retention), and delivery relay (inter-provider transport) as orthogonal concerns, as proposed in [ETSI TR 119 520-1](https://www.etsi.org/deliver/etsi_tr/119500_119599/11952001/01.01.01_60/tr_11952001v010101p.pdf). End-to-end confidentiality of user content is enforced at the delivery agent layer; inter-provider relay protects relay metadata and provider authentication. + ##### Communication protocol: WMP +The secure communication channel uses two complementary protocol layers. A business wallet does not exchange messages directly with another wallet or with a foreign trust service provider. Instead, each wallet interacts only with its own QERDS provider, delegating routing, evidence management, and inter-provider relay. + ````mermaid flowchart LR - B1(Sender Business Wallet) -->|WMP|Q1[Sender QERDS] - Q1 -->|AS4| Q2[Recipient QERDS] + B1(Sender Business Wallet) -->|WMP|Q1["Sender QERDS\n(QTSP 1)"] + Q1 -->|AS4| Q2["Recipient QERDS\n(QTSP 2)"] Q2 -->|WMP| B2(Recipient Business Wallet) ```` -##### WE BUILD Conformance Specifications mapping +Wallet Messaging Protocol (WMP) is the optional API access protocol between a business wallet and its QERDS provider, as decided in [ADR: Deliver business wallet data using QERDS](https://github.com/webuild-consortium/wp4-architecture/blob/main/adr/build-qerds.md) and proposed in [Pull Request #184 - QERDS EBW–QTSP Interface](https://github.com/webuild-consortium/wp4-architecture/pull/184). WMP is a JSON-RPC 2.0 messaging protocol with a mandatory MLS encryption layer for QERDS subscriber content and an evidence profile aligned with ETSI EN 319 522 registered-delivery requirements. See [Wallet Messaging Protocol](https://wmp.name) for additional information. -_**TODO:** Add the conformance specs links below_ +##### WE BUILD Conformance Specifications mapping - - Delivery validation — [CSXX: RP-QERDS validation]() - - QERDS Provider — [CSXX: Inter-QTSP Message Relay]() - - QERDS provision — [CSXX: EBW-QERDS API and protocol]() - - Services discovery — [CSXX: Digital Directory API]() +| Topic | WBCS | Architecture interface | +| --- | --- | --- | +| EBW-QERDS API and protocol | [(PR #184) CS-005: EBW–QTSP WMP Interface](https://github.com/webuild-consortium/wp4-architecture/pull/184) | Data transmission; evidence transmission; notification creation; data submission | +| Inter-QTSP message relay | [(PR #261) CS-007: QeRDS Four-Corner AS4](https://github.com/webuild-consortium/wp4-architecture/pull/261) | Message relay | +| Credential presentation at QERDS onboarding | [CS-002: Credential Presentation](https://github.com/webuild-consortium/wp4-architecture/blob/main/conformance-specs/cs-02-credential-presentation.md) | Identity verification | #### Access control mechanism From cdcdc9a39ccca650bf1ae60754a7718d22fa09d9 Mon Sep 17 00:00:00 2001 From: DavSanOl Date: Tue, 4 Aug 2026 09:02:22 +0200 Subject: [PATCH 4/4] 'When QERDS apply' section deleted; WMP usage disclaimer --- blueprint/appendix-ebw-definition.md | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/blueprint/appendix-ebw-definition.md b/blueprint/appendix-ebw-definition.md index 38446be4..d449931d 100644 --- a/blueprint/appendix-ebw-definition.md +++ b/blueprint/appendix-ebw-definition.md @@ -92,19 +92,6 @@ Each exchange that requires legal-grade assurance produces qualified evidence of **_WE BUILD implementation note:_** _the WP4 QTSP group will explore delivering an interoperable pre-production QERDS, along with CIR (EU) 2025/1944 requirements, as a service to the WP4 Wallet Providers group, working with the WP4 Architecture group on cross-cutting concerns, such as interoperability specifications. This enables wallet providers to provide a business wallet to the use cases with a digital address and access to the designated QERDS. For reference, see the [QERDS documentation](#qerds-documentation)._ -##### When does QERDS apply - -QERDS is the mandatory secure legal communication channel for the European Business Wallet, although not every wallet interaction requires it. Immutable business documents should not be transferred as attestations but via QERDS (see [ADR: EAA for verifiable claims, (Q)ERDS for data transfer](https://github.com/webuild-consortium/wp4-architecture/blob/main/adr/adr-qeaa-attestations-qerds-documents.md)). - -The table below clarifies when implementations should use QERDS and when other wallet mechanisms, such as credential issuance and presentation (OpenID4VCI / OpenID4VP), are sufficient. - -| QERDS applies when | QERDS does *not* apply when | -| --- | --- | -| Business documents and legal notifications must be exchanged with delivery evidence. | The scenario is mainly an issuance or verification flow following an issuer–holder–verifier model (for example PID or QEAA presentation). | -| A signed evidence trail of submission, relay, delivery, retrieval, or acceptance is needed. | The flow only involves attestation of attributes, without document exchange semantics. | -| The flow is wallet-centric or system-to-system and requires automation or agent-based access. | The use case does not require registered-delivery evidence. | - - ##### High-level architecture WE BUILD follows the [ETSI EN 319 522](https://www.etsi.org/deliver/etsi_en/319500_319599/31952201/01.02.01_60/en_31952201v010201p.pdf) four-corner model: each business wallet connects only to its own QERDS provider. Providers relay messages and evidences when both the sender and the recipient use different QTSP. The recipient's digital address and QERDS capabilities discovery uses common directory services. @@ -140,6 +127,8 @@ flowchart LR Wallet Messaging Protocol (WMP) is the optional API access protocol between a business wallet and its QERDS provider, as decided in [ADR: Deliver business wallet data using QERDS](https://github.com/webuild-consortium/wp4-architecture/blob/main/adr/build-qerds.md) and proposed in [Pull Request #184 - QERDS EBW–QTSP Interface](https://github.com/webuild-consortium/wp4-architecture/pull/184). WMP is a JSON-RPC 2.0 messaging protocol with a mandatory MLS encryption layer for QERDS subscriber content and an evidence profile aligned with ETSI EN 319 522 registered-delivery requirements. See [Wallet Messaging Protocol](https://wmp.name) for additional information. +> Note: This blueprint uses WMP as the protocol selected within WE BUILD for piloting and testing the EBW-QERDS interface, in anticipation of the Commission Implementing Regulation. Please note that WMP is not a formally standardised protocol and should not be interpreted as such. + ##### WE BUILD Conformance Specifications mapping | Topic | WBCS | Architecture interface |