A grounded architecture guide for teams implementing or integrating with the European Digital Identity Wallet under the amended eIDAS framework.
Covers ARF roles, wallet units, PID and attribute attestations, relying-party registration, trust anchors, access certificates, wallet-unit attestations, selective disclosure, logs, pseudonyms, and security controls.
Structured answer sets in this page tree.
Cited legal and guidance references.
The EUDI Wallet is not just a login app. Under the amended eIDAS framework it is an electronic identification means that lets users store, manage, validate, and present person identification data and electronic attestations of attributes, interact with relying parties, and create qualified electronic signatures or seals where supported. The Commission's Architecture and Reference Framework (ARF) is informative rather than a substitute for the legal acts, but it is the clearest technical map of the wallet ecosystem and the interactions implementers need to design.
Treat the binding baseline and the ARF as different layers. Regulation (EU) 2024/1183 amends eIDAS and defines the EUDI Wallet, the Article 5a wallet functions, relying-party authentication, certification, security breach handling, and supervision. The ARF describes the ecosystem architecture, roles, components, trust model, presentation flows, attestation formats, certification context, and risk-management concepts used to implement that framework.
A technical architecture record should therefore separate legal requirements from implementation choices. The legal layer identifies the role and obligation; the architecture layer explains how wallet units, providers, relying parties, attestations, certificates, and trust lists interact.
The architecture should distinguish the provider's wallet solution from the individual user's wallet unit. Implementing Regulation (EU) 2024/2979 describes a wallet solution as the combination of software, hardware, services, settings, and configurations needed to operate the wallet. A wallet unit is the unique configuration for an individual wallet user, including the wallet instance and security components.
The wallet instance is the application or environment the user interacts with. Critical assets are protected through wallet secure cryptographic applications (WSCAs) linked to wallet secure cryptographic devices (WSCDs). That distinction matters because PID and attestation issuers must be able to verify they are issuing to a genuine wallet unit, and relying parties need a way to validate wallet-unit authenticity and status.
Person identification data (PID) is the identity dataset associated with the wallet under the relevant eID scheme. Electronic attestations of attributes (EAAs) are separate attestations that authenticate attributes such as a characteristic, right, permission, qualification, or other attribute. The amended eIDAS text defines both concepts, while Implementing Regulation (EU) 2024/2977 sets rules for issuing PID and EAAs to wallet units.
The architecture must support issuance, storage, presentation, validation, revocation, and privacy-preserving use of PID and attestations. It should not collapse PID, qualified electronic attestations of attributes, public-sector authentic-source attestations, and non-qualified attestations into one generic credential type, because the issuer, legal effect, verification source, and revocation model can differ.
A relying party is the service provider that relies on the wallet, electronic identification, or a trust service. In wallet architecture, the relying-party integration is security-critical because it determines what data is requested, whether the relying party is registered for that purpose, how the relying party authenticates to the wallet, and what the user sees before approving disclosure.
The ARF trust model is built around mutual authentication, registration, revocation, authorization, trusted lists or lists of trusted entities, access certificate authorities, and wallet-unit attestations. A relying-party request should therefore be checked against the relying party's registered intended use, access certificate, requested attributes, embedded disclosure policy, and the wallet user's approval.
The amended eIDAS framework requires common protocols and interfaces for issuance, relying-party requests and validation, sharing and presentation online and offline, wallet-to-wallet interaction, relying-party authentication, wallet authenticity validation, erasure requests, suspicious-request reporting, and qualified electronic signatures or seals. The ARF references technical building blocks such as ISO/IEC 18013-5 mobile-document flows, SD-JWT VC, OpenID4VCI, OpenID4VP, and related OpenID profiles, but an implementation should verify the current adopted implementing acts and conformance specifications before freezing a protocol stack.
Certificates appear in several places. Wallet-unit attestations carry keys for validating a wallet unit. Wallet-relying party access certificates identify relying parties and certain providers to wallet units. Qualified certificates, qualified signature creation devices, and signature creation applications are separate trust-service elements when the wallet is used to create qualified electronic signatures or seals.
Privacy is a design constraint, not a later notice. eIDAS requires user control, selective disclosure, local encrypted pseudonyms, transaction visibility, and separation of wallet-service personal data from other provider data. Implementing Regulation (EU) 2024/2979 adds privacy-oriented requirements around wallet-unit attestations, embedded disclosure policies, transaction logs, pseudonym generation, portability, and wallet-unit revocation.
Security controls should be mapped to the wallet component they protect and the trust decision they support. The ARF risk discussion highlights impersonation, key compromise, unauthorized attestation issuance, overbroad relying-party requests, relying-party linkability, and attestation-provider linkability as architecture risks that need concrete mitigations.
No. The ARF is an informative architecture and reference framework. It is useful for designing roles, components, interfaces, and trust flows, but binding requirements come from eIDAS as amended by Regulation (EU) 2024/1183, implementing regulations, and adopted standards or certification schemes.
Separate the wallet solution from each wallet unit. The solution is the provider's overall software, hardware, services, settings, and configurations. A wallet unit is the unique setup for one user, including wallet instances, WSCAs, WSCDs, wallet-unit attestations, PID, attestations, logs, and user-controlled presentation behavior.
It should be registered for the wallet use case, identify itself with the supported authentication mechanism or access certificate, request only the attributes tied to its registered intended use, and give the wallet enough information to inform the user before selective disclosure.
Use this guide to review wallet-unit boundaries, PID and attestation issuance, relying-party registration, certificate validation, privacy controls, and security evidence before building or procuring an EUDI Wallet integration.
Ask source-linked questions about EUDI Wallet roles, ARF architecture, PID, attestations, relying parties, and trust-service evidence.
Review an EUDI Wallet integration plan against the ARF, implementing regulations, trust model, certificate checks, and privacy controls.
"wallet-relying party access certificate"
"data protection by design and by default"
"Relying Party linkability"
"Not request any extra user data than what was specified during registration."
"full control over their data"