Skip to main content

NL-FS: EUDI Wallet Functional Certification Scheme

NL-FS: EUDI Wallet Functional Certification Scheme

Download PDF (804 kB, 31 pages)Read the full text
Cover page of the document, as printed
Document referenceNL-FS
VersionRC1.0
StatusRelease Candidate
Date2026-11-06
Document typeFramework document
Parent frameworknone
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallets and the electronic identification scheme under which they are provided
Primary audienceSystem/Scheme Owner, CABs, EUDI Wallet providers, PID Provider
Secondary audienceEUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
Subsidiary DocumentsNL Certification System Documents
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​

NL-FS specifies the certification scheme for functional conformity of EUDI Wallet components within the Dutch EUDI Wallet Certification System, and establishes the evaluation methodology and conformity assessment procedures that accredited certification bodies shall apply (§1.1, p. 6). It is the scheme and framework that governs the application of all other NL-FS.x documents (§5.1.2, p. 11). It does not specify any test cases and does not define the certification scope for individual objects of certification; those scopes and requirements are in NL-FS-W (wallet solutions) and NL-FS-P (PID issuance services) (§1.3, p. 7).

Scope and object of certification​

  • The components covered are a wallet solution and a PID issuance service (§1.1, p. 6).
  • The object of certification is "the functional behaviour of the wallet solution or the PID issuance service — namely, that it correctly implements the protocols, interfaces, data formats, and other functional requirements laid down in the applicable implementing acts and in the technical specifications referenced therein" (§1.1, p. 6).
  • Entities subject to functional certification: (a) wallet providers, in respect of their wallet solution; (b) PID providers, in respect of their PID issuance services (§1.1, p. 6).
  • Rationale for including the PID issuance service: CIR 2024/2981 Article 3(3)(c) states that the object of certification includes the processes supporting provision and operation of a wallet solution, including user onboarding, and covers electronic identification means management, which under Implementing Regulation (EU) 2015/1502 includes issuance, delivery and activation of the eID means; "This implies that PID issuance is part of the object of certification" (§1.1 Note, p. 6).
  • Per platform: "Where a wallet solution includes wallet units for multiple OS versions (e.g. iOS and Android), the certification body shall treat these wallet units as separate objects of certification", because "these wallet units are, in fact, different mobile applications, having different code bases" (§9.1.1, p. 21).
  • Evaluation scope for a wallet solution: functional behaviour at its external interfaces towards users, PID providers, attestation providers, relying parties, and infrastructure components such as Trusted Lists and revocation services (§6.2, p. 14).
  • Evaluation scope for a PID issuance service: functional behaviour at its external interface towards a wallet solution; the conformity of the PID it issues (attributes, data model, encodings) is evaluated against the formats required by the applicable implementing acts, in particular CIR (EU) 2024/2977 (§6.2, p. 14).
  • Out of scope: cybersecurity certification of the wallet solution or PID issuance service (subject of the NL-CS series), and certification of wallet providers in conjunction with the eID scheme (covered by NL-P-W and NL-TL) (§1.2, p. 6).

Who it applies to​

  • Certification body: responsible for the conformity assessment in accordance with ISO/IEC 17065 and NL-SYS-01; shall be accredited per the latest version of ISO/IEC 17065 for the scope of this scheme by a national accreditation body appointed pursuant to Regulation (EC) No 765/2008 (§6.1, p. 13). It derives test objectives and test cases (directly or by reference to an existing test standard such as the FCAF), develops or references the ICS templates (§6.1(b), p. 13), preferably implements test cases in an automated conformance test tool (§6.1(c), p. 14), guides the developer in completing the ICSs (§6.1(d), p. 14), executes or has executed the applicable test cases (§6.1(e), p. 14), evaluates the evidence (§6.1(f), p. 14), qualifies test tools (§9.1.2, p. 21), creates a traceability matrix (§7.2.3, p. 18), sources supporting systems such as Trusted Lists (§9.1.1, p. 21), and issues certificates (§8.4, p. 20). It shall be competent to develop or reference test objectives and test cases (§7.1, p. 17).
  • Outsourced partner / testing laboratory: the certification body may execute tests "directly or through an outsourced partner"; where it uses an outsourced partner, "the partner shall be an ISO/IEC 17025-accredited testing laboratory" (§6.1(e), p. 14). Where the certification body did not execute the tests itself, the testing laboratory (or the developer) provides the evidence listed in §6.4 (§6.4, p. 16).
  • Developer of the object of certification: declares implemented features by filling out the ICS template of NL-FS-W or NL-FS-P and the ICS templates of each supported technical specification (§6.1(d), p. 14; §6.3, p. 15). It may execute tests itself, using a testing tool qualified by the certification body, and submits logs and verdicts per test case for review (§9.1.3, p. 21).
  • Wallet providers and PID providers: the entities subject to functional certification (§1.1, p. 6); they rely on NL-FS, and on NL-FS-W or NL-FS-P respectively (§5.1.2, p. 11).
  • Certification bodies at NL-P-W / NL-P-P level: verify validity and scope of NL-FS and NL-CS certificates and do not re-evaluate requirements already covered by them (§5.3, p. 12).

