7. Cross‑Functional Controls for the Wallet

7.1 Security and WSCD Integration

Security for the wallet starts with the WSCD. Keys used to sign presentations, authorise QES, or decrypt stored data reside in hardware‑protected environments. On Android, this may be StrongBox or a secure element, on iOS, the Secure Enclave or remote HSM. The wallet must integrate with these environments using the platform’s cryptographic APIs.

Authentication flows in the wallet are built on this. Access to keys is bound to a device unlock factor, usually reinforced by biometrics such as fingerprint or face recognition. Critical actions—sharing PID, authorising a QES—require a fresh biometric confirmation rather than relying on an old session. Private keys are generated and used inside the WSCD, they never appear in application memory in raw form and are never sent to servers.

7.2 Unobservability and Data Minimisation

Unobservability is a defining feature of the EUDIW concept. The wallet provider should not be able to reconstruct where and when an individual uses their wallet. This has architectural consequences: flows should prefer direct wallet‑to‑relying‑party communication, or use relays that see as little information as possible. Generic analytics SDKs that send timestamps, identifiers, or page‑view events to central servers are incompatible with this requirement and must be removed.

At the same time, the system must still provide meaningful transaction history to the user. The solution is to keep detailed history on the device and to send only filtered metadata to the Consent Building Block. That metadata excludes details that would allow the wallet provider to link individuals to specific services or transactions beyond what is strictly needed for legal obligations and incident handling.

7.3 Logging and Monitoring

Wallet logging has to tread carefully. Local logs on the device support troubleshooting and user‑visible history. Server‑side logs focus on application distribution, update success, error rates, and security‑related events such as repeated failed onboarding attempts.

Monitoring systems track trends and anomalies that could signal security incidents or widespread bugs. At the same time, privacy constraints limit what identifiers can be used in monitoring data.

7.4 High Availability, Disaster Recovery, and Sustainability

Although the wallet app runs on user devices, it relies on services for configuration, trust lists, and status information. Those services require high availability and disaster‑recovery planning. Outages of LOTL or configuration servers should degrade functionality gracefully, for example by allowing limited offline use for a period with clear warnings, not by silently failing. Sustainability sits alongside these concerns. A single, shared wallet client that can serve many services is more efficient than multiple sector‑specific apps. Limiting background network use, avoiding heavy polling, and reusing components across national projects all contribute to lower resource consumption.

7.5 What EUDI has that GovStack Wallet BB doesn’t

This section summarises the main gaps between the EUDI Wallet requirements and the GovStack Wallet Building Block specification. It focuses only on requirements that are explicitly mandated for an EUDI‑compliant wallet but are missing or only implicitly covered in GovStack.

The analysis is structured along the three axes mirroring the Wallet BB specs:

• Key functionalities that EUDI expects the wallet to support,

• Cross‑cutting requirements such as legal, organisational, security and privacy obligations, and

• Functional and UX behaviours around user control, dashboards and operational flows.

Taken together, these “missing pieces” indicate what would need to be added on top of a GovStack‑style wallet implementation to reach EUDI‑level compliance.

7.5.1. Key functionality gaps

7.51.1 Wallet‑to‑wallet / person‑to‑person flows

EUDI requires that the wallet:

• “MUST be able to authenticate another person's European digital identity wallet by validating the authenticity and validity of that wallet set's certificate.”

• “MUST allow the user to send and receive personal identification data and electronic certificates from another European digital identity wallet.”

GovStack’s wallet spec only models issuer → wallet → verifier. There is no functionality for wallet‑to‑wallet authentication or data exchange in the Key Digital Functionalities or Functional Requirements. Peer‑to‑peer wallet flows are missing in GovStack.

7.5.1.2 Wallet‑set certificates and wallet attestation

EUDI adds a whole layer around “wallet set” evidence. For example, it requires that:

• The wallet provider “MUST issue at least one signed wallet unit attestation to each digital wallet.”

• The provider “MUST associate each issued wallet set certificate with an identification of the digital wallet where the certificate was issued.”

• The provider “MUST be able to invalidate the evidence of the wallet set, being the only party who can do so.”

• The provider “MUST share information regarding the validity of the wallet set evidence in a manner that preserves privacy.”

