# 8. Implementation Workflow for the Wallet ## 8**.1 Plan and Align** Implementation begins with planning. Governments define the policy goals for the wallet, decide which user groups and services will be supported in the first wave, and conduct the legal and regulatory review, including the check of local legislation described earlier. Existing assets such as national identity apps or mobile eID solutions are inventoried, decisions are taken on whether to evolve them into EUDIW‑compliant wallets or to introduce a new application. At this stage, the national team examines the GovStack Wallet specification, the EUDIW ARF, and this guide together, and records a national wallet profile: which features will be supported, which platforms will be targeted, what local UX and language considerations apply, and where national rules require deviations or stricter behaviour. As part of this profiling exercise, teams should also define: a supported algorithm suite, minimal and preferred credential formats, target WSCD capabilities per platform and a roadmap for introducing more advanced features (for example, wallet-to-wallet flows) once the core issuance and presentation flows are stabilised. ## **8.2 Design and Architecture** In the design phase, architects draw a detailed picture of how the wallet will interact with Identity, Consent, and Signature Building Blocks, trust services, and app‑store ecosystems. Data flows are mapped. Decisions are made about which tasks fall on the client, which require backend services (for example, trust‑list processing), and which remain with external systems such as QTSPs. UX design runs in parallel, defining flows for onboarding via notified eID, receiving credentials, presenting them, authorising signatures, and managing transaction history. Security and privacy requirements are integrated from the beginning rather than bolted on later. This phase should produce: sequence diagrams for each main flow (onboarding, issuance, presentation, QES signing, device loss and recovery); interface specifications for each Building Block (URL paths, request/response schemas, error codes), a high-level deployment diagram (showing trust boundaries, networks, and external dependencies), and an initial threat model that identifies high-risk assets (keys, PID, QEAA, wallet-set certificates) and defines mitigations. **8.2.1 EU Profile Integration Checklist** The design phase should produce a concrete EU profile for the wallet. The following checklist can be used to translate the generic GovStack Wallet BB into an EUDI-ready implementation. | Area | Implementation action | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Internal authentication | Keep OIDC where appropriate for internal user authentication, identity proofing, and Identity BB integration. Do not rely on generic OIDC alone for EUDI wallet issuance and presentation. | | Issuance | Implement OpenID4VCI endpoints for PID and attestation issuance. Ensure that issuers can validate wallet status, Wallet Unit evidence, and required binding information before issuing. | | Presentation | Implement OpenID4VP for remote presentation and wallet-based authentication. The wallet should authenticate the relying party, display requested attributes and purpose or intended use, collect user approval, and create a verifiable presentation. | | Proximity flows | Add support or a roadmap for ISO 18013-5/-7 proximity presentation where required by the national profile or ARF conformance profile. | | Credential formats | Define the mandatory EU formats, including SD-JWT VC and ISO mdoc / ISO 18013-5/-7 where applicable. Keep any generic GovStack credential profile separate from the EU conformance profile. | | Trust integration | Integrate with access certificates, registration certificates, registrar information, trusted-list or LoTE-derived trust anchors, and revocation or status mechanisms. | | WSCD/WSCA | Define how wallet keys are generated, stored, attested, used, rotated, and deleted in secure hardware or hardware-backed environments. | | User approval and dashboard | Define user approval screens, transaction history, relying-party overview, data-rights actions, and complaint flows. Avoid treating every approval as GDPR consent. | | Testing | Prepare sandbox issuers, sandbox relying parties, conformance tests, verification scripts, and privacy tests for unlinkability, unobservability, and data minimisation. | ## **8.3 Build and Configure** Development teams then implement or adapt the wallet client. Integration with WSCDs is implemented and enforced. OpenID4VCI and OpenID4VP profiles are coded according to the ARF, and test harnesses are built to interact with example issuers and relying parties. Selective disclosure mechanisms, such as SD‑JWT or mdoc attribute requests, are wired into the consent screens. In parallel, backend components supporting the wallet—such as trust‑list fetching services, configuration servers, and anonymised telemetry collectors—are built under the constraints described in the security and unobservability sections. ## **8.4 Test, Certify, and Notify** Testing goes beyond basic functional checks. Protocol conformance is assessed using the official EUDIW test suites. Security testing covers client and backend code, WSCD integration and session management. Usability testing with diverse user groups checks that consent and disclosure screens are comprehensible and that error states are handled gracefully. Testing should include privacy and unlinkability checks, not only protocol conformance. Test cases should verify that the Wallet Provider cannot reconstruct relying-party usage, that telemetry does not include behavioural identifiers, that selective disclosure does not reveal unnecessary attributes, and that repeated presentations cannot be linked unless the chosen credential format or legal use case explicitly requires it. Implementation teams should maintain sandbox issuers, sandbox relying parties, verification scripts, and conformance test suites for OpenID4VCI, OpenID4VP, ISO 18013-5/-7, SD-JWT VC, trust validation, status checking, and revocation handling. EUDI Wallet solutions are submitted to certification under EUCC or national schemes until EUCC is available. Results feed into eIDAS notification packages and inform communication with EU counterparts and other Member States. ### 8.4.1 Wallet certification eIDAS 2.0 places a lot of emphasis on the certification of the wallet to ensure equal security for EU users. This section gives an overview of what to expect from the certification process. The detailed rules for this are in Commission Implementing Regulation (EU) 2024/2981, adopted on 28 November 2024, which lays down the rules for certification of EUDI Wallets. The regulation is very clear that the whole wallet solution is being certified: * the mobile app, * the back‑end services for issuance, revocation, key management, notifications, etc., * secure hardware components (secure elements, secure enclaves, HSMs, smartcards, etc.) where keys and critical material are stored, * relevant processes and services: onboarding, support, incident handling, updates, governance. Wallets are treated as composite systems: you can reuse existing certified components (e.g. secure element with Common Criteria or EUCC certification), but you still need a top‑level “wallet solution” certificate that says the entire assembled system, as used in real life, reaches Level of Assurance High. Assurance level “High” is defined in the eIDAS implementing regulation 2015/1502 and referenced again in 2024/2981. That requirement applies to the overall wallet solution. Whilst some sub‑components may be certified at lower levels if justified, but the system as a whole has to achieve “High”. In practice, “High” implies things like: * strong identity proofing and binding between the real person and the digital identity; * the wallet as an identification means must be tamper‑proof and duplication‑proof, typically via secure hardware; * keys should be in hardware that meets Common Criteria EAL4+ (or equivalent like EUCC High, or FIPS 140‑2/3 Level \~3) for the secure element. ### 8.4.2 An approximate wallet certification process Wallet certification process is a complex task and at the moment there is no national or EUCC scheme to be certified against. At the same time schemes are expected to broadly follow the Common Criteria / EUCC style of evaluation. Steps like this could be expected for the wallet provider to be followed. 1. *Defining the wallet solution and scope -* which products and services belong to the wallet solution: app(s), backend, secure hardware, onboarding processes, etc. and mapping them to the requirements in 2024/2981 and the Architecture & Reference Framework (ARF). 2. *Identifying relevant certifications* - reusing existing certifications where possible. 3. *Prepare documentation* - describing security objectives, threat model, architecture, cryptographic mechanisms, lifecycle, and privacy controls. 4. *Certification* - selecting the necessary CAB and submitting documents and product for testing. 5. *Surveillance, maintenance and recertification as defined by eIDAS.* ### **8.5 Launch and Evolution** Once tests and certifications are satisfactory, the wallet is released through app stores and other distribution channels. Early phases may concentrate on pilot groups or specific services before broader rollout. Metrics and feedback mechanisms are used to refine the application, address issues, and identify missing features. --- # 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/8.-implementation-workflow-for-the-wallet.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.