ARF
The ARF, the Architecture and Reference Framework, is the technical specification of the EUDI Wallet ecosystem: it turns what eIDAS 2.0 requires in law into the concrete roles, credential formats, protocols and trust infrastructure that implementers have to build.
It is maintained by the European Commission together with the member states through the eIDAS Expert Group and published in versioned releases, each accompanied by a set of technical specifications and annexes covering individual topics such as the PID rulebook, trust and revocation, or the wallet's cryptographic requirements. The ARF is what settles the questions a regulation deliberately leaves open at the level of detail implementers need: that a wallet uses OpenID4VCI to receive credentials and OpenID4VP to present them, that PID and attestations come in SD-JWT VC and ISO mdoc format, how a wallet proves to an issuer or verifier that it is genuine, and how registered issuers and relying parties are published in national registries so the other side can check them before trusting a credential. It is developed in the open on GitHub, where member states, industry and the large-scale pilots such as Potential and DC4EU raise issues and propose changes before a release is finalised, which is why the document keeps evolving as those pilots surface gaps the text did not anticipate. Anyone building for the EUDI Wallet reads the ARF rather than the regulation or its implementing acts for these details, since the acts set the legal obligation while the ARF fixes the interoperable way of meeting it. A wallet, issuer or verifier that only satisfies the regulation without following the ARF's technical choices would not interoperate with the rest of the ecosystem, even if it were legally compliant.
Related terms
How often does the ARF change?
The ARF is released in versioned updates as the European Commission, member states and large-scale pilots such as Potential and DC4EU surface gaps or ambiguities while building real implementations. Each release also ships technical specifications and annexes for its own topics. Development happens in the open on GitHub, so implementers can track proposed changes and raise issues before a version is finalised, rather than building against a document that never gets corrected.