The EU Digital Identity Wallet has moved from policy slideware to a hard engineering deadline. Under eIDAS 2.0 — Regulation (EU) 2024/1183, which amended the original 2014 electronic identification and trust services rules — every Member State must make at least one certified wallet available to its citizens and residents, and large online platforms and regulated sectors must be ready to accept it. For software teams the important shift is not the political headline but the specification stack underneath it: the Architecture and Reference Framework (ARF), a defined set of credential formats, and two OpenID protocols that together decide how identity data crosses the wire.
For companies in Tunisia and across North Africa, this is not a distant European story. Any team that builds onboarding, know-your-customer, e-commerce checkout, or HR software for EU clients will soon be asked to act as a relying party that verifies wallet presentations, and sometimes as an issuer of attestations. Getting the architecture right in 2026 is the difference between a wallet integration that ships in a sprint and a retrofit that fights your existing identity plumbing for a year. This post walks the concrete building blocks.
From eIDAS to eIDAS 2.0: what actually changed
The first eIDAS regulation gave Europe qualified signatures, seals, and trusted lists, but it left digital identity fragmented and largely government-to-citizen. eIDAS 2.0 reframes the problem around a user-controlled wallet that holds credentials and presents them selectively.
- ▸A wallet for everyone: Member States must offer a European Digital Identity Wallet at Level of Assurance high, free for natural persons.
- ▸Mandatory acceptance: Very large online platforms and sectors such as banking, telecom, and public services must accept the wallet when strong user authentication is required.
- ▸Attestations, not just identity: Beyond core Person Identification Data (PID), the wallet carries Electronic Attestations of Attributes (EAA), including qualified (QEAA) and public-body (PuB-EAA) variants — diplomas, licences, memberships, entitlements.
- ▸A published blueprint: The ARF, maintained openly by the European Commission, is the source of truth for formats, flows, and trust — read it before you design anything.
The credential formats you will actually ship
There is no single wallet credential format, and pretending otherwise is the most common early design mistake. Two families dominate, and a mature integration handles both.
- ▸SD-JWT VC: Selective Disclosure JSON Web Token Verifiable Credentials, an IETF specification. Claims are individually salted and hashed so the holder can reveal a subset while the issuer signature still verifies. It is JSON-native, friendly to web stacks, and the natural fit for attribute attestations.
- ▸ISO/IEC 18013-5 mdoc: The mobile document format born from the mobile driving licence (mDL). It uses CBOR encoding and a Mobile Security Object, and it excels at in-person and offline presentation over Bluetooth or NFC.
- ▸W3C Verifiable Credentials: The Verifiable Credentials Data Model remains relevant as a conceptual and interoperability layer, but for EUDI conformance your energy belongs on SD-JWT VC and mdoc.
The practical takeaway: model your data so the same underlying attribute can be expressed in either envelope, and never assume a verifier speaks only one dialect.
Selective disclosure and the privacy math
The reason the wallet matters for privacy engineering is selective disclosure. A bar needs to know a customer is over eighteen, not their birth date, address, and document number. eIDAS 2.0 pushes this data-minimization principle into the protocol itself.
- ▸Salted-hash disclosure: In SD-JWT VC the issuer commits to hashed claims; the holder later reveals only the salt-and-value pairs a verifier asks for, and everything else stays cryptographically hidden.
- ▸Predicate and range proofs: The over-eighteen check is a predicate, and the ARF roadmap treats zero-knowledge techniques as the path to answering yes-or-no questions without exposing the underlying value.
- ▸Unlinkability is unfinished: Basic selective disclosure still lets colluding verifiers correlate presentations through reused signatures. Batch issuance and emerging zero-knowledge schemes are how the ecosystem is working toward genuine unlinkability — track this, because it is where the standards are still moving.
The protocol layer: OpenID4VCI and OpenID4VP
Two OpenID for Verifiable Credentials specifications carry the traffic, and they are the interfaces your services implement.
- ▸OpenID4VCI (issuance): How an issuer hands a credential to a wallet — credential offer, authorization, token exchange, and the credential endpoint. This is what a Tunisian diploma issuer or an EU bank uses to push an attestation into a citizen wallet.
- ▸OpenID4VP (presentation): How a relying party requests and receives a proof. You express what you need as a query, the wallet responds with a verifiable presentation, and you validate signatures against the issuer's trust anchor.
- ▸Device and cross-device flows: Same-device redirects and cross-device flows using a scanned code are both in scope; design your user experience for a phone that is either the browser or a separate authenticator.
Trust: registries, providers, and qualified certificates
A signature only means something if you can trace it to an accountable party, and this trust fabric is where integrations quietly fail.
- ▸Trusted lists and registries: Issuers, wallet providers, and relying parties are enrolled in registries that let a verifier decide whether to trust an attestation's origin.
- ▸PID Providers: State-designated issuers of core identity data at Level of Assurance high, anchored in national identity infrastructure.
- ▸Relying-party registration: Verifiers must register and declare the attributes they intend to request, which is a deliberate check against over-asking for data.
- ▸Qualified certificates: Qualified electronic signatures, seals, and website authentication certificates (QWACs) remain the backbone that binds cryptographic keys to legal identities.
A migration roadmap for engineering teams
Treat wallet readiness as a program, not a feature flag. A workable sequence for a 2026 delivery:
1. Map your identity touchpoints: List every place you collect identity or attributes today — signup, KYC, age gates, credential uploads — and mark which become wallet presentations. 2. Pick your role: Decide per touchpoint whether you are a verifier, an issuer, or both, because the two use different protocols. 3. Prototype against the ARF: Stand up a reference wallet and verifier from the Large-Scale Pilots ecosystem and exchange a real SD-JWT VC before you touch production code. 4. Abstract the credential layer: Put a format-agnostic adapter between your application and the wire so SD-JWT VC and mdoc are pluggable, not hard-coded. 5. Wire in trust management: Build trusted-list resolution and revocation checking as first-class services, not afterthoughts. 6. Minimize your requests: Configure presentation requests to ask for the narrowest attribute set, and document the legal basis for each field. 7. Plan for graceful fallback: Keep a non-wallet path for users without one, and instrument adoption so you can retire it on evidence.
What to do next
If you ship software for European users from a North African base, three moves pay off immediately. First, assign an owner to read the ARF and subscribe to its changes, because it is a living document and drift is real. Second, build a small internal proof of concept that issues and verifies a selectively disclosed credential, so your team learns the cryptography on low stakes. Third, revisit your data model now: attributes you can express as verifiable claims are attributes you will not have to store, and every field you avoid holding is a field you never have to defend in a breach.
Looking ahead, the wallet is the leading edge of a broader shift from collecting identity data to verifying claims about it, and the teams that internalize that inversion will build leaner, more trustworthy systems. North African software firms are unusually well placed to lead here: they sit close to Europe in time zone and standards, they carry deep talent in cryptography and backend engineering, and they can offer EU clients wallet-ready integrations without the cost structure of onshore consultancies. The specifications are stabilizing through 2026, the reference implementations are open, and the regulatory pull is now certain — the window to build fluency before it becomes table stakes is open, but it is closing.