Ensure normative traceability, functional classification, and structured governance for EUDI Wallet architecture evolution

Title

Ensure normative traceability, functional classification, and structured governance for EUDI Wallet architecture evolution

Background

The current consultation and architectural development process for the EUDI Wallet (as coordinated via OpenCode and the public OOC sessions) shows valuable community participation, but lacks structured traceability and governance mechanisms for normative dependencies and architectural decisions.

In the long term, this can lead to:

  • inconsistent understanding of normative changes,
  • unclassified or ambiguous functional requirements,
  • and fragmentation of knowledge across unstructured issue discussions.

Problem Statement

To ensure sustainable, interoperable, and transparent architecture evolution, the governance and consultation process should meet basic engineering and compliance requirements:

  1. Normative Traceability
    All standards and specifications that have normative or implementation impact (ETSI TS, IETF RFC, W3C, ISO, CIR, etc.) must be:

    • listed as normative requirements within the OpenCode repository,
    • linked to their current authoritative version,
    • and automatically updated or annotated when revisions occur.

    Benefit: Every stakeholder (e.g. QTSP, Wallet Provider, Member State Authority) can immediately recognize when normative updates affect implementation scope.

  2. Functional Classification
    Functional requirements within the architecture documentation should be classified according to their normative basis:

    • Non-functional (e.g. performance, usability, scalability),
    • Functional (derived from ETSI, IETF, or CIR requirements),
    • Meta-functional (governance, process, conformance).

    Benefit: Creates a unified taxonomy for requirement validation and simplifies cross-standard audits.

  3. Structured Consultation Governance
    Open Online Consultations (OOC) and related issue-based discussions should not exist in isolation.
    Instead, each OOC topic must result in:

    • a versioned, curated summary page in OpenCode,
    • cross-linked issues and decisions,
    • and review ownership assigned to responsible organizations (e.g. SPRIND, BMI, BMDV, or QTSP working groups).

    Benefit: Prevents information loss in issue threads and ensures traceable policy-to-implementation alignment.

Proposal

Implement a “Normative Mapping & Consultation Governance Framework” within OpenCode that:

  • Defines a version-controlled list of all normative dependencies (with metadata: version, publication date, reference links, impact level).
  • Enforces tagging and classification rules for all functional and non-functional requirements.
  • Establishes a public governance board (SPRIND/BMI/BMDV) responsible for maintaining transparency of OOC outcomes and architectural decisions.

Expected Impact

  • Immediate visibility of normative changes and their implementation impact.
  • Transparent linkage between European legislation, ETSI/IETF standards, and national architecture evolution.
  • Stronger auditability and confidence for cross-border stakeholders (QTSPs, regulators, and service operators).
  • Reduced redundancy and clearer responsibility for architecture decision-making.

References

  • ETSI TS 119 478 (Draft V0.0.3) – Wallet Architecture
  • CIR (EU) 2025/1569 – Catalogue of Attributes
  • eIDAS 2.0 Regulation (EU) 2024/1183
  • IETF RFC 6749 / 7523 / 7591 / 9068 – OAuth 2.0 / JWT
  • W3C VC Data Model 2.0 / DCAT-AP 3.0
  • ISO/IEC 27001 – Information Security Management
  • Open Online Consultation (OOC) #24 (closed) – Qualified Electronic Signatures in EUDI Wallets
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information