Skip to main content

NL-CS-WI: EN 17640 FITCEM Protection Profile for EUDI Wallet Instance in a remote HSM architecture

NL-CS-WI: EN 17640 FITCEM Protection Profile for EUDI Wallet Instance in a remote HSM architecture

Download PDF (2.9 MB, 69 pages)Read the full text41 requirements
Cover page of the document, as printed
Document referenceNL-WI
VersionRC1.1
StatusRelease Candidate
Date27/10/2026
Document typeCertification Scheme EN 17640 FITCEM PROTECTION PROFILE for EUDI Wallet Instance in a remote HSM architecture
Parent frameworkNL-CS (parts1/2/3/4)
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallets
Primary audienceScheme Owners, Evaluation Laboratories; CABs, EUDI Wallet providers
Secondary audienceEUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
How to read this page

This page summarises the document. Every statement points to the section and page of the authoritative PDF it comes from: click a reference such as §6.1, p. 10 to open that page. If this summary and the PDF differ, the PDF applies.

What this document is​

This Protection Profile (PP) defines the Wallet Instance (WI) as the Target of Evaluation, WI-(TOE), for the Remote HSM configuration of a European Digital Identity Wallet (§Background, p. 4). It specifies the functional and assurance security requirements for the Wallet Instance within the FITCEM certification framework (§Background, p. 4). It is intended to provide a common security baseline for evaluating the Wallet Instance as part of an EUDI Wallet using the Remote HSM architecture, including its security dependencies and interactions with the WSCA/WSCD (§Background, p. 4). The PP is developed based on Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 (eIDAS 2.0) and Commission Implementing Regulation (EU) 2024/2981 (§Background, p. 4).

Scope and object of certification​

  • TOE definition: the TOE is a European Digital Identity Wallet Instance, abbreviated WI-(TOE), "a mobile application designed to give users full control over how they manage and share their personal identity" (§1.2, p. 7). It stores identification data and credentials from authorised PID/Attestation Providers, presents them to service providers online and in person, supports selective disclosure and offers a way to sign documents digitally (§1.2, p. 7).
  • TOE type: a mobile application installed on the User Device (§1.2.2, p. 8).
  • Exclusive configuration: "The TOE is designed exclusively for a remote HSM configuration, in which the security-critical cryptographic assets and operations are managed by a remotely deployed Wallet Secure Cryptographic Device (WSCD) accessed through the Wallet Secure Cryptographic Application (WSCA)." (§1.2, p. 7)
  • Remote HSM architecture (what is where):
    • The Wallet Instance operates on the user device and interacts with the WSCA running on Wallet Provider backend infrastructure, which in turn uses a certified remote HSM as the WSCD (§Background, p. 4).
    • User Device (UD): hardware, operating system and software environment on which the Wallet Instance executes (§1.2.2, p. 8).
    • WSCA: a WSCA implementation deployed on a hardened backend server; it provides security-critical cryptographic functionality, interfaces with the WSCD and ensures operations on critical assets are performed only after the required authorisation and User authentication (§1.2.2, p. 8).
    • WSCD: a hardware security device used by the WSCA to protect critical cryptographic assets; it shall prevent unauthorised export or use of protected private keys (§1.2.2, p. 8).
    • Keystore User Device (Keystore): a hardware-backed SE used for cryptographic assets not required to be protected by the WSCD; the possession factor used by the authentication protocol is managed in the keystore (§1.2.2, p. 8-9).
    • In the remote-HSM configuration "the critical private key is exclusively resident in the WSCA/WSCD" (§A.2 Table 14, p. 51).
  • TOE boundary: the document has no section titled "TOE boundary". Figure 1 shows the Wallet Instance (TOE) as one box inside the User Device; the Key store is a separate box in the User Device; the WSCA and the WSCD-HSM are inside "Wallet Provider Infrastructure" within a "Secure Environment"; the "Wallet Unit" boundary encloses both the Secure Environment and the User Device; Wallet Provider Backend, User, PID / Attestation Providers and Relying Party are outside the Wallet Unit (§1.2.1 Figure 1, p. 8). The WSCA/WSCD, Wallet Provider, PID/Attestation Provider, Relying Party, QTSP/Remote QSCD and User are listed as "User and External Entities" that interact with the WI-(TOE) (§2.4 Table 5, p. 25).
  • Functions in scope of the lifecycle description: installation, activation (User account, User authentications, WIA/KA generation), PID/Attestation issuance, credential disclosure, pseudonyms, revocation/deletion, and additional functionality (QES and seal, Wallet-to-Wallet, migration, DPA reporting, Trust Mark, logging) (§1.3, p. 12-20).