• The provider “MUST establish publicly available policies with terms and deadlines for invalidating wallet set evidence.”

• The provider “MUST notify the affected digital wallet user in a user‑friendly manner within 24 hours of the revocation of a wallet set certificate.”

GovStack has the general notion that issuers, wallets and verifiers must trust each other (its “trust infrastructure”), but it does not define a concrete “wallet‑set certificate” object, its lifecycle, or this notification behaviour.

7.5.1.3 Qualified signatures and seals

EUDI says the wallet:

• “MUST allow signing with a qualified electronic signature or verification with a qualified electronic seal.”

• “MUST be able to interface with at least one of the following: a signing tool integrated into the application (local), a signing tool external to the application, or a remotely managed signing function.”

GovStack talks about secure storage of keys and trusted hardware/TEE for cryptographic operations. There is however no division to trust services and qualified trust services. The concept of “qualified” is a legal term coming directly from eIDAS to describe levels of security associated with a trust service. The difference between a standard Trust Service and a Qualified Trust Service it is also about liability, supervision, and legal status.

• Trust Service (Functional): Any electronic service that creates, verifies, or validates signatures. Technically, this just requires software that can perform cryptographic operations.

• Qualified Trust Service (Legal): A service that has been audited by a supervisory body, granted a specific status by a government, and placed on a "Trusted List." It shifts the burden of proof in court and carries specific liability insurance requirements.

7.5.1.4 High‑assurance eID scheme context

EUDI also states that the wallet:

• “MUST be issued as part of an e‑identification system with a high level of assurance and must meet its requirements.”

GovStack requires the issuer to authenticate the holder and that participants rely on some trust framework, but it does not define levels of assurance or require that the wallet can also act as an eID means that is capable of doing user identification/authentication at level high.

7.5.2 Cross‑cutting gaps

7.5.2.1 Open‑source, business model and accessibility

EUDI imposes very concrete constraints:

• The wallet “MUST be open source.”

• It “MUST be free of charge for natural person end‑users,” and qualified signatures must be free of charge for non‑professional use.

• It “MUST meet the accessibility requirements of European Union Directive 2019/882.”

GovStack’s wallet spec does not say anything about open‑sourcing the implementation, pricing the service, or complying with accessibility legislation.

7.5.2.2 Security‑by‑design and user control

EUDI says, among other things, that the wallet:

• “MUST be created by implementing a protection thread (security‑by‑design) and be safe.”

• “MUST be user‑friendly.”

• “MUST be transparent and user‑monitorable.”

• “MUST be under the sole control of the user.”

GovStack has strong privacy/security principles (unobservability, unlinkability, consent, secure storage), but it does not explicitly require that the wallet be transparent and user‑monitorable or under the sole control of the user with that wording and strength; some protections are only RECOMMENDED rather than mandatory.

7.5.2.3 Governance, risk management and reliability of the provider

EUDI adds organisational constraints on the wallet provider, e.g.:

• If the provider is a private entity, it “MUST ensure that the digital identity wallet service is offered functionally separately from other services it provides.”

• It “MUST employ highly qualified personnel or subcontractors who have received appropriate training.”

• “Reliable systems MUST be used to store data so that: 1) data is not publicly available without the user's consent, 2) only authorised persons can modify data, and 3) it is possible to determine whether the data is authentic.”

• The provider “MUST implement appropriate policies to manage the legal, financial, reputational and other direct risks associated with offering a digital identity wallet.”

• The provider “MUST use appropriate measures against falsification and against the unauthorised deletion, modification or making inaccessible of data.”

None of that appears in the GovStack wallet specifications.

7.5.2.4 Logging, retention and provider access to logs

EUDI defines logging much more strictly. It says the wallet:

• “MUST store and make available to the user through a common desktop all logs of transactions made with the identity token.”

• “MUST ensure the integrity, authenticity and confidentiality of logs stored for the purpose of the shared desktop.”

• “MUST retain transaction logs collected for the purpose of the common desktop for the period specified in Union or national law.”

• “MUST allow the user to download transaction logs collected for the purpose of a shared desktop.”

