WE BUILD — Architecture & Integration Blueprint (D4.1)

1 Executive Summary and Project Context

1.1 Background

WE BUILD is a Large Scale Pilot (LSP) funded by the European Commission. The project tests how the European Digital Identity (EUDI) Wallet and the European Business Wallet (EBW) can support cross-border business processes across the EU.

The goal is practical: reduce administrative barriers that slow down companies when they operate across borders, such as opening a bank account, exchanging trusted business documents, or registering a branch in another country.

WE BUILD is organised around 13 concrete use cases that demonstrate how digital identity wallets can support real business processes. These use cases are grouped into three main areas:

• Business (WP2) – processes such as company registration, mandates and representation.
• Supply Chain (WP2) – logistics, transport documentation and electronic invoicing.
• Payments & Banking (WP3) – secure payments and simplified onboarding to financial services.

1.2 WE BUILD’s Role in the EUDI and EBW Journey

WE BUILD operates within the emerging EUDI and EBW ecosystem, but it is not the final production environment. Instead, the project acts as a large-scale pilot where technical solutions, governance models and interoperability rules can be tested through real use cases.

In the final EUDI ecosystem, every EU citizen will receive an EUDI Wallet at Level of Assurance (LoA) High.

WE BUILD focuses in particular on the EBW, designed for economic operators to manage mandates, exchange trusted business documents such as electronic invoices, and receive legally valid notifications. Some EBW functions, such as onboarding and data portability, will operate at LoA Substantial.

1.2.1 Bridging ARF Gaps through Specifications and Testing

The future EUDI ecosystem is defined through the Architecture Reference Framework (ARF). Because the ARF is still evolving, it does not yet cover every implementation detail. In the WE BUILD pilot environment, the full certification and qualification schemes used in production cannot always be applied.

To address these gaps, WE BUILD defines project-specific implementation rules through: - WE BUILD Conformance Specifications (WBCS) – technical rules that implementations must follow. - Architectural Decision Records (ADRs) – documented architecture decisions that guide the project.

In the final ecosystem, wallets and services must undergo formal certification by national supervisory bodies.

WE BUILD does not	WE BUILD does
certify EUDI wallets	provide WE BUILD wallets that pass ITB testing
rely on eIDAS-eID	provide WE BUILD eID with fictitious but realistic identities
create eIDAS-qualified e-signatures	define WE BUILD qualification of e-signatures focused on technical interoperability
use real MS registries	use real public sector bodies where possible, otherwise simulate them using fictitious
use the EC List of Trusted Lists (LoTL)	provide a WE BUILD LoTL
use the MS Trusted lists (TL)	provide WE BUILD TLs with input from supervisory bodies where available
reach production-level legal liability	operate within the WE BUILD agreement and trust framework, not within eIDAS
deal with national policy-making	use the WP5 MS Forum to indicate alignment with national policy-making
deal with universal definitions	define WE BUILD semantics within the available timeframe
issue EUDIW-RP access certificates	issue WE BUILD RP access certificates
issue eIDAS-QEAA	define WE BUILD QEAA focused on technical interoperability

1.3 Work Package 4 (WP4) - General Capabilities

The technical groups in WP4 - Architecture, Semantics, Wallet Providers, PID & EBWOID Providers, Qualified Trust Service Provider (QTSP), Trust Registry Infrastructure, and Test Infrastructure - provide the technical capabilities that support the use cases.

WP2 and WP3 use cases are expected to use the capabilities provided by WP4 rather than developing parallel technical solutions.

To ensure interoperability across participants, WE BUILD uses three levels of documentation:

1. This Architecture & Integration Blueprint (D4.1) - the high-level architecture and system overview.
2. Architectural Decision Records (ADR) - explains major architecture decisions and the reasoning behind them.
3. WE BUILD Conformance Specifications (WBCS) – defines the detailed technical requirements that implementations must follow.

The governance process behind ADRs and WBCS, including how decisions are proposed and adopted, is described in Chapter 7.

The Interoperability Testbed (ITB) is a first step toward understanding conformity assessment requirements. In a controlled consortium environment, regulatory and technical specifications are translated into executable interoperability scenarios.

1.4 Getting Started

The Blueprint is the starting point for understanding how WE BUILD works.

• Technical teams should begin with the WBCS to implement their interfaces.
• Architects should review the ADRs to understand the key architecture decisions.
• Every implementation must pass through the Interoperability Testbed (ITB) before participating in pilots.

2 Regulatory and Foundational Alignment

The WE BUILD architecture aligns with two key regulatory instruments: Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183 (commonly referred to as the amended eIDAS Regulation), and the proposed European Business Wallet proposal for economic operators.

2.1 The EUDI Framework

WE BUILD aligns with the legal and technical framework for EUDI wallets. Users can authenticate and present identity and attribute information while retaining control over what data is shared through selective disclosure and explicit consent.

The amended eIDAS Regulation is supported by several implementing acts defining the technical and governance framework for the EUDI Wallet ecosystem, most importantly:

Core Wallet Architecture and Technical framework

• 2024/2979 – Integrity and core functionalities
• 2024/2982 – Protocols and interfaces
• 2024/2981 – Certification framework
• 2024/2980 – Notification obligations within the Wallet ecosystem

Person Identification Data (PID) and Electronic Attestations of Attributes (EAA)

• 2024/2977 – PID and electronic attestations of attributes
• 2025/1569 – Electronic attestations of attributes

Wallet Ecosystem Governance and Relying Parties

• 2025/848 – Registration of wallet-relying parties
• 2025/849 – Submission of information on certified European Digital Identity Wallets
• 2025/847 – Reactions to Wallet security breaches
• 2025/846 – Cross-border identity matching for natural persons

Trust Services and QSCD Framework

• 2025/1566 – Verification of identity and attributes (QTSs)
• 2025/1567 – rQSCD management
• 2025/1570 – Notification of certified or cancelled QSCDs
• 2025/1572 – QTSP initiation, notification and verification

2.1.1 Standardisation and Technical Specifications

The European Commission, together with the European Digital Identity Cooperation Group, has published:

• The ARF specifies main functionalities, roles and responsibilities, architecture and design principles, attestation formats and protocols, trust model, certification, and risk management of the EUDI Wallet ecosystem.
• The Technical Specifications specify more technical details of selected topics derived from the ARF. The technical specifications describe various topics such as Relying Party registration, zero-knowledge proofs, attestation rulebooks, schemas and catalogues.

Furthermore, there are several standardisation organisations that contribute with standards for the EUDIW ecosystem.