Contents​

  • §1 Scope (1.1 Object of certification, 1.2 Out of scope, 1.3 Document structure): what is certified and what is not; overview of chapters; p.6. Read
  • §2 Legal basis: the eIDAS Regulation and four Commission Implementing Regulations on which the scheme rests; p.8. Read
  • §3 Normative references: ISO/IEC 17000, 17065, 17067, NL-SYS-01, NL-SYS-02, NL-FS-W, NL-FS-P; p.9. Read
  • §4 Terms and definitions: points to ISO/IEC 17000/17065/17067, NL-SYS-02 and Article 2 of CIR 2024/2979 and CIR 2024/2981; p.10. Read
  • §5 Certification scheme documentation structure: the NL-FS document series and document map (Table 1), relationship to NL-SYS-01, to NL-CS, NL-P-P/W and NL-TL, scheme type, use of certification and marks; p.11. Read
  • §6 Evaluation methodology: overview of the method (with figure), evaluation scope, Implementation Conformance Statements, evidence requirements; p.13. Read
  • §7 Test case development methodology: deriving test objectives and test cases from functional requirements (with figure), test case definition, coverage, traceability; p.17. Read
  • §8 Certification process: initial certification, surveillance, recertification, certificate requirements; p.19. Read
  • §9 Evaluation methods: requirements evaluated by testing (test framework, tooling, execution, outcome, evidence), reference test case specifications, requirements evaluated by inspection; p.21. Read
  • Annex A (normative) Test case specification details: required test case fields, grouping and identifiers (with figure), profiles, preconditions, informative example; p.24. Read
  • Annex B (normative) Feature list for inclusion in certificates for functional conformance: Table 1 Feature Descriptions and Table 2 Certificate Feature Table; p.28. Read
  • Annex C (informative) Test Framework Design Principles: functional design principles, output requirements, qualified test environment; p.30. Read