Who it applies to​

  • Scheme Owners, Evaluation Laboratories, CABs and EUDI Wallet providers: primary audience (§Document metadata, p. 2). EUDI Wallet ecosystem stakeholders: secondary audience (§Document metadata, p. 2).
  • WI-(TOE): the FSRs (Table 10) specify the security functionality that shall be provided by the Wallet Instance and its security-critical components; Table 11 specifies the mandatory RSRs; for the best-practice hardening mechanisms, "Where implemented, they shall meet the corresponding Resilience Security Requirements" (§3.1, p. 31; §3.2, p. 41; §1.2.5, p. 11). Appendix B gives the developer a starting point for the functional design and for describing the actual TOE design; it "does not prescribe a specific software architecture" (§B, p. 59).
  • Evaluation laboratory: may use both decompositions in Appendix B as "a traceable basis for verification and targeted testing", which "does not replace the detailed design evidence or evaluation activities required by the applicable methodology" (§B, p. 59). "The evaluation shall place greater focus on the assets and requirements covering T.USER_IMPERSONATION"; requirements mitigating T.LEAKED_PRESENTATION_DATA "shall also be evaluated, but with a more limited focus" (§2.2, p. 23).
  • User (S.USER, OE.USER): operates the Wallet Instance and authorises security-sensitive operations; shall keep credentials and authentication factors confidential, protect the PIN including during entry, and use the Wallet Instance only under their own control (§2.4 Table 5, p. 25; §2.5 Table 6, p. 25).
  • Wallet Provider (S.WP, OE.WP, OE.APP_DISTRIBUTION): securely activate the Wallet Instance, issue and sign the WIA and KA, keep the signing key verifiable through the trusted-anchor chain, maintain validity/revocation status and revoke compromised Wallet Instances (§2.5 Table 6, p. 25); support the Wallet Instance only on User Devices meeting OE.USER_DEVICE conditions (§2.5 Table 6, p. 27); distribute the Wallet Instance and updates via channels preserving authenticity and integrity, sign every release, release only certified versions, provide timely security updates and define a minimum supported version (§2.5 Table 6, p. 27). The Wallet Provider must revoke the Wallet Unit on User request, on PID Provider request, and on a security breach or compromise, and must regularly verify the security of the Wallet Unit (§1.3.5, p. 19).
  • WSCA/WSCD (S.WSCA/WSCD, OE.WSCA/WSCD): protect security-critical keys, run an authenticated protected channel with the Wallet Instance, perform operations only after User authentication, keep a per-User failure counter the Wallet Instance cannot reset, block after consecutive failures with increasing delays, unblock only after a reset procedure (e.g. PUK), generate per-key authorisation data at key generation (§2.5 Table 6, p. 25-26).
  • PID/Attestation Provider (S.PROVIDER, OE.PROVIDER): authenticate with access and registration certificates, verify WIA and KA (authenticity, validity, revocation), verify proof of possession for device-bound credentials, bind and sign issued credentials (§2.5 Table 6, p. 26).
  • Relying Party (S.RP, OE.RP): authenticate with access and registration certificates, verify authenticity, integrity and freshness of each presentation, the Provider signature and proof of possession, and process only validly presented and authorised Personal Data (§2.5 Table 6, p. 26).
  • QTSP / Remote QSCD (S.QTSP, OE.QTSP): protect qualified signing keys, sign only after User authentication and explicit authorisation, protect communication, return the result securely (§2.4 Table 5, p. 25; §2.5 Table 6, p. 27).
  • User Device (OE.USER_DEVICE): TEE or SE, hardware-backed keystore, key-usage restrictions, key and device attestation, trusted boot, sandboxing, OS-level User authentication, security updates for the supported period (§2.5 Table 6, p. 27).

