What is an EUDI Wallet Connector? A definition from the team that coined the term
Three years ago, the term “EUDI Wallet Connector” did not exist. Today it appears in the RFPs of European banks, in vendor decks and analyst notes. Identity verification providers, eID providers and signature platforms all claim to offer one. The problem: they mean different things. Some products called a connector request a PID from a single national wallet. Others get confused with a business wallet. This post gives a clear definition of what an EUDI Wallet Connector is, what it must cover, what it is not — and how to evaluate one.
Where the term EUDI Wallet Connector comes from
Our team has worked on digital identity since 2019, first inside Commerzbank. We led IDunion, one of Europe’s largest research consortia on digital identity, funded by the German government, and members of our team co-initiated the OpenID4VC protocol family that sits at the core of the Architecture and Reference Framework (ARF) today. When Lissi was spun out of Commerzbank in 2023, we focused on one application: the software an organization needs to interact with the wallets of its customers, employees and citizens.
That category of software had no name. We considered “gateway”, “adapter” and a few others. I remember the discussions well: “connector” won because it describes the job most precisely — it connects an organization’s existing IT to the wallets, in both directions. We built the product around the term and used it consistently. Today it is the industry’s term. And since we named the category, we feel a responsibility to define it properly.
What is an EUDI Wallet Connector?
An EUDI Wallet Connector is an infrastructure software component that enables an organization to interact with all European Digital Identity Wallets across all use cases — verifying identity data and attestations, issuing attestations, authenticating users and authorizing signatures and payments — through a single API, without implementing the eIDAS 2.0 protocol stack itself.
In terms of the European reference architecture (ARF), the connector is the technical implementation of the wallet-relying party side (requesting and verifying PID and attestations, strong customer authentication, authorization of qualified electronic signatures) and of the attestation-provider side (issuing electronic attestations of attributes). One nuance matters: the organization remains the relying party in its own name, with its own access and registration certificates. The connector is the tool of the organisation, not an intermediary in between.
A connector is an application. Whether it runs in the organization’s own data centre, as a managed service or as SaaS is a deployment choice — it changes who operates the component, not what the component is.
What a wallet connector must cover
Four things separate a connector from a wallet endpoint.
- All wallets, not one: A connector must interoperate with the wallets of all member states — today the implementations made available in national sandboxes and the EU Large-Scale Pilots, tomorrow the production wallets — continuously tested, with new wallets supported as soon as they appear. A component that talks to one national wallet is a national wallet connector. This is the criterion where the market thins out fastest, and it is easy to verify: ask for the interoperability test matrix.
- All use cases, not one: Verification of Person Identification Data for KYC, issuance and verification of EAAs, QEAAs and Pub-EAAs, strong customer authentication for logins and payments, and authorization of qualified electronic signatures — each in same-device and cross-device flows. A component that only requests a PID is a PID requester.
- The full trust infrastructure, not just the protocol call: OpenID4VCI and OpenID4VP are the visible part. Underneath sit access and registration certificates, the validation of issuers and wallets against trust frameworks (X.509 and OpenID Federation), status lists for revocation, wallet unit attestation, and the continuous tracking of ARF and implementing-act changes. This is the part most organizations underestimate — and the part that never stops.
- Configurable trust, not preset trust: The ecosystem is built on one principle: the party that requests and consumes identity data decides on its own terms what it deems acceptable. Which issuers to accept, which trust lists to rely on, which attributes to request, how to treat different jurisdictions — a bank answers these questions differently from an insurer, and a relying party in one member state differently from one in another. A connector must therefore make trust decisions configurable, not hard-code them. Predefined templates that help an organization get started are welcome; a fixed set of trust decisions that the organization cannot change are not. A component that connects to the wallets but takes these decisions for you technically works — it just does not support the spirit of the ecosystem.
.png)
One more note on intermediaries: Connectors are not only for relying parties integrating directly. Identity providers (IDVs), QTSPs, payment service providers and IT service providers offering wallet capabilities to their own clients are running a connector underneath. They usually add more requirements: full multi-tenancy with logically separated spaces per client, certificates and configuration per tenant, metrics per endpoint for billing and reporting, and white-labelling so every relying party acts in its own name. The principle of configurable trust applies here too: an intermediary may predefine how a PID request looks for its clients, but the end client should still be able to define what it deems trustworthy.
What a wallet connector is not
Not a single-endpoint add-on. Many identity verification providers and classical eID providers are extending existing products with a wallet endpoint — typically one wallet, one credential type, one flow. These are useful integrations. But they are a different category, and calling them connectors is the source of most confusion in RFPs today.
Not a business wallet. The European Commission’s proposal for a European Business Wallet describes something different: a wallet that holds, receives and presents credentials on behalf of an organization, towards other businesses and public authorities. A connector, by contrast, is the organization’s tool to interact with the wallets of natural persons. Different purpose, partly different standards. The two are related — an organization operating a connector today is well positioned for business wallet scenarios tomorrow — but a connector is not a business wallet by default.
How to choose one — the technology, and the partner behind it
Features decide whether a product is a connector. The partner decides whether you can build on it for the next ten years.
Four technical questions:
- Which wallets exactly — and how quickly are new member-state wallets supported as they appear in sandboxes and pilots?
- Which use cases beyond PID verification: credential issuance, SCA, QES?
- Does it cover the trust infrastructure — access and registration certificates, trust frameworks, status lists — and how are ARF and implementing-act changes kept up to date?
- Can you make your own trust decisions — accepted issuers, trust lists, rules per sector or jurisdiction — or are they preset?
If the answer to any of the technical questions is no, it may still be a good product. We just wouldn’t call it a connector.
Three partner questions:
- Who stands behind the software?
For regulated institutions, the ownership structure and capital base of an infrastructure provider is a third-party-risk question — and a sovereignty question.
- Do they only implement the ecosystem — or also help to shape it?
The ARF and its implementing acts are still moving. A vendor who only implements published specifications is always one revision behind; one who contributes to standardization and the Large-Scale Pilots sees changes coming, can tell you what they mean for your integration — and can guarantee compliance contractually.
- Do they offer the deployment model you need — or the one that suits them?
Some providers only offer SaaS, some only on-premise. Larger regulated institutions often need on-premise for production and a cloud sandbox for evaluation; intermediaries may need both models for different clients. A provider that forces you into a single model is making an architecture decision on your behalf.
A proposal, not a verdict
We named the category, and this is how we understand it: all wallets, all use cases, the complete trust infrastructure, and trust decisions that remain with the organization. It is the standard we hold our own product to — and we know that the ecosystem is still developing and that others may draw the lines differently. We would welcome feedback on this definition and hope it serves as a constructive contribution to the professional development of the EUDI Wallet ecosystem. For details on how we implement it, see our Lissi EUDI Wallet Connector page.
