~/en/articles/eidas-grenzueberschreitende-identitaetspruefung

eIDAS 2.0: Cross-border identity verification for relying parties

AI-generated, human-reviewed

07/10/2026 · eudi-wallet

A law firm in Berlin needs to identify a client in Kraków. A bank in Munich onboards a customer from Helsinki. Today that means video ident with the right country coverage and manual review. With eIDAS 2.0, cross-border identity verification becomes the default case. The Polish wallet speaks the same protocol as Germany’s d-you, and the verifying organisation registers exactly once.

We build id-call.eu, a verified video call based on the EUDI Wallet, and are a launch partner of the German wallet. The analysis below comes from that work.

Register once, verify everywhere: Art. 5b eIDAS 2.0

“Passporting” is a term from financial supervision, and Regulation (EU) 2024/1183 does not use it. The principle still fits. Art. 5b requires every relying party to register in the member state where it is established. As part of that registration it declares what it uses the wallet for and which attributes it intends to request. Implementing Regulation (EU) 2025/848 fills in the details: national registers, verification by a registrar, publicly accessible entries.

This works across borders because trust is attached to the registration, not to where the user lives. A German company receives an access certificate through its German registration. A Finnish wallet checks that certificate against the trust anchors published by the Commission. No Finnish approval is required. In the other direction, the German backend validates the Finnish PID against Finland’s notified PID providers.

An honest reading comes with two caveats:

  • Registration binds you to a purpose. It is not a blank cheque. If a relying party requests more attributes than it registered, the wallet may flag or refuse the request.
  • Sector law still applies. Whether a notary, a bank or a medical practice may rely on wallet identification for a specific transaction is decided by anti-money-laundering rules, notarial law or professional regulations, not by eIDAS.

The German wallet launches on 2 January 2027; mandatory acceptance for regulated sectors is expected from the end of 2027 (details in our overview of EUDI Wallet integration).

The engine room: what a pan-European verifier needs

Federated trust instead of bilateral contracts

A verifier trusts lists, not individual partners. The European Commission maintains the List of Trusted Lists (LOTL), which points to the national trusted lists. The wallet ecosystem adds lists of its own: PID providers, wallet providers, and certificate authorities for access certificates. For the backend this means:

  • Load trust anchors automatically, verify the list signatures, and validate certificate chains up to the anchor.
  • Monitor freshness. EUDIPLO, the verifier we use, stamps a configured trust list with a 30-day validity. After that it rejects every presentation. The wallet shows only a generic error, and only the log names the cause. Failing closed is the right behaviour, but it needs a cron job and monitoring.

Two formats: SD-JWT VC and mdoc

The Architecture and Reference Framework (ARF) allows two credential formats. A verifier that handles only one of them will not cover every wallet and every credential:

  • SD-JWT VC (dc+sd-jwt): JSON-based, with selective disclosure through hashed disclosures and device binding through a key-binding JWT. Common for attribute attestations.
  • ISO mdoc (mso_mdoc, ISO/IEC 18013-5): CBOR-based, with a signed Mobile Security Object. It comes from the mobile driving licence and is mandatory for in-person checks.

In id-call.eu we handle this with a format-neutral profile layer. Each profile describes one credential in exactly one format, with its own claim paths. The request offers both formats as alternatives, and the wallet presents whichever it holds. A normalisation step maps both responses to one shared vocabulary: the application sees family_name, not an mdoc namespace.

OpenID4VP as the interface

OpenID for Verifiable Presentations (OpenID4VP) connects the web application and the wallet. The relying party uses a DCQL query to state which credentials and attributes it needs, signs the request with its access certificate, and receives the presentation back encrypted. You do not need to write the cryptography yourself. We run EUDIPLO, an open-source verifier from the OpenWallet Foundation, as a separate service. The application receives the verified result through an authenticated webhook.

Case in point: id-call.eu binds identity to the channel

A valid wallet presentation proves that a genuine wallet took part. It does not prove that this wallet sits at the other end of this video call. Relay attacks exploit that gap: a real person’s identification is passed through while someone else is on camera, possibly a deepfake.

Our approach ties the two layers together cryptographically:

  1. The client generates the DTLS certificate for the WebRTC connection before it identifies itself, and reports the certificate’s SHA-256 fingerprint.
  2. The fingerprint goes into the OpenID4VP request as transaction_data.
  3. The wallet signs a hash of that data inside the key-binding JWT.
  4. The verifier checks the hash. The signalling server compares the fingerprint with the one negotiated in the SDP, and the other party receives it to run its own comparison.

A presentation that is intercepted and replayed elsewhere is detected, because it belongs to a different DTLS key. This protects remote consultations with notaries, banks or doctors against man-in-the-middle and relay attacks, whichever country the wallet comes from.

The current status is part of the picture:

  • The binding is built but switched off by default. OpenID4VP requires wallets to reject transaction_data types they do not know. The SPRIND test wallet does that with our type, correctly. The binding can go live once wallets support a type for it.
  • It only works with SD-JWT. EUDIPLO validates transaction_data only on the SD-JWT path and would silently ignore the field for mdoc. That is why id-call.eu enables the binding only when every offered profile is SD-JWT. Claiming no binding is better than claiming one that nobody checks.
  • It does not protect against our own server. A fully compromised operator can forge both the result and what is displayed. The defensible claim is “bound to the channel”, not “end-to-end secured against the operator”.

What to do now

2027 is not the year to start integration projects. It is the year they have to be finished.

  • Prepare your registration. Define your use cases and the attributes you need, as narrowly as the business allows. That is data minimisation and your future register entry in one step.
  • Test in a sandbox. Set up a verifier, run OpenID4VP against test wallets, and request both formats.
  • Plan for running the trust layer. List updates, certificate rotation and monitoring are operational tasks, not project tasks.
  • Keep the verifier separate from the application. The ARF will keep releasing new versions. If the cryptography lives in a replaceable service, an update means swapping a container, not reworking your application.

Key takeaways

  • Art. 5b eIDAS 2.0 and Implementing Regulation 2025/848 make a single registration in your home member state the basis for identity verification across all 27 member states.
  • A pan-European verifier needs automated trust-list management, SD-JWT VC and mdoc, and OpenID4VP as its interface.
  • Channel binding via transaction_data ties an identity to a specific WebRTC connection. Today it still depends on wallet support and on the SD-JWT format.

Our EUDI Verified Call case study shows how this looks in a running product. If you are planning your own relying-party integration, talk to us about EUDI Wallet integration.