Key points​

  • Legal basis: Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 (in particular Article 5a), CIR 2024/2977, CIR 2024/2979, CIR 2024/2981 (in particular Article 3 and Annex III) and CIR 2024/2982 (§2, p. 8). Annex III of CIR 2024/2981 requires conformity assessment of functional requirements defined in CIR 2024/2977, 2024/2979 and 2024/2982 (§2, p. 8).
  • A certification under NL-FS is a product certification; the NL-CS series is the parallel product certification addressing the cybersecurity of the wallet solution; "The NL-FS and NL-CS series are assessed and certified independently of each other; neither replaces the other" (§5.3, p. 12).
  • Scheme type: Type 6 as defined in ISO/IEC 17067 (initial testing and evaluation, surveillance, periodic re-evaluation); common Type 6 elements are specified in NL-SYS-01, in accordance with Article 4(3)(a) of CIR (EU) 2024/2981 (§5.4, p. 12).
  • An NL-FS certificate is "internal assurance information within the certification hierarchy" and does not of itself confer the right to use the EU Digital Identity Wallet Trust Mark (§5.5, p. 12).
  • Functional requirements "originate strictly from the regulatory sources (the eIDAS Regulation and its implementing acts) only" (§7.1, p. 17).
  • The scheme does not prescribe a set of test objectives and test cases, but recognises that the European Commission's Functional Conformance Assessment Framework (FCAF) "may provide a suitable reference set ... in the future" (§7.1, p. 17). Referencing the FCAF is not mandatory (§9.2, p. 22).
  • If the certification body references the FCAF or any other external test case specification, it shall review correctness and coverage, review suitability for the object of certification, report gaps in coverage or bugs to the organisation maintaining the test case specification and, where corrections are not made (the text reads "(I time)"), develop additional test cases, and record the version referenced (§9.2, p. 22).
  • Example of an existing test case specification with its own ICS: ISO/IEC 18013-6 (for ISO/IEC 18013-5 proximity presentations); the FCAF ICS is named for SD-JWT VC and OpenID4VP (§6.3, p. 15).
  • Test objectives are natural-language statements derived line-by-line from functional requirements, granular and single-purpose (§7.1, p. 17). Test cases shall include positive and negative cases and should be atomic (§7.1, p. 17); they treat the object of certification as a "black box" (§7.2.1, p. 18).
  • Coverage: the certification body shall create or reference test cases that test positive and negative scenarios for each functional requirement, and test cases that exercise different usage scenarios; for example, for a remote attestation presentation, test cases should cover different EAA types and formats (§7.2.2, p. 18). A traceability matrix shall show full coverage of in-scope functional requirements (§7.2.3, p. 18).
  • Testing shall be conducted in a controlled environment (the "test framework") that ensures testing is impartial and reproducible; testing of wallet solutions shall be performed using clearly defined test devices, operating systems and configurations, in line with the developer's completed ICS (§9.1.1, p. 21).
  • Test tools shall be able to provide valid and invalid inputs and receive responses, execute the test case specification(s), and log a full trace of messages; where used, the certification body qualifies them as fit for purpose (§9.1.2, p. 21).
  • Test execution "should be performed by the certification body (directly or through an appropriately qualified outsourced partner) but may also be done by the developer"; a developer shall use a tool qualified by the certification body (§9.1.3, p. 21). Where the developer generates the evidence, the certification body "shall obtain assurance that all applicable test cases are executed ... in a reliable and repeatable manner, by qualified and independent personnel" (§6.1(e), p. 14).
  • Test outcomes: executed test cases are Pass or Fail; non-executed test cases are Not applicable (profile conditions not met per ICS) or Inconclusive (preconditions not fulfilled; the certification body shall investigate) (§9.1.4, p. 22).
  • The certification decision shall be either Pass or Fail, taken in accordance with the common process of NL-SYS-01 (§6.2, p. 14).
  • Certain functional requirements, mainly involving behaviour on the user interface (e.g. information shown by the wallet when asking for user approval during presentation of an attestation), are evaluated via inspection by a human tester; they shall be covered by appropriate test cases complying with this document, and such test cases require test tools ("simulators") to bring the object into the required state (§9.3, p. 23).
  • Certificate validity: the expiry date "shall not be later than 5 years after the issuance date" (§8.4(q), p. 20).
  • The certification body shall ensure the ICS forms referenced in the certificate are publicly available for the entire validity period of the certificate (§8.4, p. 20).
  • Where an evaluation (including surveillance or special evaluations) identifies significant changes to the object of certification, new certification documentation is issued that retains the original expiry date (§8.4, p. 20).
  • Surveillance shall follow the certification cycle of NL-SYS-01 and shall take into account the rate of change of the NL-FS.x documents, the referenced technical specifications and the implementing acts (§8.2, p. 19).
  • A surveillance evaluation is triggered at minimum by: (a) a change to the object of certification affecting its functional behaviour or ICS-declared features; (b) a change to implementing acts or referenced technical specifications that materially affects the certified requirements; (c) a change to a test case specification that alters, adds or removes applicable test cases (§8.2, p. 19).
  • Transition arrangements for new or amended requirements or test cases "shall be defined by the certification system" and are not specified in this document (§8.2, p. 19).
  • Recertification is performed against the NL-FS.x documents and test case specifications current at that time; where a component that can be tested individually is unchanged together with its applicable test objectives, its re-evaluation may rely on previous evidence, provided that evidence remains valid and the certification body can verify its continued applicability; new or amended test objectives and changed components are evaluated in full (§8.3, p. 19).
  • Where an NL-FS certificate is suspended, withdrawn or expires, consequences for relying certifications follow from the hierarchy defined in NL-SYS-01 and NL-TL (§5.3, p. 12).

Process​