• ETSI ESI: ETSI ESI is a European Standardisation Organisation (ESO) that creates technical standards and European Norms for electronic identity and signatures supporting the eIDAS regulation. ETSI ESI has published approximately 80 standards for QTSP conformity assessment, protocols and formats for digital signatures, as well as protocols and formats for the EUDI Wallet. ETSI ESI has received the standardisation request STF 705 from the EU Commission to create and/or update several standards for the EUDI Wallet ecosystem.
• CEN TC224: CEN Technical Committee 224 (TC224) is an ESO that has published several standards related to identification and devices with secure elements. More specifically, CEN TC224 WG17 are standardizing Common Criteria protection profiles of QSCD/WSCA, CEN TC224 WG18 develop standards related to biometric solutions, whilst CEN TC224 WG20 are creating standards related to EUDI Wallet onboarding and access control.
• ISO/IEC: ISO is an international standardisation organisation and the International Electrotechnical Commission (IEC) develops international standards for electronic technologies. The international standardisation activities related to digital identities are performed within ISO/IEC Joint Technical Committee (JTC) 1 “Information Security”. More specifically, several ISO/IEC standards are applicable to Common Criteria certification, conformity assessment and evaluation of the EUDI Wallet solutions. Furthermore, ISO/IEC has standardised the mobile driving license (ISO mDL) in ISO 18013-5, which is a PID format for the EUDI Wallet.
• IETF: The Internet Engineering Task Force (IETF) creates technical standards that comprise the internet protocol suites. More specifically, IETF PKIX covers secure data exchanges and formats in the area of electronic signatures, PKI and trust services. Most notably, IETF has published standards for PKIX X.509 certificate and CRL profiles, OCSP, TLS and SD-JWT, which are relevant for the EUDI Wallet ecosystem. Furthermore, some of the IETF standards are used as basis by ETSI ESI, which have created European profiles of Qualified Certificates, AdES signature formats, SD-JWT VC, etc.
• OpenID Foundation: The OpenID Foundation is an industrial standardisation organisation that develops open standards for identity, federation and security. The following OpenID standards are relevant for the EUDIW technical architecture: OpenID Connect Core (OIDC), OpenID For Verifiable Credential Issuance (OID4VCI), OpenID For Verifiable Presentations (OID4VP), and OpenID High Assurance Interoperability Profile (HAIP). OID4VP, OID4VCI and HAIP are used as the foundation for the ETSI TS 119 472 standardisation of EUDI Wallet protocols.
• W3C: The World Wide Web Consortium (W3C) is an international standardisation organisation. The following W3C standards are relevant to the EUDI Wallet technical architecture: W3C Verifiable Credentials Data Model, W3C Web Authentication (WebAuthn), and W3C Digital Credentials API. More specifically, the W3C Verifiable Credentials Data Model is referenced as basis for an ETSI TS 119 472 EAA profile.
• Cloud Signature Consortium (CSC): The Cloud Signature Consortium (CSC) is an international standardisation organisation focusing on compliant digital signature creation in the cloud. The CSC specification “CSC API v2 - Architectures and protocols for remote signature applications” is referenced by the EUDI Wallet architecture and is used as basis for the ETSI TS 119 432 standard.

In addition to the aforementioned standardisation organisations, the European Cybersecurity Agency (ENISA) is developing the EUDI Wallet Certification Scheme, which will be published as an implementing regulation under the Cybersecurity Act. The purpose of the EUDI Wallet Certification Scheme is to harmonise the national certifications of the EU Member States’ EUDI Wallets.

2.2 The EBW Framework

The EBW framework is introduced through the European Commission’s Digital Package proposal as part of its 2025 Work Programme. The proposal aims to establish the EBW as a harmonised digital solution that reduces administrative burden and allows companies and public authorities to identify, authenticate and exchange data with legal effect across the European Union.

The EBW framework complements the EUDI framework by addressing the needs of economic operators and public authorities. It supports the digital management of representation rights and mandates, provides a secure channel for exchanging official documents and attestations, and includes support for a common directory. Interoperability with the EUDI Wallet is a core requirement.

The proposal supports the management and use of EAA, including owner identification data with selective disclosure. It defines requirements for authenticating owners and authorised users through (Q)EAAs and enables links between EAAs and other attestations. Access to EAAs by relying parties requires proper authorisation.

The framework relies on existing eIDAS trust services such as qualified electronic signatures, seals, timestamps and registered delivery services.

The proposal also introduces a European Digital Directory maintained by the Commission. The directory functions as a trusted internal system where EBW providers notify relevant service information and where digital addressing can be supported. Detailed requirements will be defined in future implementing acts.

The regulation supports role-based access so that multiple authorised users can operate a wallet. It also enables secure data exchange between EBWs, EUDI Wallets and relying parties, while allowing additional functionalities provided that core features remain unaffected.

From a technical perspective, the framework promotes the use of common protocols for sharing attestations. It requires secure onboarding using eID with a LoA of at least Substantial and mandates interoperability, secure communication interfaces, and mechanisms for validation and revocation. Further requirements will be defined in implementing acts.

Within WE BUILD, the proposed EBW framework is treated as a primary regulatory and architectural reference for business-focused identity and data exchange scenarios. Use case design and pilot activities align with the EBW model’s legal structure, interoperability requirements and trust-service framework, while taking forthcoming implementing acts into account.

3 Architecture Overview

3.1 Architectural Principles

While the previous chapter describes the regulatory and architectural frameworks that WE BUILD aligns with, this chapter introduces the architectural principles guiding the design of the WE BUILD ecosystem.

• Interoperability: Wallet providers, issuers and verifiers interact across organisational and national boundaries.
• Reusability: The architecture builds on existing EU digital infrastructure and results from previous Large Scale Pilots.
• Security by design: Security controls are integrated into the architecture from the start.
• Privacy by design: Users retain control over personal and organisational data through selective disclosure and explicit consent.

3.2 The Ecosystem at a Glance

The EUDI Wallet and EBW ecosystem follows the common three-party attestation model. In this model, three primary actors interact: issuer, holder and verifier. A trust framework supports these actors by providing the trust anchors used for validation. 1. Holder – Natural person or economic operator receiving, storing and sharing credentials. 2. Issuer – an entity that issues attestations to the Holder. 3. Verifier – an economic operator or natural person that requests and verifies the authenticity and validity of a holder’s credential. 4. Trust framework – the infrastructure used to validate trust relationships between ecosystem participants (described in Chapter 6).

The diagram below shows the WE BUILD reference pattern for the ecosystem.

Figure 1: WE BUILD reference pattern for the EUDIW / EBW ecosystem.

In this reference pattern, Issuers use the issuance capabilities of the European Business Wallet (EBW) to issue attestations to the Holder; the Holder uses the EUDI Wallet (for natural persons) or the European Business Wallet (for economic operators) to present attestations to the Verifier; and Verifiers use the verification capabilities of the European Business Wallet to validate the attestations presented by the Holder. The foundation of the ecosystem is the Trust framework, where Issuers publish keys, identifiers and schemas, and Verifiers register as Relying Parties.

The EBW is an architectural construct (a defined role and set of capabilities), not a regulated entity, certification artefact, or deployment specification. The reference pattern is what the WE BUILD pilots are designed to evidence; it does not preclude conformant implementations that follow a different architectural choice. Regulatory paths follow the attestation tier: QEAAs are issued via the QEAASP path under eIDAS2 with the EBW operating outside that certified scope, while PuB-EAAs (including the EBWOID) are anchored in the relevant authentic source.

3.3 System Landscape

