The ARF is the technical specification behind the EU Digital Identity Wallet

A specification, and the regulation it implements

This repository holds the Architecture and Reference Framework for the European Digital Identity Wallet, which the README describes as the common technical specification for the Wallet and its ecosystem. It is read online at eudi.dev.

The legal basis is specific and worth quoting precisely. The European Digital Identity Regulation, Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, lets every EU citizen, resident and business obtain an EUDI Wallet. The amendment builds on the original framework by improving its effectiveness and extending its benefits to the private sector, so that people can link and present aspects of their national digital identity, securely and under their own control, across Member States.

The three properties the README lists are the ones that matter for anyone judging whether the framework does its job. It is available to everyone who wants it, any EU citizen, resident or business. It is widely usable, to identify users and give them access to public and private digital services across the EU. And it is controlled by users, with people choosing and keeping track of the identity data and certificates they share, and nothing that is not necessary ever shared.

That third property is the one that constrains the technical design most, because a wallet that shares nothing unnecessary is a wallet whose protocol has to support selective disclosure, and that requirement propagates into every part of the architecture.

The project is hosted by the eu-digital-identity-wallet organisation, the homepage is eudi.dev, the licence is Creative Commons Attribution 4.0 International with a LICENCE file at the root, and the last push was on 2026-10-14.

Who writes the framework and under what mandate

The framework is not written by a vendor or a foundation, and the README is careful about that, because the governance is the point.

The ARF is developed as part of the Common Union Toolbox, a coordinated approach agreed between the Member States and the European Commission to support a consistent implementation of the Regulation across the EU, without interfering with or prejudging the legislative process.

The Toolbox was called for by Commission Recommendation (EU) 2021/946 of 3 June 2021, and it brings together three things: the ARF itself, a set of common standards and technical specifications, and common guidelines and best practices.

The work is carried out by the European Digital Identity Cooperation Group, and the README lists its four roles. It exchanges best practices and cooperates with the Commission on digital identity wallets, electronic identification means and trust services. It advises the Commission on draft implementing and delegated acts. It supports Supervisory Bodies in implementing the Regulation. And it carries out peer reviews of electronic identification schemes.

That structure tells you something about the document you are reading. It is written to be implementable by different Member States, so it will contain normative requirements, interoperability obligations and the constraints that come from being a common technical specification rather than a product. The peer review role also implies the text is checked against other Member State schemes rather than against one reference implementation.

The README points to the EDICG page and the Common Union Toolbox page for the wider context, and to the Commission's EU Digital Identity Wallet space and FAQ for the programme as a whole.

Three document sets, and why the tag matters

The repository contains three distinct bodies of material, and the distinction between them decides what you are reading.

The Architecture and Reference Framework in docs/main/index.md is the main narrative text describing the EUDI Wallet and its ecosystem. The Annexes in docs/annexes/README.md are the supporting material for the main text, including the normative high-level requirements. And the Discussion Topics in docs/discussion-topics/README.md are subjects open for public consultation, organised into iterations that each feed a major document release.

That third set is the one to look at first if you are implementing anything. A discussion topic is a question the framework has not yet settled, and the iteration structure means each round of them ends in a release. Reading them tells you where the specification is soft.

The README is explicit about which version counts. The latest authoritative version is the most recent tagged release, and the versions available are the tags on the repository. Versioning follows SemVer, and the release list shows why that matters: v2.9.0 on 2026-05-21, v3.0.0 on 2026-07-23, and a separate release named Topic_AA_rr_paper_v0.8 on 2026-10-14, which is a topic paper published outside the main version line.

So the practical rule for an implementer or an author is to quote a tag, not the branch. The branch contains work in progress and open consultation topics, and a statement that is true on main may not be true in the version that a member state has implemented.

Where the legal basis lives inside the document

There is a short paragraph in the README that tells implementers exactly where to look, and it is the kind of pointer that saves a lot of searching.

This version of the ARF reflects Regulation (EU) No 910/2014 as adopted by the co-legislators, together with its adopted Commission Implementing Regulations. The full, maintained list of those implementing regulations is in the main document, and the README points at the two places to read: section 1 Introduction and section 10 References.

That is a deliberate design decision about how the document is maintained. Instead of maintaining a separate table of implementing regulations somewhere outside the text, the list lives inside the specification, in the references section, so that the set of regulations the framework is aligned with is versioned along with the framework itself.

