EUDI Wallet – Electronic Attestations of Attributes move from draft to deployment

Why EAAs matter

Electronic Attestations of Attributes (EAAs) are the wallet-native way to convey trusted facts—“over 18,” “licensed physician,” “director at Company X”—with selective disclosure and on-device consent. They are the difference between copying documents across systems and presenting cryptographic proofs that can be revoked and status-checked. On 30 July 2025, the Commission published a new batch of implementing regulations in the Official Journal, including Implementing Regulation (EU) 2025/1566 which pin-down the reference standards for verifying identity and attributes when issuing qualified certificates and qualified EAAs. The rules enter into force 20 days after publication, giving issuers, verifiers and wallet vendors a citable legal base for production designs.

What the regulation actually fixes

Before July, pilots had to interpret drafts and working notes. With 2025/1566, the EU has set the reference standards that issuers must follow to be trusted across borders when binding an identity to attributes. That tightens the chain from identity proofing (KYC-grade checks) to attribute issuance (e.g., professional licence) and sets expectations for evidence retention and revocation/status services. The upshot is interoperability: a verifier in Frankfurt should be able to validate an attestation issued in Rome without custom glue code or policy guesswork.

Rules you’ll implement (or require in tenders)

Under the EU’s Architecture & Reference Framework, EAAs are carried as W3C Verifiable Credentials, presented via OpenID for Verifiable Presentations (OpenID4VP) and issued via OpenID for Verifiable Credential Issuance (OpenID4VCI)—with ISO/IEC 18013-5 and -7 covering mobile ID semantics and remote presentation. The EAA rules don’t replace those rails; they anchor them with legal weight and verification footprints. For buyers, that means asking vendors to show conformance to VC data models and OpenID4VC protocols, and to operate status endpointsthat scale. For systems in travel or banking, you marry these with sector rules (e.g., PSD2/SCA or IATA/ICAO DTCpatterns) to avoid parallel identity stacks. (Standards background inferred; the legal reference sets the verification baseline.)

Issuers: build once, issue many

Issuers—public authorities, professional bodies, regulated firms—should treat EAAs as products with lifecycles. Start with attribute catalogues: what you’ll issue, to whom, on what evidence, with what validity windows. Implement strong proofing aligned to the regulation’s reference standards and log the binding of identity → attribute in a way auditors can sample. Operate revocation/status services with clear SLA targets, because verifiers will depend on them at scale. The EAA path is also a route to privacy by design: publish data minimisation profiles so relying parties ask for the least revealing proof that meets their policy (e.g., “over-18” rather than date of birth). 

Verifiers: proofs not attributes

For verifiers—banks, airlines, platforms—the shift is from storing documents to validating proofs. That changes your risk and your interfaces. Build verifiers that can parse VC 2.0 structures, speak OpenID4VP, and check trust lists and status without leaking more data than necessary. Design for offline and degraded modes: if the issuer’s status endpoint is slow or down, your policy should define whether to fallback, queue, or deny. And make auditability a first-class feature: log proofs presented (not raw attributes), plus the trust anchors and the decision you took, so you can justify onboarding decisions without retaining personal data. 

Wallet vendors: the UX will make or break adoption

Users will judge wallets by clarity of consent and repeatability. Explain what’s being shared, with whom, and why—in the user’s language. Implement pair-wise identifiers where possible so verifiers can’t collate users across services. And because the business model remains a live debate (who pays, who benefits), design for ecosystem interop rather than sticky, vendor-specific add-ons. The wallets that win will be those that work everywhere, not those that trap verifiers in private APIs.

Where identity meets security (and PQC, soon)

As verifiers embrace EAAs, they inherit crypto-lifecycle responsibilities: key rotation, revocation hygiene, and eventually post-quantum agility as ETSI/ISO profiles evolve. The good news is that EAAs push you toward short-lived proofs and status checks that are easier to upgrade than long-lived PDFs and database snapshots. Map your crypto inventory now, so when PQC-ready profiles land in earnest, you aren’t discovering where the keys live while customers queue at the door. (Forward-looking inference aligned to ETSI/ISO evolution.)

The TQS takeaway

With 2025/1566 in the Official Journal and the Commission portal pointing to the final texts, projects can move from “pilot semantics” to production conformance. The job now is to surface this into procurement, architecture and UX: specify the rails, demand the status endpoints, and build journeys that ask for only what’s needed. Do that and you’ll cut fraud, cut friction and keep regulators on side as the Wallet shifts from promise to infrastructure.

Companion read: *ENISA’s Threat Landscape meets a patchy NIS2 rollout.”

Sources

1. EUR-Lex — Implementing Regulation (EU) 2025/1566 (identity & attribute verification reference standards). EUR-Lex
2. European Commission EUDI Wallet portal — overview of adopted implementing regulations (published 30 July 2025, in force +20 days). European Commission
3. Background on the EUDI legal framework and staged implementing acts (context/timelines). european-digital-identity-regulation.com+1