• The provider “MAY access transaction logs collected for the purpose of the common desktop only when necessary to provide the service and only with the explicit consent of the user.”

GovStack requires the wallet to keep logs of key actions (download, share, delete) and to present this history to the holder, but it does not define legal retention periods or strict rules on when the provider may access logs.

7.5.2.5 Deep privacy guarantees and data separation

On top of basic GDPR principles, EUDI adds:

• The wallet “MUST use privacy‑preserving technologies that ensure non‑association when electronic evidence does not require user identification, when evidence is presented to different relying parties.”

• Information about the use of the wallet “MUST NOT be collected or stored beyond what is necessary to provide the wallet service or meet explicit legal obligations.”

• Personal data stored for the European digital identity wallet “MUST NOT be combined with data from other services or used for unrelated purposes.”

• Personal data for the wallet “MUST be stored logically separately from personal data processed in the context of any other service.”

GovStack’s wallet spec clearly aims for unobservability and unlinkability, but again, many of those are recommendations rather than strict regulatory MUSTs, and it does not talk about logical separation from other services run by the same provider.

7.5.3. Functional / UX gaps

7.5.3.1 “Common desktop” / unified dashboard

EUDI defines a common desktop (dashboard) with several explicit duties:

• It “MUST store and make available to the user” all transaction logs.

• It “MUST provide an overview on the common desktop of all relying parties with whom the user has established a connection, along with a list of the data exchanged with them.”

• It says the common dashboard “MUST allow the user's chosen relying parties to request the deletion of exchanged personal data in accordance with Article 17 of the GDPR” and

• “MUST maintain a history of deletion requests submitted under GDPR for display to the user.”

• It “MUST enable the common desktop to submit complaints about suspicious or illegal requests from relying parties to national data protection authorities, including the necessary information to substantiate the suspicion,” and

• “MUST log complaints sent to data protection authorities via the common dashboard.”

GovStack has separate functions for transaction logs, complaint submission, and data deletion requests, but does not require them to be integrated into a single, user‑facing dashboard listing all relying parties and exchanges.

7.5.3.2 Integrated disclosure policies

For electronic attestations, EUDI adds precise policy semantics:

• It says that “for electronic attestations with an integrated disclosure policy, the wallet must verify and inform the user whether the relying party or European digital identity provider requesting the evidence is authorised to request the evidence.”

• It also says the wallet “MUST enable the implementation of integrated disclosure policies” such as:

  • no policy (no extra restrictions),

  • “authorised‑relying‑parties‑only”, where evidence may be disclosed only to listed relying parties, and

  • “specific root of trust”, where the user is recommended to disclose evidence only to relying parties whose certificates chain to specified trust anchors.

GovStack supports selective disclosure, data minimisation and consent, but it does not define this notion of an embedded disclosure policy object with explicit allow‑lists and trust‑root constraints.

7.5.3.3 Split crypto module (“secure crypto wallet app”)

EUDI models a dedicated cryptographic component and says, for example, that the wallet:

• “MUST manage critical assets in a digital wallet crypto application.”

• “MUST ensure the integrity, authenticity and confidentiality of communication with the crypto application.”

• “MUST, when performing operations using cryptographic or other critical assets involving high‑assurance e‑identification, comply with the high‑assurance authentication requirements and always perform these operations in the crypto application of the digital wallet.”

• “MUST be able to generate cryptographic keys.”

• “MUST be able to delete critical assets.”

• “MUST be able to provide evidence that it possesses the private keys associated with the public keys used for cryptographic bindings.”

GovStack requires secure storage and trusted hardware/TEE for keys, but it does not explicitly separate “wallet UI” from a “crypto application” with its own certification and responsibilities.

7.5.3.4 Legal‑style complaint and deletion workflows

GovStack has:

• a complaint submission capability to a supervisory body, and

• a data deletion request capability, both as wallet features.

EUDI goes further in tying those to GDPR and DPAs:

• complaints must be logged and visible to the user via the common dashboard,

• deletion requests must be tracked and historically visible to the user,

• and they are explicitly tied to GDPR Article 17 rather than just generic “delete” actions.

GovStack doesn’t add that legal framing or history‑tracking, so the regulatory detail and the UX for tracking these flows are missing.