The diagram below illustrates the baseline trust topology of the EU wallet ecosystem. Issuers provide attestations to holders, holders present them to verifiers, and all actors validate trust relationships using the trusted lists. The trusted lists specify the recognised participants in schemes for electronic identification and trust services.

%% Baseline trust topology of the EU wallet ecosystem
flowchart TB
    issuer["Issuer  "]
    holder["Holder  "]
    verifier["Verifier  "]
    trust["WE BUILD Trusted Lists"]

    issuer -->|"issues attestations<br/>(PID, EAA, QEAA)"| holder
    holder -->|"presents attestations<br/>(selective disclosure)"| verifier
    issuer -.->|"published in"| trust
    holder -.->|"validates issuer &<br/>verifier against"| trust
    verifier -.->|"validates<br/>credentials against"| trust

    %% Styling
    classDef primaryRole fill:#fff2cc,stroke:#d6b656,stroke-width:2px,color:#000;
    classDef component fill:#e1d5e7,stroke:#9673a6,stroke-width:2px,color:#000;

    class issuer,holder,verifier primaryRole;
    class trust component;

WE BUILD focuses primarily on wallets for economic operators and public sector bodies. In these scenarios, qualified electronic registered delivery services (QERDS) support trusted messaging between recognised participants. Accordingly, interactions between data senders and receipients may be routed through a Qualified Trust Service Provider (QTSP) providing a QERDS. The QTSP is recognised in a scheme for trust services, just like in the previous diagram, enabling other participants to verify QERDS evidence issued by the QTSP. The WE BUILD Digital Directory (simulating the European Digital Directory) provides economic and public sector bodies with digital addressing for secure routing of documents and notifications.

QERDS is a payload-agnostic transport; within WE BUILD, its application focuses on document submissions and notifications.

While this model can apply to any data transmission, the application of QERDS in WE BUILD focuses on document submissions and notifications. The QERDS provides an additional interaction model in the WE BUILD ecosystem, complementary to the issuer-holder-verifier model above:

%% WE BUILD additional trust topology with the QERDS and the European Digital Directory
graph TB
    Directory["WE BUILD<br>Digital Directory"]
    TL["WE BUILD<br>Trusted Lists"]
    subgraph Users[Wallet users]
      direction LR
      SenderBW["Business<br>Wallet"]
      RecipientBW["Business<br>Wallet"]
      Sender-->|"uses"|SenderBW
      RecipientBW-->|"is used by"|Recipient
    end
    SenderBW-->|"submits documents using the QERDS to"|RecipientBW
    SenderBW-->|"uses the QERDS to notify"|RecipientBW
    Users-->|"discover wallet services and capabilities using"|Directory
    Users-->|"validate QERDS evidence against"|TL

    classDef group fill:#ffffff,stroke:#d6b656,stroke-width:2px,color:#000;
    classDef primaryRole fill:#fff2cc,stroke:#d6b656,stroke-width:2px,color:#000;
    classDef component fill:#e1d5e7,stroke:#9673a6,stroke-width:2px,color:#000;
    classDef governance fill:#f8cecc,stroke:#b85450,stroke-width:2px,color:#000;

    class Users group
    class Sender,Recipient primaryRole
    class SenderBW,RecipientBW component
    class Directory,TL governance

The ecosystem supports both interaction patterns for exchanging data: delivery with evidence, implemented by the QERDS, and holder-mediated presentation, following the issuer-holder-verifier model. The two compose: artefacts from either pattern can be carried or referenced over either channel where a use case requires it.

3.4 Wallet Types in WE BUILD

WE BUILD supports wallet solutions for both natural persons and economic operators.

Natural persons interact through EUDI Wallets, which enable individuals to authenticate and present personal identity attributes. Economic operators interact through EBW, which enable organisations to manage and present business-related attestations such as representation rights or organisational attributes.

From a deployment perspective, wallet solutions can be implemented in several ways depending on the target users, operational requirements, and cryptographic architecture. In practice, three main implementation approaches are relevant within the WE BUILD ecosystem.

Wallet type	Typical context	Characteristics
Mobile wallets (on-device)	Natural persons	Wallet application running on a user’s smartphone, with credentials stored and used locally on the device.
Server or Web-based wallets	Economic operators	Wallet services operated in backend infrastructure and accessed through Web interfaces or enterprise systems.
Hybrid wallets	Both contexts	Combine device-based interaction with backend cryptographic infrastructure.

The underlying cryptographic architecture of wallets is defined in the ARF and related standards. This Blueprint therefore focuses on the interactions and interoperability patterns relevant for WE BUILD rather than repeating the detailed wallet architecture definitions.

In practice, most deployments follow a mobile-first approach for natural persons and a server-based or enterprise-integrated approach for economic operators. Hybrid architectures may also be used to combine device-based user interaction with backend cryptographic services.

flowchart TB
    LE["Economic operator /<br>public sector body"] -.-> |controls| EBW
    NP["Natural person"] -.-> |represents| LE
    NP -.-> |controls| EUDI
    EUDI["EUDI Wallet&nbsp;&nbsp;"]-.-> |presents PID to| EBW
    EP["EBWOID provider"] -.-> |issues EBWOID to| EBW
    LE -.-> |"registered with<br>(in case of a company)"| BReg
    LE -.-> |registered with| EP
    BReg["Business registry"] -.-> |issues EU Company Certificate to| EBW

4 How the Wallet Interacts with Services

Chapter 3 introduced the main actors in the WE BUILD ecosystem. This chapter describes how these actors interact through wallet-based service flows.

4.1 Interaction Pattern: Attestation Issuance

The WBCS for high-assurance credential issuance defines the requirements used in the project to ensure interoperable issuance of verifiable digital credentials between wallets and issuers. For reference on qualified electronic attestation of attributes, see the QEAA documentation.

The WE BUILD ecosystem mainly supports two credential issuance models, which differ in which actor initiates the process: wallet-initiated issuance and issuer-initiated issuance. If the credential cannot be issued immediately, deferred issuance is used. The wallet retries periodically until the credential is issued or an unrecoverable error occurs.

4.1.1 Wallet-initiated Issuance

This issuance flow is initiated by the user:

1. The user opens their wallet and selects the credential type to be issued (for example, a PID or a QEAA).
2. The wallet connects with the corresponding issuer and requests the credential.
3. The user authenticates with the issuer, following the procedure specified by the issuer itself.
4. The issuer requests the user’s consent to issue the credential and send it to their wallet.
5. The issuer generates the credential and delivers it to the wallet.
6. The wallet verifies the authenticity of the credential and stores it. From this point, the user becomes responsible for managing the issued credential.

sequenceDiagram
participant User
participant Wallet
participant Issuer

User->>Wallet: Selects the credential type
Wallet-->>Issuer: Requests the credential
Issuer->>User: Requests authentication
User->>Issuer: Authentication
Issuer->>User: Requests consent
User->>Issuer: Gives consent
Issuer-->>Issuer: Generates the credential
Issuer-->>Wallet: Sends the credential
Wallet-->>Wallet: Validates the credential
Wallet-->>Wallet: Stores the credential 
User->>Wallet: Accesses the credential

