Running the EUDIW reference wallet against our verifier

If you operate a service in the EU that needs to verify a citizen's identity — a bank, an insurer, a healthcare provider, a regulated SaaS — eIDAS 2.0 is coming for you. Every member state is building a sovereign digital identity wallet (EUDIW). Citizens will carry verified credentials on their phones. You'll be expected to accept those credentials as proof of identity, attributes, or qualifications.

The rollout runs through 2026. The question most teams we talk to are asking is: what do we do now?

The short answer: set up an OpenID4VP verifier against the reference wallets, ship it in staging, and be ready for production when your member state's wallet goes live.

Here's how that works with the Thoryn eIDAS verifier.

What the reference wallets give you

The EUDIW ecosystem publishes reference implementations of both the wallet and the verifier. The most actively maintained are the EU reference wallet and the NL reference wallet — the Netherlands is early in the rollout. They speak OpenID4VP for presentation, support SD-JWT VC and mdoc credential formats, and conform to the ARF (Architecture and Reference Framework).

Your staging integration doesn't need real issued credentials — the reference wallets come pre-seeded with test credentials (Personal ID, driving licence, mobile driving licence). You can verify end-to-end without waiting for your member state's PID issuance to go live.

What the flow looks like

Our eIDAS verifier implements the standard 5-step OpenID4VP flow:

1. User scans a QR at your relying party — or clicks a deep link if they're on mobile.
2. Wallet fetches the request from the verifier, which includes a presentation definition describing which credentials and claims you need.
3. User consents in the wallet UI. Only the disclosed claims are included in the response.
4. Verifier receives a signed VP token via the response_uri you configured.
5. Verifier validates the signature, checks the Trust Registry, and returns verified claims to your application.

A minimal presentation definition for proof-of-identity:

{
  "id": "onboarding",
  "input_descriptors": [
    {
      "id": "pid",
      "format": { "vc+sd-jwt": { "sd-jwt_alg_values": ["ES256"] } },
      "constraints": {
        "fields": [
          { "path": ["$.given_name"] },
          { "path": ["$.family_name"] },
          { "path": ["$.birth_date"] },
          { "path": ["$.document_number"] }
        ],
        "limit_disclosure": "required"
      }
    }
  ]
}

limit_disclosure: required is the important line. It tells the wallet to only include the listed fields — no over-disclosure. Anything not listed is cryptographically out of reach.

What happens at runtime

When the wallet submits the VP token, the Thoryn verifier:

• Validates the JWT signature against the issuer's JWKS
• Looks up the issuer in the Trust Registry to confirm they are trusted for this credential type
• Enforces limit_disclosure — if the wallet includes extra disclosures, the presentation is rejected
• Checks holder binding — the VP token signature must match the key committed in the credential
• Returns verified claims to your application via webhook

If any step fails, you get a machine-readable reason code: untrusted_issuer, limit_disclosure_violated, holder_binding_failed, and so on. The reasons are logged alongside the attempt.

ARF compliance — what we track

ARF moves. Revisions are published roughly quarterly, and profile changes land without warning. The Thoryn verifier tracks ARF revision by revision:

• Conformant relying party profile (the set of OpenID4VP features we implement)
• Trusted issuer registry with revocation — live trust decisions, not static lists
• Selective disclosure enforcement — via SD-JWT, enforced at the protocol level
• Transparent audit trail on every verification, with machine-readable reason codes

Your integration stays the same when ARF ships a new revision. You call the same verifier endpoint with the same presentation definition and get the same claim shape back. We handle the protocol shift internally.

What you can do this quarter

• Stand up the Thoryn verifier (we can run it for you, or you can self-host)
• Write your presentation definitions for the flows you care about: onboarding, KYC refresh, age gates, licence verification
• Test against the NL reference wallet and the EU reference wallet
• Wire the verifier's webhook into your onboarding or customer data flows
• Run your security review once, now, instead of once per ARF revision

When your member state's wallet goes live, you flip a config — same verifier endpoint, real wallet instead of reference — and you're in production.

Get started

The eIDAS 2.0 product page has the full protocol details. Request access to spin up a sandbox verifier and run your first presentation against the NL reference wallet. Most teams are getting their first verified claim back within a day.