Contents​

  • Front matter: cover (p.1), document metadata (p.2), history of changes (p.3), Background, Terminology, Relationship to Other Standards and Schemes (p.4-5), Table of Contents (p.6) (§Cover, p. 1; §Document metadata, p. 2; §History of changes, p. 3; §Background, p. 4-5; §Table of Contents, p. 6).
  • 1 Introduction: PP reference identification, TOE overview (ecosystem, Wallet Unit components, ecosystem entities, principal security interactions, user-device protection and self-protection) and the Wallet Unit lifecycle and cryptographic trust relationships; starts p.7 (§1, p. 7).
  • 2 Security Problem Definition: assets (Table 1), threats (Table 2), attack scenarios (Tables 3-4), User and external entities (Table 5), environmental security objectives (Table 6) and coverage tables (Tables 7-9); starts p.21 (§2, p. 21).
  • 3 Detailed Security Requirements: Functional Security Requirements (Table 10) and Resilience Security Requirements (Tables 11 mandatory and 12 best practice); starts p.31 (§3, p. 31).
  • A Requirement Coverage Rationale: mapping of FSRs and assets to the lifecycle (Table 13) and of FSRs, RSRs and OEs to the attack scenarios (Table 14); starts p.48 (§A, p. 48).
  • B Modular and functional Decomposition of the WI-(TOE): functional decomposition (Table 15), modular decomposition (Figure 2, Table 16); starts p.59 (§B, p. 59).
  • C OWASP MAS mapping to the Security Requirements: mapping of FSRs (C.1) and RSRs (C.2) to OWASP MASVS requirements; starts p.66 (§C, p. 66).
  • Colofon: one line, "FITCEM Protection Profile for Wallet Instance in the remote HSM architecture"; p.69 (§Colofon, p. 69).

