eIDAS 2.0 EU Digital Identity Wallet 2026: Complete Developer Guide for Relying Parties

Post #1 in the sota.io EU Digital Identity & eIDAS 2.0 Developer Series

The EU Digital Identity Wallet (EUDIW) goes live in December 2026. Every Member State must offer citizens a government-issued digital identity wallet — and a growing list of service providers must accept it. If your SaaS platform provides financial services, processes identity verification, or falls under the "large online platform" category, you are likely a Relying Party under Regulation (EU) 2024/1183.

This guide explains what you need to build, which protocol stack to implement, and how to prepare your integration before the December 31, 2026 deadline.

What is eIDAS 2.0?

Regulation (EU) 2024/1183 — published in the Official Journal on April 30, 2024 — significantly amends the original eIDAS Regulation (EU) No 910/2014. The headline change is the EU Digital Identity Wallet: a standardised, government-issued mobile application that lets EU citizens and residents store and selectively disclose verified identity attributes (age, address, professional qualifications, driving licence) to any service that accepts it.

Key points:

• Member State obligation: Each EU Member State must provide at least one free EUDIW to all citizens and residents who request one, with full functionality available by December 31, 2026.
• Interoperability: All wallets must conform to the Architecture Reference Framework (ARF) published by the EU Commission. The current version is ARF v2.4.0 (January 2026).
• Portability: Citizens own their data; they decide what attributes to share with each service and can revoke access at any time.
• Trust chain: Only Qualified Trust Service Providers (QTSPs) can issue credentials into wallets. Member States certify their own wallet implementations through national supervisory bodies.

Who Must Accept the EUDIW?

Regulation (EU) 2024/1183 creates a mandatory acceptance obligation for specific categories of service providers. These are known as Relying Parties (RPs) — any service that requests attribute verification from a wallet. The mandatory acceptance obligation applies to:

If your SaaS is not in these categories, voluntary acceptance is possible and commercially valuable — earlier integration = competitive differentiation as EUDIW adoption scales post-2026.

The EUDIW Technical Protocol Stack

The ARF v2.4.0 defines the complete technical architecture. As a Relying Party, you need to implement:

OpenID for Verifiable Presentations (OpenID4VP)

OpenID4VP (IETF draft) is the protocol used when a Relying Party requests credentials from a wallet. The flow:

1. RP sends a Presentation Request — a signed JSON object specifying which attributes to request (e.g. eu.europa.ec.eudi.pid.1 for the Person Identification Data)
2. Wallet presents a Verifiable Presentation — signed by the wallet and cryptographically bound to the holder
3. RP verifies the presentation — checks signatures against the EUDIW Trust Framework (issuer certificates from national QTSPs)

The protocol supports both cross-device flows (QR code on desktop, wallet on mobile) and same-device flows (deep link into the wallet app).