Preparatory activities (before any specific certification; the four left-most boxes of the figure) (§6.1, p. 13–14):

  1. (No actor named) The functional requirements are found in the eIDAS Regulation, the implementing acts and referenced technical specifications, and are further identified in NL-FS-W (wallet solutions) or NL-FS-P (PID issuance services) (§6.1(a), p. 13).
  2. Certification body: derives test objectives and test cases (Chapter 7), directly or by reference to an existing test standard such as the FCAF, and develops or references the ICS template(s) (§6.1(b), p. 13).
  3. Certification body (directly or through a qualified outsourced partner): preferably implements the test cases in an automated conformance test tool (§6.1(c), p. 14).

Per certification (the four right-most boxes of the figure) (§6.1, p. 14): 4. Developer: completes the ICS of NL-FS-W or NL-FS-P and the ICSs of each supported technical specification; the certification body guides the developer (§6.1(d), p. 14). 5. Certification body (directly or through an ISO/IEC 17025-accredited testing laboratory, or relying on developer-generated evidence where it has developed or qualified a test tool): executes the applicable test cases, using the ICSs to determine applicability (§6.1(e), p. 14). 6. Certification body: evaluates the evidence to determine whether a certificate of conformance can be issued (§6.1(f), p. 14); decision Pass or Fail per NL-SYS-01 (§6.2, p. 14). 7. Certification body: issues the certificate with the content of §8.4 (§8.4, p. 20). 8. Certification body: surveillance per NL-SYS-01 cycle and triggers (§8.2, p. 19); recertification per NL-SYS-01 (§8.3, p. 19).

Initial certification follows the common process of NL-SYS-01 and includes a full evaluation against all applicable test objectives, as determined by the profile and ICS (§8.1, p. 19).

Figures​

  • Figure in §6.1 (p.13), titled "From eIDAS Legal Texts to a Certified EUDI Wallet": eight boxes left to right — "eIDAS Legal Texts" (Requirements and references to technical specifications; e.g. Regulation (EU) 910/2014, CIR (EU) 2024/2981) → "Functional Requirements" (What the wallet solution must do) → "Certification Body" (Generates Test Objectives; Based on the requirements) → "Test Cases" (Detailed scenarios to verify conformity) → "Developer Submits ICS" (Indicates all features implemented; with the caption "Test cases are selected and configured based on ICS specifics") → "Testing" (Execute test cases in a suitable environment) → "Certification Decision" (Confirm conformity) → "Certificate Granted" (to the Wallet Solution) (§6.1, p. 13).
  • Figure in §6.3 (p.15): "ICS Level 1: Wallet Features Implemented — Defined by NL-FS Series", with three subordinate boxes: "ICS Level 2: Protocol Optionality — Defined by Individual Protocol Standards" and two boxes "ICS Level 2: Technical Specifications Optionality" (§6.3, p. 15).
  • Figure in §7.1 (p.17): three boxes linked by downward arrows: Functional Requirements → Test Objectives → Test Cases (§7.1, p. 17).
  • Figure in Annex A.2 (p.25): tree "Object of certification" → "Test layer" → "Test area" → "Test group" → "Test unit" → "Test case" (Annex A.2, p. 25).
  • Annex A.5 example (p.27): reproduced test case "mDL_MS_DE_DRWiFi_02" from ISO/IEC 18013-6 with fields Test case ID, System under test (mdoc), Purpose, Reference (ISO/IEC 18013-5:2021, 8.2.1.1), Technology, Profile, Preconditions, Test scenario, Expected results; applicability is decided via ICS statements 47 and 56 of ISO/IEC 18013-6 Annex B.1; the "Technology" field is ISO-specific and not required (Annex A.5, p. 26–27).

ICS (Implementation Conformance Statements)​

  • ICSs are declarations by the developer about features supported or not supported, consisting of statements answered Yes or No (§6.3, p. 14).
  • Two levels: (1) the ICS in NL-FS-W / NL-FS-P, covering the legally mandated features, enabling modularity; (2) technical-specification-level ICSs that come with each test case specification (e.g. ISO/IEC 18013-6, FCAF), covering only optional features of base standards; "Objects of certification are not allowed to pick and choose from mandatory features of these standards"; these are not included in NL-FS-W/NL-FS-P (§6.3, p. 15).
  • Developers shall complete and submit both the NL-FS-W/NL-FS-P ICS and the ICS of each supported technical specification (§6.3, p. 15).
  • A submitted ICS shall at minimum identify the object unambiguously (name, version, build identifier) and declare each statement true or false (§6.3, p. 16).