Key points​

  • Two User authentication mechanisms are enrolled: OS-level User authentication and the WSCA/WSCD-level Remote User Authentication Protocol (RUAP) (§1.3.2.2, p. 13).
  • OS-level authentication (FSR_LOCAL_AUTH) shall be multi-factor (device possession plus a knowledge- or inherence-based factor), enforced at startup and before security-sensitive actions, and expire after the applicable inactivity timeout (§3.1 Table 10, p. 32).
  • RUAP (FSR_REMOTE_AUTH) shall meet Level of Assurance High of CIR (EU) 2015/1502, use at least two factors from different categories, and resist guessing, eavesdropping, replay and manipulation "with high attack potential" (§3.1 Table 10, p. 32).
  • The User Authentication Evidence (UAE) is derived from a knowledge-based factor (derived from the PIN) and a possession-based factor; it is verified against the Authentication Reference Data (ARD) (§Background, p. 4); the ARD is derived and shared with the WSCA/WSCD during initial enrolment, and each PIN verification is performed through a "live and fresh interaction" (§3.1 Table 10, p. 32). Disclosure of the ARD "shall not by itself enable User impersonation" (§2.1 Table 1, p. 21).
  • A PUK can be integrated in the protocol to reset the knowledge-based factor (§3.1 Table 10, p. 32).
  • Per-key authentication data is sent to the WI-(TOE) at key generation and provided at every security-sensitive cryptographic operation of that key (§3.1 Table 10, p. 33).
  • WSCA/WSCD-level authentication is required at least for initial generation of KAs and WIA, User approval of selective disclosure, deleting a PID or attestation, and requesting issuance of a new PID or Attestation (§1.3.2.2, p. 14).
  • The WIA technical validity period "shall be less than 24 hours", measured from the Wallet Provider's integrity verification to the expiry time in the WIA; the TOE must prove its integrity to the Wallet Provider before a WIA is generated (§3.1 Table 10, p. 33).
  • The KA is signed with WP_SIG_PRIV1 and the WIA with WP_SIG_PRIV2 (§1.3.2.3.1, p. 14; §1.3.2.3.2, p. 15). The TOE shall present a KA only to authorised PID/Attestation Providers during issuance and "shall not present a KA to a Relying Party" (§3.1 Table 10, p. 34). The TOE sends a KA only for device-bound PIDs/Attestations (§1.3.3.2, p. 17).
  • The WIA device-binding key pair may be managed by the WSCA/WSCD or by the Wallet Instance (§1.3.2.3.2, p. 15).
  • If RP_ACC_CERT or RP_REG_CERT validation fails, the TOE shall not disclose the requested PID or attestation (§3.1 Table 10, p. 35).
  • The TOE shall not delegate security-sensitive User approval and disclosure decisions "to a browser, operating-system component or other intermediary application" (§3.1 Table 10, p. 36).
  • Supported formats: SD-JWT VC for remote presentation and ISO/IEC 18013-5 mdoc for proximity presentation (§1.3.3.3, p. 17). Protocol flows: OpenID4VCI, OpenID4VP, ISO/IEC 18013-5, ISO/IEC 18013-7 and Digital Credentials API (§3.1 Table 10, p. 34).
  • Migration Object shall not contain WIA, KA, attribute identifiers/values or private keys of PIDs and device-bound attestations; the PID is re-issued before other attestations (§3.1 Table 10, p. 39).
  • Transaction logs shall not contain actual attribute values unless legislation requires it; Wallet Provider access to logs only with explicit prior User consent (§3.1 Table 10, p. 40).
  • The User-initiated factory reset shall delete the PIDs and electronic attestations, transaction logs and Wallet Instance configuration and settings, and request secure deletion of associated cryptographic assets from the WSCA/WSCD and applicable secure keystores (§3.1 Table 10, p. 31).
  • When rooting/jailbreaking, unauthorized developer or debug mode, execution in an emulator or app-virtualization environment, or other conditions invalidating the TOE's security assumptions are detected, the TOE shall terminate or disable all security-critical functionality and not perform security-critical operations until an acceptable security state has been restored (RSR_OPER_MOD) (§3.2 Table 11, p. 43).
  • The PIN shall not be persistently stored or logged; PIN-derived data shall be cleared immediately after use (RSR_PIN_ENTRY) (§3.2 Table 11, p. 42).
  • Cryptography shall follow the ECCG Agreed Cryptographic Mechanisms; mechanisms not yet included shall be explicitly identified, justified and subject to approval by the certification/evaluation process (RSR_CRPTO) (§3.2 Table 11, p. 45).
  • RNG: the WI-(TOE) must use a hardware RNG via SE or TEE, or a DRBG compliant to NIST SP 800-90A or ISO/IEC 18031 seeded by at least two entropy sources (one external trusted source, one from the mobile device); reseeding at least when the integrity/confidentiality of its state cannot be assured and at least every 24 hours of continuous operation (RSR_RNG) (§3.2 Table 11, p. 45).
  • OE.USER_DEVICE: the Wallet Provider shall support the Wallet Instance only on User Devices that provide, among others, a TEE or SE, a hardware-backed keystore, a trusted boot mechanism, application sandboxing and security updates for the period during which the Wallet Provider supports the device (§2.5 Table 6, p. 27). RSR_USERDEVICE: "The TOE shall check that the User Device and OS shall at minimum" provide, among others, a TEE or SE, a trusted boot mechanism, application isolation/sandboxing and mechanisms for secure and timely security updates (§3.2 Table 11, p. 41-42).
  • The WI-(TOE) shall be installed through an official application distribution channel (e.g. Google Play Store or Apple App Store) or a mechanism with equivalent authenticity and integrity protection (§3.1 Table 10, p. 31).
  • Assurance: the cover states assurance level "High/High" for identity proofing (CIR 2015/1502) and evaluation (EU Regulation 2019/881) (§Document metadata, p. 2). FITCEM is EN 17640:2022, which "defines the fixed-time cybersecurity evaluation methodology applicable to the evaluation of the Wallet Instance TOE" (§Background, p. 5). The document does not state an EAL, an AVA_VAN level or a FITCEM attack-potential rating for the evaluation; "high attack potential" appears only in the RUAP text (§1.3.2.2, p. 13; §3.1 Table 10, p. 32).
  • Conformance claims: the document contains no conformance-claims section (§Table of Contents, p. 6).