4.1.2 Issuer-initiated Issuance

This issuance flow is initiated by the issuer:

1. The user interacts with the issuer (for example, during a digital onboarding process).
2. The issuer prepares one or more credentials.
3. The issuer offers these credentials to the user. This can be done in several ways, both same-device and cross-device:

• By displaying a QR code that the user shall scan with their wallet.
• By sending a link to the wallet.

4. The wallet displays the offer and requests confirmation from the user.
5. The user authenticates with the issuer, following the procedure specified by the issuer itself.
6. The issuer requests the user’s consent to issue the credential and send it to their wallet.
7. The issuer generates the credential and delivers it to the wallet.
8. The wallet verifies the authenticity of the credential and stores it. From this point, the user becomes responsible for managing the issued credential.

sequenceDiagram
participant User
participant Wallet
participant Issuer

User->>Issuer: Interacts digitally
Issuer-->>Issuer: Prepares the credential
Issuer->>User: Offers the credential displaying a QR code
User->>Wallet: Scans the QR code
Wallet->>User: Requests confirmation
User->>Wallet: Accepts the offer
Wallet-->>Issuer: Requests the credential
Issuer->>User: Requests authentication
User->>Issuer: Authenticates
Issuer->>User: Requests consent
User->>Issuer: Gives consent
Issuer-->>Issuer: Generates the credential
Issuer-->>Wallet: Sends the credential
Wallet-->>Wallet: Validates the credential
Wallet-->>Wallet: Stores the credential
User->>Wallet: Accesses the credential

4.2 Interaction Pattern: Attestation Presentation (Receiving)

In this pattern, a verifier requests specific attestations from the wallet. The wallet presents the requested information, typically using selective disclosure mechanisms, and the verifier validates the received data.

The WE BUILD Conformance Specification for Credential Presentation describes how wallets and relying parties interoperate within the WE BUILD ecosystem. It covers presentation (request and response flows), interfaces between wallets and relying parties as well as security, privacy and interoperability requirements and same‑device and cross‑device invocation patterns.

4.3 Signature and Seal Integration

Wallets in WE BUILD provide the ability to create qualified electronic signatures and seals. This section describes the various integration models. For reference, see the QES documentation.

WE BUILD supports both wallet-centric and QTSP-operated approaches for electronic signatures and seals. In both models, the wallet provides the user interaction layer, while cryptographic operations may take place either locally or in remote infrastructure operated by a QTSP.

Both approaches are compatible with the architectural patterns described in the ARF. However, during the WE BUILD pilot phase not every wallet provider or QTSP is expected to implement every possible model. For interoperability across the consortium, WE BUILD therefore treats remote signing and sealing through QTSP-managed services with standardised interfaces as the common baseline. Local signing models may still be supported by individual wallet implementations, but they are not assumed as a uniform baseline for interoperability within the project.

This section aligns with the WP4 interoperability baselines defined for issuance and presentation flows. Proximity-based signing scenarios are currently outside the baseline protocol scope of the WE BUILD pilots.

In the WE BUILD pilot and ITB environment, eIDAS-qualified status cannot be achieved because the ITB operates outside the formal eIDAS certification framework. Any reference to “qualified” in WE BUILD therefore represents a technical demonstration only and does not constitute a legally valid qualified electronic signature. The prerequisites for eIDAS-qualified status remain unchanged, including use of a Qualified Signature Creation Device (QSCD) and a qualified certificate issued by a QTSP that is listed on an official national Trusted List.

4.3.1 Wallet-centric Signing Model

In the wallet-centric model, the EUDI Wallet is the central component of the electronic signature process. Three distinct signing processes are considered, depending on where the Signature Creation Application (SCA) runs and where the Signature Creation Device (SCD) is hosted.

1) Remote Signing with External SCA

The user initiates signing from the wallet, while the SCA is external. The document is sent to the external SCA for review and consent, after which the signing request is forwarded to a remote SCD that creates the signature and returns the result.

Remote signing with external SCA

Remote Signing with Local SCA (Wallet as SCA)

The user initiates signing from the wallet, which also acts as the SCA. The document is presented to the user within the wallet for review and consent. After approval, the wallet forwards the signing request to a remote SCD that produces the signature and returns the result.

Remote signing with local SCA

3) Local Signing

The user initiates signing from the wallet, which also acts as the SCA. The document is presented to the user within the wallet for review and consent. After approval, the signature is created locally using a SCD integrated in the user’s device.

Local signing

4.3.2 QTSP-centric Signing and Sealing Model

In the QTSP-centric model, the trust service provider operates the signing or sealing process. The cryptographic key material used for signature or seal creation is generated, stored, and used within infrastructure controlled by or on behalf of the QTSP, typically in secure hardware environments. From the perspective of the user, signing and sealing are therefore remote operations. External components interact with the trust service through defined interfaces, while the cryptographic operation itself is performed within the QTSP-controlled environment.

Within this architecture, the EUDI Wallet may act as a client-side orchestration component. It can authenticate the user, capture user intent, and trigger a signing operation. However, it does not operate the signature creation environment, does not manage signing credentials, and does not assume the responsibilities of a trust service provider.

In this model, the QTSP remains responsible for identity binding, credential issuance, and compliance with applicable ETSI standards. Signature or seal creation data remains under controlled conditions consistent with the required assurance level, and activation mechanisms enforce the conditions required for advanced or qualified signatures, including sole control where applicable.

The pilot implementation aims to remain technically aligned with qualified signing requirements. Pilot trust validation is described below and relies on consortium trusted lists.

4.3.3 CSC Interoperability Profile for Remote Signing and Sealing

For remote signing and sealing flows, WE BUILD uses the Cloud Signature Consortium (CSC) interoperability framework. CSC APIs expose standardised interfaces that allow wallets and client applications to interact with QTSP-operated signing services. The detailed WE BUILD CSC interoperability profile will be defined in a WBCS. That specification will describe the concrete integration details, including authorisation mechanisms, endpoints, supported formats and algorithms, and interoperability constraints used in the ITB. Until such a profile is published, CSC API v2.2.0.0 serves as the base reference specification for CSC-based interactions.

During the pilot phase, trust validation relies on consortium reference trust mechanisms. Wallet components or external SCAs validate participating QTSPs and trust anchors using WE BUILD trusted lists. The reference trusted list may include participating QTSP entries and their registered issuing certificate authorities for pilot purposes.

When a signing request is processed, the SCA validates the signer’s certificate chain against issuing certificate authorities listed in the WE BUILD trusted list and checks the QTSP status within the pilot trust framework. Revocation status is validated using OCSP responders or CRL distribution points operated by participating QTSPs. Where registration status checks are required, registrar processes are simulated through mock registrar services and endpoints.

4.3.4 Organisational Signing: Individuals Signing on Behalf of a Company

WE BUILD supports signing scenarios where an individual signs on behalf of an organisation. This model reuses the wallet-centric and QTSP-operated signing approaches described above. The wallet provides the user interface for document review and approval, while the QTSP performs the signature or seal creation within its controlled environment.

