The EU Digital Identity Wallet (EUDI Wallet) is a regulated European digital identity ecosystem, not a single credential format or protocol. Its requirements span EU law, implementing regulations, the Architecture and Reference Framework (ARF), international standards, national trust infrastructure, certification, and wallet, issuer, and relying-party implementations.

This page is an annotated route into the primary sources. It distinguishes binding law from architecture guidance, stable standards from drafts, and reference software from production-ready implementations.

Start here

Use a versioned ARF release when requirements must be cited or implemented reproducibly. The unversioned latest documentation is useful for orientation but can change as the framework evolves.

The legal authority comes from EU legislation. The ARF and technical standards explain how participants can implement that framework; they do not replace the law.

Implementing regulations cover distinct operational subjects such as wallet integrity and core functionality, person identification data and electronic attestations of attributes, protocols and interfaces, certification, and notification to the Commission. Consult the maintained Commission index before treating any list as complete.

Architecture, requirements, and rulebooks

The ARF is the best technical entry point because it connects ecosystem roles and legal requirements to concrete protocols, formats, and trust mechanisms.

  • ARF main document — functionalities, ecosystem roles, architecture, data exchange, trust model, certification, and accessibility.
  • ARF annexes — definitions, normative high-level requirements, rulebooks, and design guidance.
  • High-level requirements by topic — a practical requirements index for implementers and reviewers.
  • PID Rulebook — requirements for Person Identification Data.
  • mDL Rulebook — the mobile driving licence profile.
  • Technical specifications — EUDI-specific normative specifications, including trust marks, wallet unit attestations, relying-party registration, data portability, and wallet-to-wallet interactions.
  • ARF discussion topics — open design work and unresolved topics; useful context, but not equivalent to adopted requirements.
  • ARF changelog — changes between framework releases.

The terms PID, QEAA, PuB-EAA, and EAA identify legally and operationally distinct kinds of data or attestation. They should not be flattened into one generic credential type when evaluating issuer authority, assurance, or acceptance policy.

Protocols and credential formats

The ecosystem composes specifications maintained by several standards bodies. Check the profile and version required by the applicable ARF release rather than assuming that support for a base standard establishes EUDI interoperability.

Issuance and presentation

Selective-disclosure credentials

SD-JWT is a disclosure mechanism, while SD-JWT VC defines a credential format and processing model. Neither label alone establishes an EUDI profile, issuer authorization, holder binding, status, or fitness for a relying party’s purpose.

Mobile documents

ISO standards are often paywalled. Their catalogue pages identify the canonical edition and status; implementation still requires access to the normative text and the exact EUDI profile that constrains it.

Trust, registration, and certification

Protocol interoperability is only one layer. EUDI decisions also depend on the role and registration of participants, trusted-list and certificate processing, wallet and device assurance, credential status, and policy for the requested attributes.

A successful signature or certificate-path check does not by itself establish that an issuer is authorized to issue a particular PID or attestation, that a relying party is entitled to request it, or that a wallet and presentation meet the required EUDI profile.

Implementations and developer resources

The Commission reference implementation is useful for interoperability work and for understanding intended component boundaries. Its own documentation describes it as evolving reference software, not a production certification or a substitute for security engineering.

Pilots and field testing

  • Commission pilot overview — the reference prototype, large-scale pilots, sectors, and use cases.
  • POTENTIAL — public services, banking, telecommunications, mDL, signatures, and health use cases.
  • NOBID — payment authorization and Nordic-Baltic interoperability work.
  • DC4EU — education and social-security credentials and infrastructure.

Pilot evidence can reveal interoperability and usability problems, but pilot participation or compatibility is not the same as legal compliance, certified wallet status, or production assurance.

Reading EUDI artifacts with Proofet Atlas

Proofet Atlas 0.1.0 can describe artifacts encountered in the EUDI ecosystem without treating EUDI as a credential family. For example, an artifact may have an intrinsic family such as ISO mdoc or SD-JWT VC, a specific PID or attestation profile, an issuance or presentation protocol context, and separately evaluated assurance results.

Detection of an EUDI-related identifier is only classification evidence. A conformance or trust conclusion requires the applicable legal and ARF version, the full profile, cryptographic and status evidence, participant authorization, holder and transaction binding, and an explicit relying-party policy.

Maintenance note

This ecosystem changes across legislative, framework, standards, and software release cycles. Links and source status were checked on 25 August 2026. For normative work, record the exact legal consolidation date, ARF release, standard edition or draft revision, implementation version, and date consulted.