The practical consequence for an implementer is that the question of which implementing acts are in force is answered by reading the document you are implementing, and specifically its references section, rather than by tracking a separate publication.

The same version discipline applies to the Annexes, which contain the normative high-level requirements, and to the high-level requirements themselves, which the tooling renders from a CSV. The requirements are generated rather than hand written, which is what keeps the annex and the main text from drifting apart, and the build pipeline has a dedicated target for regenerating them.

The documentation pipeline: MkDocs, Material, Pandoc and a gate suite

The repository is a documentation project with a real toolchain, and the Makefile is the map of it.

The site is built with MkDocs and the Material theme. The requirements file pins mkdocs at 1.6.1, mkdocs-material at 9.7.6 and mike at 2.1.3, and the comment explains why the pins exist: MkDocs 1.x is unmaintained and MkDocs 2.0 will be incompatible with Material for MkDocs, so the versions are pinned defensively. The file also suggests pip-compile --generate-hashes requirements.txt for full supply chain integrity. Two other pins have their reasons spelled out: jinja2 at 3.1.6 because the high-level requirements generator depends on it directly, and mkdocs-autorefs at 1.4.4 because it resolves the internal Topic N cross-references from any page depth.

The Makefile exposes two families of target. Build targets convert Markdown into HTML through MkDocs and into PDF, DOCX and EPUB through Pandoc, with make serve serving the site locally and make pdfs building the release PDFs, which the comment says needs pandoc and a LaTeX distribution such as xelatex. There is also make hltr, which regenerates the Annex 2 requirements markdown from the high-level requirements CSV, and it is run via the hltr scripts.

Then there are the gate targets, which mirror the CI workflow. make gate runs the repo-wide docs quality checks, make build-strict does a strict MkDocs build, make check-links verifies internal links and section anchors, make check-csv checks the structure of the requirements CSV, make lint-md runs the Markdown lint, make check-private-links rejects links to private repositories, make check-typos runs codespell on given files, and make check-external uses lychee to check external links.

For a specification that member states will implement against, that gate suite is the interesting part. It means a broken cross-reference or a dead external link fails the build rather than shipping in a release.

Where this repository is the wrong tool

The limits are clear, and they come from the fact that this is a normative document rather than an implementation.

First, it does nothing on its own. If you want an EUDI Wallet, you want the reference implementation, which the README points to at docs.eudi.dev, and if you want to know whether an implementation is conformant, you want the conformance website at conformance.eudi.dev. This repository is the specification both of those are built against.

Second, it is not a stable API. SemVer applies to the document version, and a major version bump reflects a change to the specification, not a backwards incompatible change in a function signature. If you are building against it, a major bump means re-reading the diff rather than adjusting a version constraint.

Third, the discussion topics are not settled text. A document under public consultation can change, and a topic paper release such as the one dated 2026-10-14 is a contribution to that process rather than part of the framework. Treating anything in that area as a requirement is a mistake.

Fourth, the scope is the wallet ecosystem, not the whole of digital identity. The framework covers the wallet, its ecosystem and the reference framework for the implementing acts. It is not a guide to national eID schemes, and the EDICG's role of carrying out peer reviews of those schemes happens elsewhere.

Fifth, the licence is attribution based and worth checking for your use. The ARF is licensed under Creative Commons Attribution 4.0 International, which is a permissive licence for reuse and adaptation with credit, but the repository's own metadata does not classify a licence, and the LICENCE file at the root is the text that governs. For a specification you intend to quote in a product document or to translate, read it rather than assume.

The repository also carries the housekeeping that a document of this weight needs: a CONTRIBUTING.md with the code of conduct and the pull request process, a SECURITY.md, a CHANGELOG.md, a Makefile, a .codespellrc, a .markdownlint-cli2.jsonc and a .lycheeignore for the link checker.

Editorial conclusion

Anyone implementing the EU Digital Identity Wallet, or writing about it, should read this repository, because it is the authoritative text that the wallet, its ecosystem and the conformance testing all point at, and the most recent tagged release is the version to quote. It is the wrong starting point for using a wallet, since this is a specification and not an implementation, and it is the wrong source for the reference implementation, which lives in its own project. Before relying on any statement in it, pin to the latest tagged release rather than the branch, check that the implementing regulations you care about are listed in the references section, and read the discussion topics, because those are the parts still open for consultation.

Frequently asked questions

Official sources

1. eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework on GitHub
2. Issues
3. Project website
4. README
5. Releases