# 3. GovStack Building Blocks in the EIDAS 2.0 Profile ## 3.1 Roles of the Building Blocks The EUDI Wallet ARF maps well to several GovStack Building Blocks, but the mapping is not one-to-one. Some GovStack components are directly relevant to the wallet, some are wallet-facing ecosystem dependencies, and some remain outside the ARF and must be implemented elsewhere in the digital public infrastructure. | GovStack Building Block or concern | EUDI Wallet ARF alignment | Treatment in this guide | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity / Identity Verification | Strong wallet-facing alignment. The ARF defines PID, user identification and authentication, credential presentation, and protocols such as OpenID4VP and OpenID4VCI. | Covered as a core wallet dependency. The Identity BB acts as the backend identity, enrolment, and PID source; the wallet acts as the holder-side storage and presentation environment. | | Wallet BB | Strong but incomplete alignment. GovStack defines a generic wallet; the EUDI profile adds regulated wallet roles, credential formats, trust evidence, WSCD/WSCA, WUA/WIA, certification, and lifecycle controls. | Main focus of this guide. The GovStack Wallet BB is configured as an EUDI Wallet Unit. | | Consent BB | Partial conceptual alignment. The ARF requires clear user approval before disclosure, transparency about requested attributes, and the ability to reject or limit sharing. | Covered as user approval, transparency, transaction history, and data-rights support. It should not be described as GDPR consent in every wallet transaction. | | Digital Registries | Strong alignment through Trusted Lists, LoTEs, registrar services, RP registration, access certificates, registration certificates, and status or revocation information. | Covered as wallet-facing trust infrastructure. The wallet uses this information to decide whether issuers and relying parties are trusted and authorised. | | Information Mediator / Data Exchange | Functional alignment. The ARF does not require a central exchange bus, but it standardises wallet-facing exchange protocols such as OpenID4VCI, OpenID4VP, and ISO 18013-5/-7. | Covered as wallet-specific data exchange. Broader service-to-service mediation remains outside the wallet core. | | Workflow / Process Management | Strong alignment through lifecycle models for Wallet Solution, Wallet Unit, issuers, relying parties, issuance, presentation, revocation, recovery, and certification. | Covered in the implementation workflow and operations sections. | | Digital Signatures / PKI / Trust Services | Strong alignment where the wallet initiates QES or QSeal flows and integrates with QTSPs, QSCDs, remote QSCD services, and trust evidence. | Covered as a wallet-facing signing dependency, not as a full trust-service implementation guide. | | Cross-cutting Security | Strong alignment. The ARF adds privacy and security by design, device and user binding, WSCD/WSCA, revocation checks, disclosure policies, Access CA, and trusted-list-based trust. | Covered in security, unobservability, trust, and certification sections. | | Registration BB | Partial alignment. RP registration, intended use, certificates, and authorisation data resemble registration functions, but they are specific to wallet ecosystem actors. | Covered as RP and trust registration. Domain-specific permits or licensing registries remain outside this guide. | | Messaging / Notification | Partial alignment. EUDI rules require some ecosystem notifications, but the ARF does not define a full GovStack Messaging BB API. | Treated as an operational dependency. A national implementation needs a separate notification service for email, SMS, push, webhook, or in-app messages. | | Payments | Partial alignment. The wallet may support strong user authentication for payment-related use cases, but the ARF does not provide payment APIs, clearing, settlement, refunds, or reconciliation. | Out of wallet-core scope. Payment processing belongs to a separate Payments BB or sector payment infrastructure. | | Scheduler | Not directly covered. Periodic checks, revocation refresh, certificate expiry monitoring, key rotation checks, and SLA tasks are not wallet functions. | Out of ARF scope. These functions should be handled by platform orchestration or scheduler services. | | Service Catalog | Not directly covered. ARF registrars and trusted lists identify trusted actors, not the full catalogue of government APIs and services. | Out of wallet-core scope. Service catalogues remain a GovStack platform concern. | ### ### **3.1.1 Digital Wallet Building Block** GovStack’s wallet becomes the EUDIW application, a mobile client that combines application logic with hardware‑backed key protection. It provides user‑centric control by storing Person Identification Data (PID) as well as Qualified Electronic Attestations of Attributes (QEAAs) (including Electronic Attestation of Attributes and Electronic Attestation of Attributes issued by or on behalf of a public sector body responsible for an authentic source), ensuring that only the user can authorise any presentation or signing operation (“sole control”). The wallet operates within a secure cryptographic environment where keys reside in a Wallet Secure Cryptographic Device (WSCD), such as a Secure Element or a Trusted Execution Environment (TEE), pure software keystores are not acceptable for achieving a High Level of Assurance (LoA). To support interoperability across Member States, the wallet implements the EU profile of OpenID4VP for credential presentation and validates issuers and trust services against the EU List of Trusted Lists (LOTL). ### **3.1.2 Identity Building Block** In a standard GovStack setup, this block handles identities and authentication. In the EU profile it acts as the Person Identification Data (PID) Provider, connecting authentic sources such as the Civil Registry and Population Register with the wallet. Its responsibilities include identity verification, where onboarding flows must rely on notified eID means such as national eID cards or Mobile ID, and the Level of Assurance must reach High in line with Commission Implementing Regulation (EU) 2015/1502. It is also responsible for PID issuance, providing PID as a credential (OpenID4VCI protocol, as profiled by the 'OpenID for Verifiable Credential Issuance' profile specified in HAIP) that contains the mandated attributes—family name, given name, date of birth—and any other legally required elements, and exposing an OIDC4VCI (OpenID for Verifiable Credential Issuance) endpoint aligned with the EUDIW ARF profile. In addition, it manages the lifecycle of PID, including revocation, and renewal whenever registry data changes, such as in cases of name changes, death, or loss of legal capacity. The Identity Building Block should not be confused with the wallet itself. In the EU profile, the Identity BB remains the backend identity, enrolment, authentication, and registry-integration component. It sources or verifies PID and attributes, connects to authentic sources, and supports identity proofing and lifecycle management. The EUDI Wallet is the client-side holder environment that receives PID and attestations, stores them under user control, and presents them to relying parties. The two are complementary: Identity BB provides the trusted identity source, while the Wallet BB provides the user-facing storage, approval, presentation, and cryptographic binding environment. ### **3.1.3 Consent Building Block** The Consent Building Block is responsible for ensuring transaction transparency by recording every credential presentation and issuance event in a way that is visible to the user, including which relying party was involved, which attributes were shared, and when the event occurred. Although this building block remains important, the current implementation of eIDAS 2 does not fully align with the Concent building block, primarily because unobservability sits at its core. A common interpretation holds that attestations stored in a wallet fall solely under the user’s control and therefore lack a designated data controller. Since consent, in regulatory terms, must be recorded and managed by a data controller, this creates a structural limitation: if no such controller exists for wallet-held attestations, then consent cannot be meaningfully established or recorded within the wallet environment. ### **3.1.4 Electronic Signature Building Block** In GovStack, this block is responsible for signing documents, in the EU profile, it functions as a Qualified Signature Creation Application linked to a Qualified Trust Service Provider (QTSP) and a Qualified Signature Creation Device (QSCD). It must be able to produce Qualified Electronic Signatures (QES) with full legal equivalence to handwritten signatures anywhere in the EU, integrate with remote QSCDs such as HSM‑based services operated by a QTSP, and use the wallet with explicit user authorisation for each signature. The block also has to support standard signature formats including PAdES, XAdES, and other profiles required for long‑term validation and archival. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://specs.govstack.global/impl-eidas-wallet/3.-govstack-building-blocks-in-the-eidas-2.0-profile.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.