Relying Party                 User Wallet
     |                             |
     |--- Authorisation Request -->|
     |    (openid4vp://)           |
     |                             |
     |<-- Authorisation Response --|
     |    (VP Token + ID Token)    |
     |                             |
     |--- Verify VP Token -------> Trust Framework
     |<--- OK / Reject ------------|

SD-JWT (Selective Disclosure JWT)

Credentials in EUDIW wallets are encoded as SD-JWT (Selective Disclosure JWT, draft-ietf-oauth-selective-disclosure-jwt). This format allows holders to share only the attributes they choose — for example, proving they are over 18 without revealing their exact birthdate.

An SD-JWT has three parts:

• Issuer-signed JWT — contains hashes of all disclosable claims, signed by the QTSP that issued the credential
• Disclosures — the actual claim values, selectively included by the holder when presenting
• Key Binding JWT — proves the presentation was created by the legitimate holder (wallet private key)

As a Relying Party, you verify:

1. Issuer signature (trusted QTSP certificate chain)
2. Disclosed claims match the requested attributes
3. Key binding JWT is valid and fresh (replay protection)

OpenID for Verifiable Credential Issuance (OpenID4VCI)

OpenID4VCI is used when a Credential Issuer (a QTSP or public body) pushes a credential into a wallet. As a Relying Party, you typically do not implement OID4VCI — unless you are also issuing credentials (e.g. a professional qualification body issuing a lawyer's licence into wallets). Most SaaS platforms only implement OID4VP.

The Person Identification Data (PID) Credential

The baseline credential every EUDIW will contain is the Person Identification Data (PID) — the digital equivalent of a national identity document. The PID credential namespace is eu.europa.ec.eudi.pid.1 and contains:

{
  "family_name": "Müller",
  "given_name": "Anna",
  "birth_date": "1990-05-15",
  "age_over_18": true,
  "age_over_21": true,
  "nationality": "DE",
  "resident_country": "DE",
  "resident_city": "Berlin",
  "portrait": "<base64 photo>",
  "issuance_date": "2026-01-15",
  "expiry_date": "2031-01-15"
}

All fields are selectively disclosable via SD-JWT. Your Presentation Request specifies exactly which attributes you need:

• Identity verification only: request family_name, given_name, birth_date
• Age gating: request only age_over_18 (no birthdate disclosed)
• EU residency check: request resident_country, nationality
• Full KYC: request all PID fields plus optional mDL (mobile Driving Licence) credential

Registering as a Relying Party

The EUDIW Trust Framework requires Relying Parties to register in a national RP Registry maintained by each Member State's supervisory authority. Registration is currently being standardised; the expected process is:

1. Generate an RP key pair — EC P-256 or RSA-2048 minimum; EC P-256 recommended
2. Create an RP metadata document — OpenID4VP client metadata, your DID or X.509 certificate, requested credential types, redirect URIs
3. Submit to national registry — the precise submission process varies by Member State (pilot registries are running in Germany via BSI and in the Netherlands via RVO)
4. Obtain a Relying Party certificate — issued by the national supervisory body, embedded in your Presentation Requests
5. Publish your RP metadata at a well-known URL** — https://yourdomain.com/.well-known/openid-credential-relying-party

Germany's EUDIW pilot (Pilotprogramm) launched in early 2026. The German BSI operates a sandbox environment at https://demo.pid-issuer.bundesdruckerei.de for integration testing with real PID issuance flows.

Implementing OpenID4VP: Minimal RP Example

Here is a minimal Python example of a Relying Party presentation request using the openid4vp pattern:

import secrets
import json
import base64
import hashlib

def create_presentation_request(rp_private_key: str, redirect_uri: str) -> dict:
    """
    Create an OpenID4VP Presentation Request for EU PID attributes.
    Returns the request object to encode as a QR code or deep link.
    """
    nonce = secrets.token_urlsafe(32)  # replay protection

    presentation_definition = {
        "id": "eu-pid-verification",
        "input_descriptors": [
            {
                "id": "eu_pid",
                "name": "EU Person Identification Data",
                "purpose": "Identity verification per eIDAS 2.0",
                "format": {"vc+sd-jwt": {"alg": ["ES256"]}},
                "constraints": {
                    "fields": [
                        {
                            "path": ["$.credentialSubject.family_name"],
                            "filter": {"type": "string"}
                        },
                        {
                            "path": ["$.credentialSubject.given_name"],
                            "filter": {"type": "string"}
                        },
                        {
                            "path": ["$.credentialSubject.age_over_18"],
                            "filter": {"type": "boolean", "const": True}
                        }
                    ]
                }
            }
        ]
    }

    request_object = {
        "response_type": "vp_token",
        "response_mode": "direct_post",
        "client_id": "https://your-saas.eu/rp",
        "redirect_uri": redirect_uri,
        "nonce": nonce,
        "presentation_definition": presentation_definition,
        "state": secrets.token_urlsafe(16)
    }

    # In production: sign this as a JWT with your RP private key
    return request_object


def verify_vp_token(vp_token: str, expected_nonce: str) -> dict:
    """
    Verify a VP Token returned by the EUDIW.
    Returns disclosed claims if valid.
    """
    # 1. Parse the SD-JWT: issuer_jwt~disclosure1~disclosure2~kb_jwt
    parts = vp_token.split("~")
    issuer_jwt = parts[0]
    disclosures = parts[1:-1]
    kb_jwt = parts[-1]

    # 2. Verify issuer signature against EUDIW Trust Framework PKI
    # (requires fetching issuer certificate from national QTSP)
    # issuer_claims = verify_jwt(issuer_jwt, trust_anchors=EUDIW_TRUST_ANCHORS)

    # 3. Verify key binding JWT (prevents replay)
    # kb_claims = verify_key_binding_jwt(kb_jwt, expected_nonce)

    # 4. Decode disclosed claims
    disclosed = {}
    for disc in disclosures:
        decoded = json.loads(base64.urlsafe_b64decode(disc + "=="))
        disclosed[decoded[1]] = decoded[2]  # [salt, key, value]

    return disclosed

For production use, the oid4vp Python library (GitHub: eudiw/eudi-lib-python-openid4vp) provides a complete implementation maintained by the EU Commission's EUDIW project.

EU Hosting Advantage for EUDIW Integration

EUDIW involves highly sensitive personal identity data — national identity attributes, biometric photos, age, address. When your SaaS processes PID credential presentations, you have:

• GDPR Art.9 obligations — PID can contain health data (medical credentials), disability status, biometric photos → special category data under GDPR
• CLOUD Act risk — If your SaaS is hosted by a US-parent cloud provider, EUDIW credential data could in theory be accessed by US law enforcement under the CLOUD Act without an EU court order
• eIDAS 2.0 requirements — The regulation requires Relying Parties to process wallet data in compliance with GDPR; US-hosted services face jurisdictional uncertainty

Hosting on EU-native infrastructure (Hetzner Germany, OVHcloud, Scaleway) eliminates CLOUD Act exposure. With sota.io (EU-native managed PaaS), your EUDIW Relying Party service runs entirely within EU jurisdiction — no US parent, no CLOUD Act, no jurisdictional uncertainty for your EUDIW identity data.

ARF v2.4.0 Reference Implementation Stack

The EU Commission maintains the EUDI Wallet Reference Implementation (EUDIW-RI) on GitHub at eu-digital-identity-wallet organisation. The reference libraries:

The Python library is production-ready as of early 2026 and implements the full ARF v2.4.0 protocol including SD-JWT verification, trust chain validation against national QTSP PKIs, and OpenID4VP cross-device flows.

Pilot Programs and Sandbox Testing

Before the December 2026 go-live, several Member States are running pilots with real wallets:

The EU Commission also maintains a cross-border integration lab (Large-Scale Pilot projects: POTENTIAL, EWC, DC4EU) where Relying Parties can test cross-border flows with wallets from multiple Member States.

20-Item Relying Party Readiness Checklist

Use this checklist to assess your EUDIW integration readiness before December 2026:

Legal & Policy

• Determined whether your service falls under mandatory acceptance obligation
• Updated Privacy Policy to reflect EUDIW credential data processing
• Added EUDIW-specific consent flows (wallet data minimisation disclosure)
• Registered as a Data Controller under GDPR for PID processing

Technical Architecture

• RP key pair generated (EC P-256 recommended)
• RP metadata document published at /.well-known/openid-credential-relying-party
• OpenID4VP presentation request implementation complete
• SD-JWT verification logic implemented (including key binding JWT)
• EUDIW Trust Framework PKI integration (national QTSP certificate chain verification)

Protocol Flows

• Cross-device flow implemented (QR code + polling)
• Same-device flow implemented (deep link with app-to-app)
• Nonce freshness validation (anti-replay)
• Session timeout after presentation (credentials not stored longer than necessary)

Registration & Trust

• Submitted registration to national RP Registry
• Obtained RP certificate from national supervisory body
• Completed at least one end-to-end test with official pilot wallet

Infrastructure

• EU-hosted deployment (CLOUD Act-free jurisdiction)
• Credential data isolated in EU jurisdiction (no US-parent cloud egress)
• Penetration test completed on EUDIW integration endpoints
• Incident response plan includes EUDIW credential data breach scenario

Next in This Series

This is Post #1 of the sota.io EU Digital Identity & eIDAS 2.0 Developer Series:

• Post #1 (this): eIDAS 2.0 EUDIW Overview — Regulation, Who Must Comply, Protocol Stack
• Post #2: OpenID4VP Deep Dive — Cross-Device Flows, Presentation Exchange, Signature Verification
• Post #3: SD-JWT Credential Format — Selective Disclosure, Key Binding, Trust Chain Validation
• Post #4: Relying Party Registration — National Registries, Certificates, Metadata Standards
• Post #5: eIDAS 2.0 Compliance Checklist 2026 — December Deadline Readiness for SaaS Teams

The December 2026 EUDIW deadline is 214 days away. Implementation typically takes 3-6 months — start now.

sota.io runs your EUDIW Relying Party service on EU-native infrastructure. No CLOUD Act exposure. No US parent. Deploy in minutes: sota.io