ARF

Origin: composes. The European Commission and Member-State technical experts write and maintain this. Solidus has no authorship role here, we read it and report, honestly, where our testnet lines up and where it doesn't.

The ARF is the technical specification that turns eIDAS 2.0's legal requirements into something engineers can actually build against. Where the regulation says "Member States shall provide a wallet," the ARF says, in detail: which protocols the wallet must speak, what data it must hold, how a verifier checks a presentation is genuine, and who is allowed to issue what. If eIDAS 2.0 is the law, the ARF is the blueprint everyone building to that law is actually implementing.

It is published openly on GitHub, actively versioned, releases arrive every few months as Member States and the Commission work through open questions, and covers:

• The wallet lifecycle, how a wallet gets set up, attested as secure, and recovered if the device is lost.
• PID, the baseline government-issued identity attributes every wallet must hold (its own Lexicon entry).
• (Q)EAA, (Qualified) Electronic Attestations of Attributes, the third-party credentials (diplomas, licenses, memberships) issued on top of the PID.
• The wire protocols, OpenID4VCI for issuance, OpenID4VP for presentation, and the device-binding / proof-of-possession mechanics that tie a credential to a specific wallet instance.
• The trust framework, who's allowed to issue a PID or (Q)EAA, and how a verifier checks that authorization, rooted in eIDAS's existing QTSP / EU Trusted List system.

Why this is the single most useful EU-regulation term to understand

Almost every other EU-regulation term in this Lexicon, EUDI Wallet, PID, QTSP, is a component the ARF assembles into one coherent system. Understanding the ARF is understanding the whole EU approach at once: a wallet holding standardized attribute sets, presented over standard protocols, trusted through a government-rooted certificate hierarchy. Once you have that picture, every other EU digital-identity term is just "which piece of the ARF is this."

Where Solidus genuinely lines up, and where it genuinely doesn't

Solidus tracks the ARF closely because Solidus's own KYC-credential stack happens to sit on several of the same open standards the ARF requires, not because Solidus set out to build an ARF-conformant system. The honest, itemized picture, shipped versus gap:

Shipped on testnet, overlapping with ARF requirements:

• OpenID4VCI (credential issuance) and OpenID4VP (credential presentation)
• SD-JWT VC as a selective-disclosure credential format
• W3C DID Core and VC Data Model 2.0 underneath all of it
• did:solidus itself is registered in the W3C DID Method Registry, a registry listing, not a W3C standard and not an ARF requirement, but relevant provenance for anyone checking whether the DID method behind these credentials is real

Not shipped, genuine gaps, not close calls:

• mdoc / ISO 18013-5, the CBOR-based credential format the ARF requires a PID to be issued in alongside SD-JWT VC, both formats are mandatory for a real PID, and Solidus has neither the issuance nor the verification side of the mdoc half.
• Wallet attestation and hardware-backed key binding: Solidus credentials today are bound to a holder DID, not to an attested wallet instance or a secure-element key.
• The QTSP-rooted trust framework, the ARF roots trust in Member-State-authorized certificate authorities on the EU Trusted List; Solidus roots trust in on-chain DID documents verified by its own BFT consensus. This is a genuinely different mechanism by design, not an unfinished version of the ARF's model, but it also means a Solidus credential has no standing inside the ARF's trust chain without a QTSP partner, which does not exist today.

Check it yourself

The full, dated, standard-by-standard mapping, every ✅ shipped, 🟡 partial, and ❌ not-shipped line, is public at docs.solidus.network/resources/eudi-arf-mapping. Read the ARF's own text directly at github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework. It is an actively-versioned living document (v2.9.0 as of May 2026), so check the repo for whatever the current release is before citing a version number anywhere.