Assets (Table 1, 23 assets) (§2.1, p. 21-22)​

A.MUT_KEY (keys/data for the mutually authenticated WI–WSCA/WSCD channel), A.PIN (User PIN / knowledge factor), A.PUK (Personal Unblocking Key), A.POSS (User possession factor), A.UAE (User Authentication Evidence), A.ARD (Authentication Reference Data), A.KEYAUTH (per-key authorisation data), A.CMD (WSCA/WSCD commands), A.WIA (Wallet Instance Attestation), A.KA (Key Attestation), A.PIDATT (PIDs and Attestations), A.PRES (presentation data), A.NONCE (nonces/freshness data), A.LOG (transaction logs), A.MON (monitoring and security data), A.INIT (initial Wallet data), A.ANCHOR (trust anchors and trust lists), A.CERT (access and registration certificates), A.WIID (Wallet Instance identifier), A.TRUSTM (Trust Mark information), A.PSEUD (RP-specific pseudonyms), A.MIGR (Migration Object), A.QESDATA (QES signing data). Each has a required protection (confidentiality, integrity, authenticity, freshness, privacy as listed) (§2.1 Table 1, p. 21-22).

Threats (Table 2) (§2.2, p. 23)​

  • T.USER_IMPERSONATION: an attacker presents a stolen or otherwise obtained PID or Attestation to a Relying Party, including a freshly generated and validly signed nonce, to impersonate the legitimate Wallet User without that User's involvement or authorisation. Considered "the more severe threat" (§2.2 Table 2, p. 23).
  • T.LEAKED_PRESENTATION_DATA: an attacker causes Personal Data in a Wallet Unit to be disclosed to a Relying Party or other unauthorised recipient without the User's knowledge and authorisation, including by manipulating or compromising the presentation process (§2.2 Table 2, p. 23).

Attack scenarios (Tables 3 and 4) (§2.3, p. 23-24)​

  • AS.UI.01 Fake WSCA/WSCD during channel establishment; AS.UI.02 Cloning of Wallet Instance authentication factors; AS.UI.03 Theft of device-bound private key; AS.UI.04 Bypass of User authentication; AS.UI.05 Manipulation of WIA/KA binding; AS.UI.06 Replay or manipulation of authentication data; AS.UI.07 Bypass via Migration (§2.3 Table 3, p. 23-24).
  • AS.LPD.01 Fake Relying Party; AS.LPD.02 Manipulation of presentation request; AS.LPD.03 Bypass of User approval; AS.LPD.04 Manipulation of User approval information; AS.LPD.06 Manipulation of selective disclosure; AS.LPD.07 Presentation data interception; AS.LPD.08 Replay or transaction manipulation (§2.3 Table 4, p. 24).
  • AS.UI.03 and AS.UI.05 have no FSR or RSR assigned ("-") and are mitigated by environmental objectives (OE.WSCA/WSCD, OE.PROVIDER, OE.RP; OE.WP, OE.PROVIDER, OE.RP); AS.UI.05 "is primarily mitigated by the environment" (§A.2 Table 14, p. 51-52).

Organisational security policies and assumptions​

The document contains no sections or identifiers for organisational security policies (OSPs) or assumptions (§Table of Contents, p. 6). Table 6 identifies the security objectives applicable to the subjects and external entities in the operational environment as Environmental Security Objectives (§2.5, p. 25).