Evidence (§6.4) and certificate content (§8.4)​

  • Scheme-specific evidence (where the certification body did not run the tests): (a) description of the object incl. build identifier, version, Software Bill of Materials reference and configuration; (b) the NL-FS-W/NL-FS-P ICS; (c) the technical-specification ICSs; (d) test case specification(s) with versions; (e) the qualified conformance test tool and its version, if applicable; (f) test environment details (e.g. brand, make, OS version of test devices); (g) list of applicable test cases, preferably determined automatically from the ICS; (h) execution reports with verdict per test case, full communication details, and the exact reason for any verdict not Passed; (i) supporting documentation for authenticity and completeness (§6.4, p. 16).
  • Certificate content (in addition to ISO/IEC 17065 clause 7.7): unique identifier; name and version of object; Annex B Table 2 filled from Table 1; reference to completed ICS forms; name of the wallet eID scheme, owner and Member State where applicable; client name/address/contact; link to client website with ISO/IEC 17065 4.6 public information; certification body details; evaluating CAB and its accreditation if different; references to Regulation (EU) No 910/2014 and CIR (EU) 2024/2981; public evaluation report (if applicable); evaluation report; test case specifications, standards and versions; test environment description (incl. name and version of any qualified test tool; brand, make and OS version of test devices); name of wallet provider or PID provider; issuance date; expiry date ≤ 5 years after issuance (§8.4, p. 20).
  • Annex C (informative): a test framework satisfies Determinism, Well-defined dependencies and Reproducible test data sets (Annex C.2, p. 30); produces structured output per test case (identifier, version anchors, per-step and overall result with reason, reproduction information) (Annex C.3, p. 30); a test environment is "qualified" if executions are correct, deterministic/reproducible/traceable, compliant with the test case specifications, and their output's integrity and authenticity can be established, in which case the certification body may rely on its output, to the extent it judges proportionate, without reproducing each execution; this "does not diminish its responsibility for the certification decision" (Annex C.4, p. 31).

Requirements in this document​

  • NL-FS itself does not contain numbered requirements; it defines a test case identifier format: OoC_TestLayer_TestArea_TestGroup_TestUnit_##, where OoC is the object of certification (e.g. Wallet Solution, PID, PID Issuance Service, or an artifact such as an access certificate), the middle components name the test layer/area/group/unit (abbreviations recommended), and ## is a two-digit decimal number; components may be omitted (e.g. OoC_TestLayer_##) (Annex A.2, p. 25).
  • Mandatory test case fields: Test case identifier, Objective, References, Profiles, Preconditions, Test scenario (Test step ID, Description, optional Configuration data), Expected results (one per test step) (Annex A.1, p. 24). Profiles and Preconditions fields shall be present even when empty (Annex A.3–A.4, p. 26).
  • The certification body shall ensure a direct correspondence between each profile in each test case and an individual ICS statement; if the ICS does not match all specified profiles, the test shall be skipped and marked Not Applicable; with no profile, the test shall be executed on all objects (Annex A.3, p. 26).
  • Annex B certificate feature codes (Table 1, image) (Annex B, p. 28): Service — PROX Proximity Presentation, RPSD Remote Presentation - Same Device, RPCD Remote Presentation - Cross Device, ISSU Issuance, QES Qualified Signature, PSEU Pseudonym, DASH Dashboard / Transaction Log, PORT Portability, EDP Embedded Disclosure Policies, SUA Strong User Authentication; Object Type — PID, QEAA: <list of attestation types>, PUBEAA: <list of attestation types>, EAA: <list of attestation types>, DPA Data Protection Authority Request, ERASE Data Erasure Request; Transport — OPVP OpenID4VP, ISO5 ISO/IEC 18013-5, ISO7 ISO/IEC 18013-7, OPVI OpenID4VCI, NLISS Dutch-Specific Issuance Spec, ACV Access Cert Verification, RCV Registration Cert Verification; Format — MDOC ISO/IEC 18013 mdoc, SDJ SD-JWT VC, REDIR Redirects; Wallet Engagement — QR QR Code, NFC NFC, DCAPI DCAPI; Device Retrieval — NFC NFC, BLE BLE, WIFI WiFi Aware.
  • Table 2 Certificate Feature Table has rows Service, Object Type, Transport, Format, Wallet Engagement, Device Retrieval with empty value cells (Annex B, p. 28–29).
  • NL-SYS-01: common requirements on the certification body and the common certification process (application, evaluation, certification decision, surveillance, re-certification); applies to functional and cybersecurity testing and eID scheme conformity (§5.2, p. 11); Type 6 elements (§5.4, p. 12); certification decision (§6.2, p. 14); certification cycle (§8.2, p. 19).
  • NL-SYS-02: vocabulary (terms wallet solution, wallet unit, wallet instance, wallet provider, PID provider, PID, functional conformity, object of certification, test framework, certification body) (§4, p. 10).
  • NL-FS-W: certification scope and ICS template for wallet solutions (§5.1.1, p. 11; §5.1.2, p. 11); NL-FS-P: certification scope and ICS for PID issuance services ("PID issuance system conformance" in Table 1) (§5.1.1, p. 11; §5.1.2, p. 11).
  • NL-CS series: parallel cybersecurity product certification, out of scope (§1.2, p. 6; §5.3, p. 12).
  • NL-P-W: relies on the NL-FS certificate held by a wallet provider; NL-P-P: relies on the NL-FS certificate held by a PID provider; NL-TL: relies on NL-P-W and NL-P-P certificates (§5.3, p. 12).
  • Standards: ISO/IEC 17000, ISO/IEC 17065:2012, ISO/IEC 17067:2026 (§3, p. 9); ISO/IEC 17025 (outsourced testing laboratories) (§6.1(e), p. 14); ISO/IEC 18013-5 and ISO/IEC 18013-6 (§6.3, p. 15); OpenID4VP, SD-JWT VC (§6.3, p. 15).
  • EU legal acts: Regulation (EU) No 910/2014 / 2024/1183; CIR 2024/2977, 2024/2979, 2024/2981, 2024/2982 (§2, p. 8); Implementing Regulation (EU) 2015/1502 (eID means management) (§1.1, p. 6); Regulation (EC) No 765/2008 (accreditation) (§6.1, p. 13).
  • European Commission's Functional Conformance Assessment Framework (FCAF): possible reference test case specification (§6.1(b), p. 13; §7.1, p. 17; §9.2, p. 22).

