Skip to content
A high level look into SSI and the current projects including the EU Data Wallet

A high level look into SSI and the current projects including the EU Data Wallet

  • Home /
  • Blog Posts /
  • A high level look into SSI and the current projects including the EU Data Wallet
Table of Contents

Why this post

Self-sovereign identity (SSI) and its adjacent ecosystems evolved fast over the last 24 months. This post summarises where the core standards sit, how the European Digital Identity (EUDI) Wallet programme frames the stack, and what’s actually shipping across networks and vendors—using current, primary sources throughout. This post is a bit more technical in nature as implementation gets closer. If you need more details or background please read the deeper dive version of this post.

Where the standards are now

  • W3C VCDM remains the general data model for verifiable credentials. In parallel, selective disclosure JWTs are maturing rapidly in the IETF:
    • The core SD‑JWT draft was submitted to the IESG for publication on 2025‑03‑03, reflecting stability in the design for selective disclosure over JWTs. Source: IETF Datatracker.
    • The SD‑JWT VC draft adds metadata for credential semantics, integrity and rendering (simple and svg_template), and claim path conventions—useful for wallet UX and verifier display. Source: SD‑JWT‑VC draft.

How the EU frames the wallet stack (ARF v2.4.0)

The EUDI Wallet Architecture and Reference Framework (ARF) v2.4.0 profiles multiple credential technologies with clear modality splits:

  • Remote flows use OpenID for Verifiable Presentations (OpenID4VP) and Credential Issuance (OpenID4VCI).
  • Proximity flows profile ISO/IEC 18013‑5/7 (mDL/mdoc) with HAIP.
  • Credentials are profiled around SD‑JWT VC for selective disclosure in the current ARF line.
  • Trust is rooted in PKI-based Trusted Lists and Trust Registries—not blockchains—and qualified e-signatures (QES) are required “by default and free of charge” for legal effects.
  • Revocation is handled via status lists (e.g., W3C StatusList 2021) in ARF contexts, rather than accumulator proofs.

References: EC EUDI implementation pages and the ARF 2.4.0 docs.

Large Scale Pilots: what finished and what’s next

Four initial LSPs—EWC, POTENTIAL, NOBID, and DC4EU—concluded their grant cycles in 2025. Wrap-ups and deliverables confirm end-to-end wallet journeys (PID, attributes, payments, signatures) and offer detailed UX/accessibility findings (for example, NOBID’s multi-country user testing). Two new LSPs are starting next:

  • APTITUDE — mobility, transport, and banking, including travel documents and strong authentication for payments.
  • WE BUILD — business and payments (B2B/B2G/B2C), with emphasis on legal representation and data sharing.

References: EC pages; BiometricUpdate coverage (Sept 2025); NOBID’s final wrap-up post.

Privacy tech in practice: SD‑JWT and AnonCreds

  • SD‑JWT/VC provides selective disclosure with JWT tooling and aligns with ARF remote and rendering guidance.
  • Hyperledger AnonCreds offers advanced ZKP features (blinded issuer signatures, link secret holder binding, predicate proofs, and non‑correlating revocation proofs). It’s ledger‑agnostic today, though note: ARF’s current revocation profile centers on status lists, not accumulator schemes.

References: IETF SD‑JWT(-VC) drafts; Hyperledger AnonCreds spec and wiki.

Networks and registries: Sovrin and ION

  • Sovrin: The Sovrin Foundation announced that MainNet shutdown in March, 2025. Sovrin’s legacy? AnonCreds lives on as an open specification under Hyperledger with ledger‑agnostic implementations. So if you still anchor identifiers or schemas there it is still possible.
  • ION: A permissionless DID network built on Bitcoin via the Sidetree protocol—no new token, no extra consensus—designed for high‑scale DID ops. Useful when you need decentralised identifier anchoring decoupled from PKI trust lists. Sources: DIF ION overview and GitHub.