In these scenarios, the transaction must bind both the natural person and the organisation represented. The natural person identity is represented by the PID, while the organisation context is represented through the EBWOID, which acts as the cross-border minimum organisation identifier.

At signing time, identifiers or references to both the PID and the EBWOID are included in the transaction data presented to the user and subsequently authorised or signed. This ensures that the resulting signature or seal can be unambiguously linked to both the individual and the organisation.

The exact representation of these bindings is use-case specific and will be defined in rulebooks and WBCS (see Chapter 5 for the semantic and schema model).

4.4 Secure Communication Channel

This section describes how secure message exchange is integrated into the WE BUILD wallet ecosystem.

In WE BUILD, the secure communication channel is implemented through Qualified Electronic Registered Delivery Services (QERDS) operated by QTSPs. Whenever legal-grade delivery assurance is required, messages are routed through QERDS. QERDS providers ensure mutual authentication, end-to-end integrity and confidentiality, and interoperability across access points. This “registered delivery” pattern is positioned as an enabler for interactions between and across public sector bodies and economic operators.

Because the QERDS and the EU Digital Directory designated for the production European Business Wallet are not yet available, WE BUILD designates the pre-production QERDS specified by WP4 for use in WE BUILD business wallets. For reference, see the QERDS documentation.

4.4.1 From “Registered Delivery” to “Digital Identity Wallets”

As a baseline, a classic B2G/B2B situation is used: an authority notifies an economic operator, the economic operator responds, and the relying party requires evidence. With QERDS, both sides use their QERDS providers to register sending and receiving, so that delivery is not just transport, but is a process that produces trustworthy evidence.

In this model, WE BUILD takes the next step: wallets become the user-facing endpoints (“wallet-centric delivery”). The sender wallet and recipient wallet remain the places where users read, approve, and manage messages, or where they configure connections to backend systems to perform these actions. QERDS providers form the delivery layer underneath, handling routing, inter-provider exchange, and evidence creation, while wallets provide identity/authentication and user control.

4.4.2 Technical Flow (WE BUILD High-Level)

WE BUILD follows the QERDS architecture decomposition and the four-corner delivery pattern:

1. Sender identification and authentication is performed at the sender’s QTSP (wallet-driven).
2. Message submission is performed from the sender’s wallet or connected backend system to the sender QERDS (QTSP A).
3. Discovery of the recipient’s QERDS endpoint and capabilities is performed via common services (e.g., the WE BUILD Digital Directory, simulating the EU Digital Directory from the EBW proposal).
4. Handshake and relay is performed between QTSP A and QTSP B (QERDS-to-QERDS interoperability).
5. Recipient notification is issued, followed by recipient authentication at QTSP B.
6. Consignment and handover of the message and its metadata is performed to the recipient’s wallet or connected backend system.
7. Evidence is made available to sender and recipient wallets (submission/dispatch and receipt/consignment or non-delivery). Evidence is protected by qualified sealing and, where required, qualified timestamping. Where applicable, the evidence can be pushed to the sender’s and the recipient’s backend systems as well.

4.5 Enterprise and System-to-System Wallet Interactions

Some WE BUILD scenarios involve interactions between backend systems rather than direct end-user actions. In these cases, wallet functionality may be integrated into enterprise platforms, APIs, or automated services.

This is particularly relevant for EBW scenarios such as supply chain credentials, Digital Product Passports, and automated B2B or B2G data exchange. In such cases, credential issuance and presentation may be initiated by backend systems while still following the interoperability patterns defined in this blueprint.

Although the interaction is system-driven, the same trust framework, credential formats, and verification mechanisms apply as in user-driven wallet interactions.

5 Information Inside the Wallet

While the previous chapter describes how wallets interact with services, this chapter describes the data and semantic structures used inside the wallet and in the exchanged attestations.

5.1 Semantic Model of the European Business Wallet

The semantic model is organised into three layers:

1. Terminology – defines terms and their abstract concepts and establishes relationships between them.
2. Vocabulary – defines classes, properties, and individuals linked to the terminology.
3. Attestation mapping – maps vocabulary terms to the elements used in attestations.

The terminology and vocabulary layers are independent of attestation formats, while the mapping layer depends on the format used.

Currently, only W3C VCDM 2.0 supports machine-readable semantic mappings directly within credentials. For mDoc and SD-JWT-VC, the meaning of data fields must instead be defined in attestation rulebooks. In these cases, semantic interoperability between attestations is not automatically enforced.

5.1.1 WE BUILD Terminology

The WE BUILD terminology is published online and serves as a reference model for the terminology of the European Digital Identity Framework. The terminology is defined using the Simple Knowledge Organisation System (SKOS).

5.1.2 European Business Wallet Vocabulary

The European Wallet vocabulary is maintained in GitHub. It is defined using the Web Ontology Language (OWL), which specifies classes, properties and individuals of the vocabulary.

To support semantic interoperability, credential subjects used within the EBW framework are modelled in the vocabulary. These vocabulary terms are then mapped to the corresponding elements used in attestations.

If the credential format supports machine-readable semantic contexts, the mapping between credential data and the vocabulary can be embedded in the credential itself. Otherwise, the meaning of the data fields must be defined in attestation rulebooks, and the rulebook owner is responsible for mapping those fields to the vocabulary definitions.

Reuse of existing vocabularies The EBW vocabulary defines the domain-specific vocabulary used in the WE BUILD attestations. Existing vocabularies are reused where possible, including those for credential metadata, proof mechanisms, security, decentralised identifiers, and credential status. Domain vocabularies from other sectors may also be reused (for example, digital product passports, supply chains, education, railway and data spaces).

5.2 Attestation Rulebooks and Credential Schemas

WE BUILD defines rulebooks and credential data schemas for the attestations used in the project’s use cases. Rulebooks describe requirements, roles, processes, and conformance criteria for specific attestations. They also define how credential data fields relate to the semantic vocabulary used in the project.

Credential schemas define the structure of credential data and support implementers in producing interoperable credentials and validating that the data follows the agreed format.

Rulebook descriptions are currently provided by the use cases using a common template and are maintained in the project collaboration portal. As part of the ongoing work to formalise rulebooks and credential schemas, these descriptions will be consolidated in a shared repository such as the WE BUILD Attestation Rulebooks repository, including rulebooks for key credentials such as PID and EBWOID.

6 Trust, Security and Governance

The previous chapter described the structure of the information stored in wallets and exchanged as attestations. This chapter describes the trust infrastructure that allows ecosystem participants to validate those attestations.

6.1 Trust Ecosystem

The trust infrastructure for the EUDI and EBW ecosystem is based on three complementary processes: registration/onboarding of participants, notification of certain entities to the European Commission, and publication of Trusted Lists (or Lists of Trusted Entities) that provide cryptographic trust anchors for validation.

6.2 Establishing Trust Between Participants

WE BUILD defines the onboarding processes (how entities get registered), the trust framework (which rules apply), the PKI architecture (which certificates are used and how), the APIs used to query trust information programmatically, and the trust evaluation logic used by participants at runtime.