Security objectives​

  • For the TOE: the document contains no section defining TOE security objectives; chapter 2 (Security Problem Definition) is followed by chapter 3 (Detailed Security Requirements) (§Table of Contents, p. 6).
  • For the environment (Table 6, 8 objectives) (§2.5, p. 25-27): OE.USER (User control and protection of authentication factors); OE.WP (Wallet Provider trust and lifecycle management); OE.WSCA/WSCD (protection of cryptographic assets and secure cryptographic services); OE.PROVIDER (PID/Attestation issuance and Wallet Unit trust); OE.RP (presentation verification and transaction trust); OE.QTSP (protected qualified signature and seal services); OE.USER_DEVICE (secure User Device platform); OE.APP_DISTRIBUTION (authentic distribution and update of the Wallet Instance).
  • "The environmental objectives are particularly important for this threat because the Wallet Instance does not itself provide all of the required security functionality." (T.USER_IMPERSONATION) (§2.6.2.1 Table 7, p. 29).

Figures​

  • Figure 1 "Wallet Unit as part of the Wallet Ecosystem" (§1.2.1, p. 8): a block diagram. A dashed "Wallet Unit" boundary contains (left) a "Secure Environment" with "Wallet Provider Infrastructure" holding "WSCD-HSM" and "WSCA" (two-way arrow between them), and (right) "User Device" holding "Wallet Instance (TOE)" and "Key store" (two-way arrow between them). Two-way arrows connect WSCA–Wallet Instance and WSCA–Wallet Provider Backend. Outside the Wallet Unit: "Wallet Provider Backend" (top, arrows to WSCA, Wallet Instance and User), "User" (arrow to Wallet Instance), "PID / Attestation Providers" and "Relying Party" (bottom, arrows to Wallet Instance).
  • Figure 2 "Modular decomposition" (§B.2, p. 60): the WI-(TOE) as grouped module boxes: User Interface (Wallet User Interaction IF); Wallet Onboarding Modules (Wallet Onboarding Module); Acquisition / Activation Modules (PID Acq offline, PID Acq online, Pub EAA Acq, QeS Acq); Capture Modules (Biometrics Capture, ID-doc Capture, eID Means interface); Credential Generator Modules (Credential Generator); Resilience Modules (empty box); Core Modules (Wallet Core Engine, Wallet Pseudonym Manager, Wallet Dashboard); Local User Authentication (Local / System User Authenticator); Verification / Validation Modules (Credential Verification, Signature Verification, RP Verification); Data Modules (BackUp & Restore, Data & Credential Store, Secrets Vault, Transaction Log); Authentication / Confirmation Modules (Confirmation Module, SCA, SUA, Signature Initiation); Wallet Attestations / Authentication (WIM, SICZ, WUC); Presentation Modules (Online Presentation S-device, Offline Presentation, Online Presentation X-device); Request Verification Modules (Disclosure Authorization). Along the bottom: Mobile Device Functions, Mobile Device Secure Element HW, NFC interface.

Process​