Notes on this draft​

  • Cover page shows two overlapping dates, "2026-11-06" and "2026.11.05" (p. 1).
  • Footnote marker "ICS[1]" appears in §6.3 but no footnote text is present on the page (§6.3, p. 15).
  • §1.3 refers to "Chapter 0 defines terms and definitions"; the terms chapter is Chapter 4 (§1.3, p. 6).
  • §5.2 heading is "Relationship to NL-SYS-1" while the text uses "NL-SYS-01" (§5.2, p. 11).
  • Typos: "producs" (§5.3, p. 12); "does not re-evaluate the requirements already covered by them.The certification hierarchy" (missing space) (§5.3, p. 12); "(I time)" (§9.2, p. 22); "ISO/IEC 18103-5" (for 18013-5) (§6.3, p. 15); "shall a create a traceability matrix" (§7.2.3, p. 18); "shall leade to a verdict" (Annex A.1, p. 24); "evidence resulting for test case execution" (§6.1(f), p. 14).
  • §9.1.4 refers to "Appendix A.3" and "Appendix A.4", which are Annex A.3 and A.4 (§9.1.4, p. 22).
  • §6.4 refers to "the developer, see section 6.1 (d)"; developer-generated test evidence is described in §6.1(e), not (d) (§6.4, p. 16).
  • Table 1 in §5.1.2 titles NL-FS-P "PID issuance system conformance" and describes it as defining "the certification scope for the PID provider", while §3 lists NL-FS-P as "PID Issuance Service Conformance" (§5.1.2, p. 11; §3, p. 9).
  • The figure in §6.1 ends with "Certificate Granted to the Wallet Solution" and the §6.3 figure says "Wallet Features Implemented", although the scheme also covers PID issuance services (§6.1, p. 13; §6.3, p. 15).
  • The test case ID in the §A.5 text is "mDL_MS_DE_DRWifi_02" while the reproduced table shows "mDL_MS_DE_DRWiFi_02" (Annex A.5, p. 26–27).
  • ISO/IEC 17067 is cited as "ISO/IEC 17067:2026" (§3, p. 9).
  • Annex B Table 1 contains placeholders "<list of attestation types>" for QEAA, PUBEAA and EAA; the code "NFC" appears both under Wallet Engagement and Device Retrieval (Annex B, p. 28). Table 2 is an empty template (Annex B, p. 28–29).

Sources​