The infrastructure is based on the Trusted List model defined in the eIDAS Regulation and the ARF. It follows the European model in which a List of Trusted Lists (LoTL) points to Trusted Lists. Each Trusted List contains entries for authorised participants such as PID Providers, Attestation Providers (QEAA, PuB-EAA, non-qualified EAA), Wallet Providers, and Relying Parties.

The onboarding processes define how participants join the ecosystem. This includes how: - Relying Parties register, accept policies and configure access controls - PID and Attestation Providers register, declare supported attestation types and obtain registration and access certificates - Wallet Providers register and issue wallet instance attestations - Trust Service Providers register and publish relevant certificates

Once onboarding is completed, participants use the trust infrastructure to evaluate each other during normal operation. WE BUILD therefore defines a set of trust evaluation scenarios covering how participants verify each other at runtime.

These scenarios include: - a Wallet Unit evaluating a Credential Issuer before requesting a PID or attestation - a Credential Issuer evaluating the Wallet Unit before issuing - a Wallet Unit evaluating a Relying Party before presenting attributes - a Relying Party evaluating presented credentials (PID, QEAA, PuB-EAA, non-qualified EAA) - discovery and consumption of the LoTL and TLs.

For detailed information on authorities, registries and responsibilities, see Appendix C - Trust Ecosystem.

For reference on relying party access certificates and relying party registration certificates, see the RPAC/RPRC documentation.

6.2.1 Trust infrastructure architecture (overview)

In the Appendix - Trust Ecosystem there is a diagram that summarises the roles of Member State and European Commission, the split between registration and notification, and how Trusted Lists and the LoTL are produced and consumed. A simplified version used in WE BUILD is shown below.

graph TB
    subgraph MS["weBuild Registry"]
        Registrar[Registration Service]
        TLProvider[Trusted List Provider]
        APTL[Attestation Provider TLs]
    end

    subgraph Entities["weBuild Participant"]
        AP[Attestation Provider]
        WP[Wallet Provider]
        RP[Relying Party]
    end

    subgraph TL["weBuild Trusted List Provider"]
        LoTLPublication[List of Trusted Lists]
    end

    AP -->|Register| Registrar
    WP -->|Register| Registrar
    RP -->|Register| Registrar

    LoTLPublication -->|references|TLProvider
    LoTLPublication -->|references|APTL

    style MS fill:#e1f5ff
    style TL fill:#fff4e1
    style Entities fill:#e8f5e9

WE BUILD participants select the registry in which they register.

6.3 Revocation

Revocation ensures that attestations that are no longer valid can no longer be trusted or used.

WE BUILD distinguishes between attestation revocation, which is handled by issuers, and revocation or withdrawal of providers and services, which is reflected in the trust infrastructure.

6.3.1 Technical realisation

Revocation of PID, EBWOID and attestations is implemented by issuers. In WE BUILD, attestation revocation follows the agreed mechanism defined in the ADR on Attestation Revocation, based on the IETF Token Status List and aligned with OpenID4VC HAIP.

Short-lived attestations (valid for 24 hours or less) are not subject to revocation.

Revocation or withdrawal of providers and services is reflected in the trust infrastructure through status changes in Trusted Lists and, where applicable, invalidation of certificates.

6.3.2 Provider Obligations

To maintain a trusted ecosystem, PID and EBWOID providers agree to: * Define and publish revocation policies. * Ensure that only the issuing authority can revoke its attestations. * Publish revocation status information within a reasonable time frame.

6.3.3 Conditions for Mandatory Revocation

According to the rules, a provider must revoke without delay if: * The holder explicitly requests it. * The security of the wallet app itself (the unit certificate) is compromised. * Any of the specific situations defined in the provider’s public policy occur.

7 Architecture Governance: ADRs and WBCS

While the previous chapter described the operational trust infrastructure, this chapter describes the governance model used to define and maintain the technical architecture of the WE BUILD ecosystem. In a project as large as WE BUILD, interoperability between independently developed components must be ensured without requiring every developer to participate in all coordination meetings.

To maintain alignment, the project uses a technical governance model based on consensus, commitment and clear documentation. Technical choices are driven by the needs of the 13 use cases implemented in the project.

7.1 Architectural Decision Records (ADR)

The ADRs is essentially our project’s “logbook” for major decisions. - Purpose: The ADR process is where we formally capture and justify significant technical choices, such as which specific protocols and formats to use. Instead of having these decisions buried in a slide deck or a long email chain, we document the rationale and context so that everyone can understand the “Why” behind a choice. - Classification: We maintain a lightweight ADR for any software-related decision that affects how different systems work together (interoperability). This ensures alignment with external rules like the eIDAS Regulation and the ARF. - Lifecycle: ADRs are managed on GitHub (webuild-consortium/wp4-architecture). They move from a “Proposed” state to “Accepted” once the Architecture Group and relevant stakeholders reach consensus.

stateDiagram-v2
    state "New ADR candidate" as pr
    state "PR ready to merge" as ready
    state "Consortium decision" as merged
    state "Proposal rejected" as rejected

    [*] --> pr: Any consortium participant proposes
    pr --> ready: Review

    ready --> merged: Merge the PR
    merged --> [*]

    ready --> rejected: Closes the PR
    rejected --> [*]

7.2 WE BUILD Conformance Specifications (WBCS)

If ADRs capture the rationale (“why”), the WBCS define the implementation requirements (“how”). - Operationalising Intent: We use the WBCS to turn high-level architectural goals into detailed technical rules. These specifications define the exact interfaces for wallets, issuers, and verifiers. - A Commitment to Implement: This is the most important part: An approved WBCS is not just a suggestion. When a specification is approved, it signifies a commitment from the participating organizations to actually build that interface into their services. - Defining Implementation Requirements: Because the WBCS define how interfaces and protocols must be implemented, they allow us to achieve interoperability across the whole consortium. If you follow the WBCS, you avoid building an “interoperable island” where your service only works with a few specific partners. - The Link to Testing: Our Interoperability Testbed (ITB) uses these specifications as its primary rulebook. Implementations that do not follow the WBCS will not pass the ITB tests and are therefore not eligible for pilot participation.

---
config:
  flowchart:
    defaultRenderer: 'elk'
    subGraphTitleMargin:
      bottom: 25
---