Vendors and projects: what’s real and recent

  • Microsoft Entra Verified ID: FaceCheck became generally available on 2024‑08‑12; Entra logs also document revocation via status lists and wallet library updates. Source: Entra “What’s New.”
  • Trinsic: Pivoted from general‑purpose VC infra to an Identity Acceptance Network; public materials reference 500M+ pre‑verified user coverage across providers. Sources: Trinsic site and CEO posts.
  • SpruceID: Government‑scale deployments (e.g., California DMV Wallet) and extensive standards work. Sources: SpruceID site and blog.
  • walt.id: Open‑source wallet/identity infrastructure supporting SD‑JWT, W3C VC, OID4VC, HAIP, and multi‑ecosystem plugins. Source: walt.id.
  • Dock ↔ cheqd alliance and token merger: In early 2025 both announced an alliance, with token/blockchain merger plans approved—consolidating SSI capabilities and simplifying integrations. Sources: Dock and cheqd announcements.

Note: Product and capability names move as the ecosystem is fluid as shown by Sovrin closing.

Practical guidance if you’re building now

  1. Choose by context and mandates
  • EU public services and regulated sectors: Follow ARF v2.4.0. Prefer SD‑JWT VC for remote with OpenID4VP/VCI, and ISO 18013‑5/7 + HAIP for proximity. Plan for QES flows and PKI trust lists.
  • Global private sector: SD‑JWT VC and W3C VC JWT are the lowest‑friction options; evaluate mdoc when proximity/offline is required.
  1. Plan for revocation and status
  • Use StatusList 2021 (or equivalent) where ARF-like semantics apply. If you need non‑linkable revocation proofs, scope AnonCreds carefully and consider bridges to status lists for verifier compatibility.
  1. Mitigate linkability early
  • Minimise stable identifiers; prefer per‑interaction DIDs/keys; use SD‑JWT selective disclosure and align with ARF guidance on device/user binding and re‑issuance policies.
  1. Wallet UX is make‑or‑break
  • LSP findings show that flow clarity, assistive tech support, and plain language matter as much as crypto. Budget for usability testing with diverse users.
  1. Avoid brittle dependencies
  • Don’t bind yourself to a single ledger or DID method unless mandated. Prefer registries you can swap and trust anchors you can rotate.

References (selected)

Tags :

Related Posts

Privacy by Design - A look back and a look forward

Privacy by Design - A look back and a look forward

From X.400 to SMTP: The Story of a Simpler Takeover In the early days of digital communication, there were two competing visions for email. One was the complex, feature-rich, and highly structured X.400 standard, championed by the International Telecommunication Union (ITU). The other was the simpler, more flexible Simple Mail Transfer Protocol (SMTP), which emerged from the internet’s open and collaborative development. Ultimately, SMTP and complementary protocols like PGP (Pretty Good Privacy) prevailed due to their simplicity, adaptability, and the decentralized nature of the internet.

Read more
Privacy by Design & the EU Data Wallet

Privacy by Design & the EU Data Wallet

From X.400 to SD-JWT: A Privacy Evolution in the EU Digital Identity Wallet The landscape of digital identity is constantly evolving, and with the advent of the EU Digital Identity (EUDI) Wallet, we’re seeing a significant leap towards user-centric and privacy-respecting systems. For those of us with a longer history in digital communication, the term “X.400” might ring a bell. While seemingly disparate, comparing the foundational concepts behind X.400 and the modern SD-JWT (Selective Disclosure for JSON Web Tokens) within the context of the EUDI Wallet highlights a remarkable evolution, particularly in how we handle and control personal data.

Read more
Proof of Process - Self-Sovereign Identity

Proof of Process - Self-Sovereign Identity

Your Digital Fingerprint: How “Proof of Process” Can Revolutionize Self-Sovereign Identity In our increasingly digital world, proving who you are online is a constant, cumbersome battle. We hand over sensitive documents, answer security questions, and rely on centralized authorities to verify our identities – often leading to fragmented data, privacy concerns, and vulnerability to breaches. But what if there was a way to “self-prove” your identity, without constantly exposing your personal data?

Read more