The document describes the Wallet Unit lifecycle (not a certification process) (§1.3, p. 12-20):

  1. Installation: Wallet Instance distributed preferably via an official OS distribution channel; otherwise the Wallet Provider provides an authenticity/integrity check mechanism (Wallet Provider) (§1.3.1, p. 12).
  2. Mutual authentication channel: Wallet Instance establishes secure channels with the Wallet Provider and the WSCA/WSCD (WI-(TOE)) (§1.3.1.1, p. 12).
  3. Initial data: WI-(TOE) sends technical data, system diagnostics and security-posture signals to the Wallet Provider; the Wallet Provider minimises collection (WI-(TOE), Wallet Provider) (§1.3.1.2, p. 12).
  4. Activation – Wallet Provider User account: User registers; Wallet Provider associates the account with the Wallet Instance (User, Wallet Provider) (§1.3.2.1, p. 13).
  5. Activation – User authentications: User enrols OS-level authentication and RUAP; knowledge and possession factors bound to the ARD, ARD shared with WSCA/WSCD (User, WI-(TOE), WSCA/WSCD) (§1.3.2.2, p. 13-14).
  6. Activation – WIA and KA: User performs WSCA/WSCD-level authentication; WSCA/WSCD generates attested keys; Wallet Provider issues and signs KA and WIA (User, WSCA/WSCD, Wallet Provider) (§1.3.2.3, p. 14-15).
  7. Issuance – Provider authentication: TOE verifies the Provider's ISS_ACC_CERT and, where applicable, ISS_REG_CERT (WI-(TOE)) (§1.3.3.1, p. 16).
  8. Issuance – Wallet Unit authentication: TOE sends WIA and KA(s); Provider verifies signatures, validity, revocation status and proof of possession via nonce (WI-(TOE), WSCA/WSCD, Provider) (§1.3.3.2, p. 16-17).
  9. Issuance – generation: for a device-bound PID or Attestation, the Provider binds the credential to one of the public keys in the applicable KA, signs with ISS_SIG_PRIV and returns it via OpenID4VCI Credential Response (Provider) (§1.3.3.3, p. 17).
  10. Disclosure: TOE authenticates the RP (RP_ACC_CERT, RP_REG_CERT), authenticates the User, shows RP identity, requested attributes, intended use and evaluation outcome, obtains approval, and signs a transaction-bound presentation via the WSCD/WSCA; RP verifies the presentation (WI-(TOE), User, WSCA/WSCD, RP) (§1.3.4.1-1.3.4.2, p. 18).
  11. Revocation/deletion: Wallet Provider revokes the Wallet Instance (revoked status at all index positions in its WIAs) and, where the compromise affects a WSCA/WSCD, the WSCA/WSCD (a WSCD is revoked at all index positions in the corresponding KAs); for a revocable PID, the PID Provider must revoke the PID if either has been revoked; the Wallet Unit shall support secure deletion of its contents through a factory reset (Wallet Provider, PID Provider) (§1.3.5, p. 19).

Requirements in this document​

All 41 entries are listed one by one, with their text and PDF page, on the NL-CS-WI requirements page. You can also search them together with all other requirements.