graph TB
%% flowchart

    subgraph "WP4 (Architecture)"
        Proposal -- Discuss --> Review
        Review -- Rejected --> Proposal
        Review -- Approved --> CS
    end

    subgraph "Participants from WP2, WP3 and WP4"
        Implementations["Implementations
        (wallets, issuers, verifiers)"]
    end

    subgraph "Testing Group"
        ITB["ITB"]
    end

    CS -- "Guiding" --> Implementations
    CS -- "Configure" --> ITB
    Implementations -- "Test" --> ITB

    Anyone -- "Create/adapt" --> Proposal
    SpecEfforts["Specification efforts"] -- "New wallet interface definitions" --> CS
    TestDev["Test development"] -- "New version test cases" --> ITB

7.3 Document Lifecycle

WE BUILD moves fast, and our documentation needs to keep up. We don’t wait for “perfect” documents; we iterate as the use cases mature. - The Blueprint as a Living Framework: This Blueprint (D4.1) sets the high-level structure, but it is supported by the more agile ADRs and WBCS that live on GitHub. As we learn, we update these records and specifications. - The Hybrid Working Flow: To keep things moving, we use a “hybrid” approach to our document lifecycle: - GitHub: This is our source of truth for all accepted specifications and decision records. - Slack: The ITB uses a dedicated channel for implementation support, where developers can ask questions and help each other in real-time. - Meetings: We hold interface-alignment meetings to discuss progress, resolve gaps, and gain final agreement on new specifications. - Maturing Together: As the project moves forward, we will add more detailed definitions to the documentation stack. This approach allows the Blueprint to evolve from a high-level architectural reference into a practical guide for implementing the WE BUILD ecosystem.

8 Testing and the Interoperability Testbed (ITB)

Once architectural decisions and specifications are defined, interoperability must be verified in practice. This chapter describes how interoperability is verified through the WE BUILD testing strategy and the Interoperability Testbed (ITB).

8.1 Testing Strategy

The Architecture Group coordinates the architectural building blocks and ensures alignment with the project use cases.

The Testing Group develops test cases and test suites for: - Generic test cases based on WBCS. - Functional test cases for required features (based on WBCS and, when needed, rulebooks and/or data schemas). - End-to-end and piloting test cases for WP2/WP3 use cases (based on existing WBCS, rulebooks and data schemas).

To implement tests in the ITB, the Testing Group needs the specification artefacts: WBCS, rulebooks, data schemas, namespaces, and related metadata. The Architecture Group ensures that these artefacts are complete and consistent with the overall architecture and supports WP4 groups and WP2/WP3 use cases in providing the required input.

Most specification artefacts are produced within WP4: - The Semantics Group: attestations (data schemas, namespaces, and relevant rulebook parts). - The Wallet, PID/EBWOID and QTSP Group: WBCS and commitment to implement them. - The Architecture Group: Architecture Decision Records (ADRs) that define the allowed scope for WBCS. - The Trust Infrastructure Group: validation and verification requirements to be reflected in test cases.

For piloting-specific test suites, the Testing Group collaborates directly with the relevant use case(s). The Architecture Group acts as a facilitator to ensure consistency across the involved specifications.

8.2 Test Requirements

Test cases are derived from the WBCS.

WBCS must stay within the scope defined by the published ADRs. If a WBCS needs functionality beyond that scope, it requires an ADR discussion. Testing focuses on features implemented by multiple parties, since interoperability requires multi-party implementations.

Implementing participants discuss WBCS together with the use cases that require the functionality.

The ITB initially includes two credential-agnostic test suites: - Issuing (based on OpenID4VCI v1.0) - Verifying (based on OpenID4VP v1.0)

If a use case requires different functionality, it can propose a new or adapted (draft) WBCS. Once the WBCS and required supporting artefacts are available, the Testing Group implements the corresponding test cases in the ITB.

Some test cases require additional artefacts beyond the WBCS, such as rulebooks for attestation-specific requirements, and the corresponding data schemas, namespaces, and metadata.

When the required artefacts are available, the Testing Group implements the test cases in the ITB and communicates their availability to the consortium.

8.3 Additional Documentation

The ITB on GitHub

A user guide on how to onboard and execute tests.

Documentation on the ITB and integrations

9 What’s Next & Scaling Up

This document, together with the initial attestation data models and schemas, establishes a common technical baseline for the wallet ecosystem. The architecture will continue to evolve throughout the project as the focus shifts towards implementation and testing.

WP4 - General Capabilities operates on a defined timeline with key milestones and deliverables while adapting to feedback from the use cases as well as business, regulatory and technological developments. The deliverable is expected to evolve through updates and refinements as new ADRs and WBCS are added or revised. The document therefore serves as a living reference for the WE BUILD architecture.

The roadmap for months 8–19 focuses on maturing the trust infrastructure and validating cross-border interoperability through the project’s automated testbed.

Key Milestones and Deliverables (Months 8–19)

Month	Type	Reference and Title	Connection to D4.1
10	Deliverable	D4.3 Attestation Data Models & PID/EBWOID Rulebook	Finalizes the data structures for the issuance patterns defined in D4.1
11	Milestone	MS5 WP2 Pilot Design Complete (Business)	Finalizes the scope of business use journeys based on D4.1 architectural patterns
11	Milestone	MS10 WP3 Pilot Design Complete (Payments)	Finalizes the scope of payments and banking use journeys based on D4.1 architectural patterns
12	Deliverable	D2.1 WP2 Pilot Design Report & PID/EBWOID issuance rulebook	Maps user journeys to the D4.1 reference implementations
12	Deliverable	D3.1 WP3 Pilot Design Report	Maps payment journeys to the D4.1 reference implementations
13	Deliverable	D4.4 Trust Infrastructure Guidelines	Details the technical signature/seal flows introduced in D4.1
17	Milestone	MS6 WP2 Pilot Implementation Complete	Validates local business infrastructure against D4.1 specifications
17	Milestone	MS11 WP3 Pilot Implementation Complete	Validates local payment infrastructure against D4.1 specifications
19	Milestone	MS7 WP2 Cross-Border Readiness	Proves interoperability of WP2 and WP4 business ecosystem
19	Milestone	MS12 WP3 Cross-Border Readiness	Proves interoperability of WP3 and WP4 payments and banking ecosystem
19	Milestone	MS17 Wallets & Trust Infrastructure Ready	Final evidence of wallet/trust interoperability as per D4.1

Alongside these milestones and deliverables, WP4 will continue to iterate on the architecture, specifications and supporting artefacts throughout the project. All WP4 groups will incorporate feedback from the piloting phase and adapt to new requirements and emerging EUDI standards and other technological developments. The ITB will remain a vital tool for continuous integration and testing, ensuring that the solutions remain interoperable, secure, and scalable.

Appendix A. Glossary

Terms and Definitions

This appendix defines the key terms, regulatory frameworks, and technical specifications utilised throughout the WE BUILD ecosystem.

While this document avoids abbreviations as much as possible, commonly used abbreviations are included for reference.

Term	Abbreviation	Definition
Architectural Decision Record	ADR	A document used to capture and justify significant technical choices. ADRs serve as the project’s “logbook” to ensure transparency regarding the rationale behind protocol and standard adoption.
Architecture and Reference Framework	ARF	The reference architecture for the European Digital Identity Wallet ecosystem published by the European Commission in cooperation with the Member States. It defines roles, trust models, protocols and interoperability requirements for the ecosystem.
Attestation Rulebook	-	A document describing the governance, requirements and semantic interpretation of a specific attestation type, including how credential data maps to vocabulary terms and schemas.
Blueprint	—	The high-level architecture and integration document (D4.1) describing the WE BUILD ecosystem, architectural patterns, interaction flows and governance model.
Business Wallet Unit Attestation	BWUA	A specific type of Wallet Unit Attestation issued for a European Business Wallet (EBW) instance.
EAA Provider	—	An entity that relies on authentic sources of information to issue attestations to a wallet.
EBW Instance	—	A unique deployment or installation of a European Business Wallet (EBW) solution, controlled by an Owner (legal person or economic operator).
EBW Provider	—	A Wallet Provider specifically authorized to issue and manage European Business Wallets (EBW).
EBWOID Provider	—	An entity responsible for verifying the identity of a legal person or economic operator and issuing EBW Owner Identification Data (EBWOID).
EBW Owner Identification Data	EBWOID	A set of attributes used to uniquely identify a legal person or economic operator within the European Business Wallet ecosystem.
Economic operator	—	Any natural or legal person or public entity which offers products or services on the market; the primary user of the European Business Wallet.
Electronic Attestation of Attributes	EAA / QEAA / PuB-EAA	Digital credentials that prove specific attributes (e.g., professional qualifications, representation rights) with either qualified (QEAA) or public sector body-issued (PuB-EAA) or non-qualified (EAA) legal status.
Electronic Identification, Authentication and Trust Services	eIDAS / eIDAS 2.0	The legal framework for electronic identification and trust services for electronic transactions in the European Single Market.
European Business Wallet	EBW	A wallet designed for economic operators or public sector bodies to manage business data such as mandates, electronic invoices, and administrative and professional documents and notifications.
European Digital Identity Wallet	EUDI Wallet	A mobile or cloud-based solution for natural persons to manage and share identity data.
EUDIW Instance	—	A specific deployment of an EUDI Wallet solution for a natural person.
Holder	—	See Wallet User instead.
Interoperability	-	The ability of independently developed systems and components to exchange information and correctly interpret the exchanged data.
Interoperability Testbed	ITB	The automated testing environment used in WE BUILD to verify that implementations conform to the agreed specifications and remain interoperable.
Issuer	—	See EAA Provider instead.
Large Scale Pilot	LSP	A project funded by the European Commission to test the practical implementation of the EUDI Wallet framework across various cross-border use cases.
Legal Person	—	An entity (such as a corporation or public body) recognized by law as having rights and duties, distinguished from a natural person.
Legal Person Identification Data	LPID	See EBW Owner Identification Data instead.
Level of Assurance	LoA	A classification of the degree of confidence in the electronic identification of a natural person, a legal person, or a natural person representing a legal person. Recognised levels are: Low, Substantial, High.
List of Trusted Lists	LoTL	A list that references national or ecosystem Trusted Lists, allowing participants to discover and validate trusted entities.
Natural Person	—	An individual human being acting in their own capacity.
Owner	—	The legal person or economic operator that has legal control over and responsibility for an EBW Instance.
Personal Identification Data	PID	A mandatory set of attributes issued to a natural person to uniquely identify them at Level of Assurance (LoA) High.
PID Provider	—	An entity responsible for verifying the identity of a natural person and issuing Personal Identification Data (PID).
Qualified Electronic Registered Delivery Service	QERDS	A secure communication channel that provides legal evidence of the handling of transmitted data.
Qualified Trust Service Provider	QTSP	A regulated entity providing electronic trust services (e.g., signatures, seals, or delivery services) with full legal effect under eIDAS.
Relying Party	RP	An entity that requests and receives attestations from a wallet to verify specific attributes or identities.
Selective Disclosure JSON Web Token	SD-JWT	A format allowing holders to share only specific parts of a credential while keeping other data private.
Trust Framework	—	The set of governance rules, standards, and trust infrastructure used to establish and verify trust relationships between ecosystem participants.
Trusted List	TL	A machine-readable list of trusted service providers or entities used to validate trust relationships within the ecosystem.
Verifier	—	See Relying Party instead.
Wallet Application	—	The user-facing software component of a Wallet Solution providing the interface for managing credentials.
Wallet Core Component(s)	—	The technical module(s) of a Wallet Solution handling cryptographic operations and protocol implementations.
Wallet Instance	—	A specific operational instance of a wallet solution running on a device or cloud environment.
Wallet Instance Attestation	WIA	A short-lived, signed information object issued by a Wallet Provider that contains information about the Wallet Instance. It is device-bound and presented to PID or Attestation Providers to authenticate the instance, but it does not require a WSCD/WSCA for key management and does not contain revocation information.
Wallet Provider	—	An organization that provides a Wallet Solution and manages its lifecycle.
Wallet Secure Cryptographic Device / Application	WSCD / WSCA	The hardware or software environment used to manage cryptographic keys securely within the wallet.
Wallet Solution	—	A specific implementation of a wallet consisting of a Wallet Application and Wallet Core Component(s).
Wallet Unit Attestation	WUA	A signed information object issued by a Wallet Provider that describes the capabilities and security properties of a Wallet Unit (especially the WSCD/WSCA). It is device-bound and allows PID or Attestation Providers to verify compliance, bind credentials to the unit, and check for revocation.
Wallet User	—	The natural or legal person that controls and operates a wallet instance.
WE BUILD	—	The consortium and project focused on pioneering the European Business Wallet and EUDI Wallet use cases.
WE BUILD Conformance Specifications	WBCS	Detailed technical rules that operationalize architectural intent. Approval of a WBCS signifies a commitment from partners to implement those interfaces.

Appendix B. Document History

Changes

Version	Date	Author	Description
1.0	2026-03-20	Authors Sarah Amandusson, Digg, SE Sander Dijkhuis, Cleverbase, NL George Fourtounis, GRNET, GR Benjamin Hansson, iGrant.io, SE Leif Johansson, SIROS Foundation, SE Svilena Rakshieva, Evrotrust Technologies, BG Sebastian Elfors, IDNow, FR George J Padayatti, iGrant.io, SE Giuseppe De Marco, Dipartimento per la trasformazione digitale, IT Ronald Koenig, Spherity, DE Contributing parties Steffen Piel, Governikus, DE Malin Norlander, Bolagsverket, SE Lal Chandran, iGrant.io, SE Aleksandar Simsic, ICTU, NL Esther Maakay, Signicat, NL Hristian Daskalov, Evrotrust Technologies, BG Thodoris Papadopoulos, GRNET, GR Eelco Klaver, Credenco, NL Viky Manaila, Intesi Group, IT Andreas Abraham, Validated ID, ES Alejandro Nieto, Digitel TS, ES Stefan Hadjistoytchev, Evrotrust Technologies, BG Andrew Freund, D-Trust, DE Miguel Aguilar, Bolagsverket, SE Dr. Oliver Froitzheim, Bundesanzeiger Verlag GmbH, DE Sarah Gräfer, Bundesanzeiger Verlag GmbH, DE Reviewers Andriana Prentza, University of Piraeus, GR Ard van der Heijden, ICTU, NL Marie Austenaa, Data Craft, NO Stef Haartman, NL Xavier Juredieu, FR	First complete version with full content
0.1	2025-12-08	Sarah Amandusson	Initial structure