Notes on this draft​

  • Identifier and version inconsistencies: the cover and metadata use "NL-WI", not "NL-CS-WI" (§Cover, p. 1; §Document metadata, p. 2). §1.1 states "Version: 0.7" and "Status: Non-Certified" while the metadata states "RC1.1" and "Release Candidate" (§1.1, p. 7; §Document metadata, p. 2). The metadata date is 27/10/2026, but the history table dates RC1.1 2026-10-31 (§Document metadata, p. 2; §History of changes, p. 3). Title wording differs: "in a remote HSM architecture" (cover) vs "in the remote HSM architecture" (§1.1, colophon) (§Cover, p. 1; §1.1, p. 7; §Colofon, p. 69).
  • The history table on p.3 has a third, overprinted line under the RC1.1 row that is not legible in the rendered page (in the text layer it duplicates the RC1.1 row) (§History of changes, p. 3).
  • Terminology definitions: the ARD definition reads "used at the WSCA/WSCD to verify the Authentication Reference Data (UAE)" (the expanded term is "Authentication Reference Data", the abbreviation "UAE") (§Background, p. 4). After the UAE definition there is an empty bullet (§Background, p. 4).
  • Undefined or misspelled requirement references: "FSP_REMOTE_AUTH" in FSR_WI_INSTALL and in Appendix C.1, while the requirement is FSR_REMOTE_AUTH (§3.1 Table 10, p. 31; §C.1, p. 66); "FSR_SELECTIVE_DISCLO" in Table 16 (Biometrics Capture) (§B.2 Table 16, p. 61); "SR_PROTOCOL" in Table 14 for AS.LPD.07 (§A.2 Table 14, p. 57). The prefix "FSP" of FSP_Q_SIGNATURE is not explained.
  • FSR_REVOCATION has no title line in Table 10 (other FSRs start with a title such as "Wallet Instance Attestation") (§3.1 Table 10, p. 37).
  • In §1.3.2.3.2 (WIA), the list is introduced as "Key Attestation has the following purposes:" although it describes the WIA (§1.3.2.3.2, p. 15). Incomplete sentence: "The verify if the TOE belongs to a certified Wallet Solution registered in the Wallet Provider Trusted List." (§1.3.2.3.2, p. 16).
  • Wrong cross-reference: "The User deletes a PID or attestation in their Wallet Unit (further detailed in section 1.3.4.3)", but §1.3.4.3 is "Pseudonyms" (§1.3.2.2, p. 14; §1.3.4.3, p. 18).
  • Per-key data terminology varies: "Per-key authentication shall be implemented at the WSCD and the per-key authorization data shall secure stored by the WI-(TOE)" (§1.2.4, p. 9); "Per-key authentication data shall be sent to the Wallet Instance" (§3.1 Table 10, p. 33); asset A.KEYAUTH is "Per-key authorisation data" (§2.1 Table 1, p. 21).
  • Attack scenario numbering skips AS.LPD.05 (§2.3 Table 4, p. 24).
  • Coverage tables: Table 7 text names FSR_KEY_ATTEST for T.USER_IMPERSONATION, but Table 9's requirement list for that threat omits it (§2.6.2.1 Table 7, p. 28; §2.6.3 Table 9, p. 30). Table 9 lists A.CERT twice for T.LEAKED_PRESENTATION_DATA and has an empty entry "A.ANCHOR; ;" in the Supporting row (§2.6.3 Table 9, p. 30). Table 14 lists "OE.WP" twice for AS.UI.04 (§A.2 Table 14, p. 51). Table 13 lists A.KEYAUTH and A.PUK twice for 1.3.2.2 (§A.1 Table 13, p. 48). Table 14 is titled "Coverage of the Required Asset protection" under the heading "A.2 Coverage of the attack scenarios" (§A.2, p. 49).
  • Appendix B intro says that "in Table 16 it groups the Functional Security Requirements (FSRs) and Resilience Security Requirements (RSRs)" for the functional decomposition, but the functional decomposition is Table 15, which contains only function names and descriptions (§B, p. 59; §B.1 Table 15, p. 59-60). The B.2 introductory paragraph is printed with its sentences out of order ("Security Requirements (FSRs) and Resilience Security Requirements (RSRs) implemented by the module. Figure 2 presents …") (§B.2, p. 60). Figure 2 shows "Disclosure Authorization" inside "Request Verification Modules", while Table 16 lists "Disclosure Authorization" and "Request Verification" as separate modules (§B.2 Figure 2, p. 60; Table 16, p. 64); Figure 2's "Resilience Modules" box is empty while Table 16 has a "Resilience" module covering all mandatory RSRs and "ALL ASSETS" (§B.2 Table 16, p. 65).
  • The document contains no conformance claims section, no OSP or assumption sections, no TOE security objectives section, and states no EAL, AVA_VAN level, FITCEM attack potential or evaluation duration for the evaluation (§Table of Contents, p. 6). The assurance-related wording found is "High/High" in the document metadata and "with high attack potential" in the RUAP text (§Document metadata, p. 2; §1.3.2.2, p. 13; §3.1 Table 10, p. 32).
  • Mixed requirement strength: RSR_OBF_COD says the TOE "may apply" obfuscation yet "At a minimum, obfuscation shall cover" (§3.2 Table 12, p. 46). RSR_USERDEVICE is phrased as a requirement on the User Device but says "The TOE shall check that the User Device and OS shall at minimum" (§3.2 Table 11, p. 41).
  • Typographical issues: "must be enforces by the subjects" (§2.4, p. 24); "(depicted in Figure Figure 1)" (§1.2.3, p. 9).
  • The document states that detailed descriptions of the individual modules are provided in [EUDI Oracle], an external web resource (https://eudi-oracle.yivi.eu/) (§Background, p. 5; §B.2, p. 61), and "Technical Specification 10" without further identification (§3.1 Table 10, p. 39).

Sources​