Il Contesto Normativo: Da eIDAS 1.0 a eIDAS 2.0

Il Regolamento eIDAS 1.0 (EU 910/2014) aveva posto le basi per l’interoperabilità dei sistemi di identità digitale nell’Unione Europea, ma mostrava limiti evidenti: adozione volontaria da parte degli Stati membri, flussi SAML 2.0 poco adatti al mondo mobile, e assenza di un portafoglio digitale standardizzato per i cittadini. Dieci anni dopo, il Regolamento EU 2024/1183 - formalmente noto come eIDAS 2.0 - è entrato in vigore il 20 maggio 2024 riscrivendo le regole del gioco.

Le novità più rilevanti per i developer includono: l’obbligo per tutti gli Stati membri di rilasciare un European Union Digital Identity Wallet (EUDI Wallet) entro il 2026, l’introduzione degli Electronic Attribute Attestations (EAA), il concetto di Qualified Electronic Attestation of Attributes (QEAA), e l’obbligo per i Relying Parties (RP) in settori regolamentati di accettare il wallet entro il 2027.

Architettura EUDI Wallet: I Componenti Fondamentali

L’architettura di riferimento dell’EUDI Wallet è definita dall’Architecture and Reference Framework (ARF), documentazione tecnica mantenuta dalla Commissione Europea. Il sistema si compone di quattro layer principali:

1. Issuer Layer - Chi Emette le Credenziali

Gli Issuers sono entità autorizzate a emettere attestati verificabili. Esistono due categorie principali:

• PID Providers: emettono il Person Identification Data (PID), ovvero la credenziale identitaria di base rilasciata dallo Stato (equivalente al documento d’identità digitale).
• Attestation Providers: emettono EAA (Electronic Attribute Attestations) - ad esempio patente di guida, titolo di studio, tessera sanitaria, qualifica professionale.

Il protocollo standard per l’issuance è OpenID4VCI (OpenID for Verifiable Credential Issuance), che estende il flusso OAuth 2.0 con endpoint dedicati per la richiesta e il rilascio di credenziali.

// Esempio: Token Request per OpenID4VCI
// POST /token

{
  "grant_type": "urn:ietf:params:oauth:grant-type:pre-authorized_code",
  "pre-authorized_code": "SplxlOBeZQQYbYS6WxSbIA",
  "user_pin": "493536"
}

// Risposta con Access Token
{
  "access_token": "eyJraWQiOiJrZXktMSJ9...",
  "token_type": "bearer",
  "expires_in": 86400,
  "c_nonce": "tZignsnFbp",
  "c_nonce_expires_in": 86400
}

// Credential Request
// POST /credential
// Authorization: Bearer eyJraWQiOiJrZXktMSJ9...

{
  "format": "vc+sd-jwt",
  "credential_definition": {
    "type": ["VerifiableCredential", "PersonIdentificationData"]
  },
  "proof": {
    "proof_type": "jwt",
    "jwt": "eyJraWQiOiJrZXktMiIsInR5cCI6Im9wZW5pZDR2Y2ktcHJvb2Yrand..."
  }
}

2. Wallet Layer - Il Portafoglio del Cittadino

Il EUDI Wallet è un’applicazione (mobile o web) che il cittadino usa per ricevere, conservare e presentare le proprie credenziali. Deve essere certificata secondo gli standard di sicurezza definiti dagli Implementing Acts (EUCC - EU Cybersecurity Certification Scheme for Common Criteria). Le funzionalità principali includono:

• Gestione sicura delle chiavi crittografiche (hardware-backed quando disponibile)
• Supporto a SD-JWT VC (Selective Disclosure JWT Verifiable Credentials)
• Supporto a ISO 18013-5 (mdoc) per il profilo mobile driver’s license
• Proximity presentation via NFC/BLE (per controlli fisici)
• Remote presentation via browser (HTTPS redirect)

3. Verifier/Relying Party Layer - Chi Riceve le Credenziali

I Relying Parties (RP) - chiamati anche Verifiers nell’ecosistema VC - sono i servizi che richiedono l’autenticazione o la verifica degli attributi del cittadino. Il protocollo per la presentazione è OpenID4VP (OpenID for Verifiable Presentations), spesso usato in combinazione con SIOPv2 (Self-Issued OpenID Provider v2) per i flussi self-sovereign.

4. Trust Infrastructure - La Catena di Fiducia

L’EUDI Wallet si basa su una Public Key Infrastructure (PKI) europea coordinata dalla Commissione. Ogni Issuer deve essere registrato nell’EUDIW Trusted Issuers Registry, e i Verifiers devono registrarsi come Relying Parties. La validazione delle credenziali avviene attraverso la verifica della firma digitale dell’Issuer tramite certificati X.509 v3 ancorati alla PKI nazionale dello Stato membro.

SD-JWT: Selective Disclosure e Privacy

Uno degli aspetti tecnici più rilevanti di eIDAS 2.0 è l’adozione degli SD-JWT (Selective Disclosure JSON Web Tokens), definiti nell’RFC IETF corrispondente. L’idea di base è permettere al titolare (holder) di rivelare solo gli attributi necessari per una determinata transazione, senza esporre l’intero documento di identità.

Un SD-JWT si compone di tre parti:

// Struttura SD-JWT

// 1. JWT Header + Payload (con disclosures hashate)
{
  "iss": "https://issuer.example.gov.it",
  "sub": "user_12345",
  "iat": 1710000000,
  "exp": 1741536000,
  "_sd_alg": "sha-256",
  "_sd": [
    "YIk1uXcv7d9yT8rX4mZ1aA",   // hash di "given_name": "Mario"
    "kp3uX9vZ2d8rT7yX5mZ3bB",   // hash di "family_name": "Rossi"
    "Xp4uX8vZ3d9rT6yX6mZ4cC",   // hash di "birthdate": "1990-01-15"
    "Zp5uX7vZ4d0rT5yX7mZ5dD"    // hash di "age_over_18": true
  ]
}

// 2. Disclosure (payload completo, trasmesso separatamente)
// Ogni disclosure = base64url( salt || claim_name || claim_value )
// Esempio decoded:
["ynMvKGiQegTHCXkHkEL4aA", "given_name", "Mario"]
["qRpTaSvVlGnb9uOtCiKqGg", "age_over_18", true]

// 3. Presentazione selettiva al Verifier
// Il holder invia solo le disclosures che vuole rivelare
// In questo esempio: solo age_over_18, non given_name

eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwcz...~qRpTaSvVlGnb9uOtCiKqGg~

Implementare un Relying Party EUDI Wallet

Se stai sviluppando un servizio digitale che deve accettare l’identità EUDI Wallet, devi implementare un Verifier/Relying Party. I passi principali sono:

Step 1: Registrazione come Relying Party

Ogni RP deve registrarsi nel registro nazionale degli intermediari e ottenere un certificato X.509 che sarà usato per firmare le Authorization Requests inviate al wallet. In Italia, il registro è gestito da AgID.

Step 2: Creare una Authorization Request (OpenID4VP)

// Authorization Request OpenID4VP
// Il RP genera un signed JWT con i parametri di presentazione

// Header JWT del Request Object
{
  "alg": "ES256",
  "kid": "rp-key-2025",
  "typ": "oauth-authz-req+jwt"
}

// Payload JWT del Request Object
{
  "client_id": "https://my-service.comune.it/eudi-rp",
  "client_id_scheme": "x509_san_uri",
  "response_type": "vp_token",
  "response_mode": "direct_post",
  "response_uri": "https://my-service.comune.it/eudi-rp/callback",
  "nonce": "n-0S6_WzA2Mj",
  "state": "af0ifjsldkj",
  "presentation_definition": {
    "id": "pid-age-verification",
    "input_descriptors": [
      {
        "id": "pid_vc",
        "format": {
          "vc+sd-jwt": {
            "alg": ["ES256", "ES384"]
          }
        },
        "constraints": {
          "fields": [
            {
              "path": ["$.vct"],
              "filter": {
                "type": "string",
                "const": "PersonIdentificationData"
              }
            },
            {
              "path": ["$.age_over_18"],
              "intent_to_retain": false
            }
          ]
        }
      }
    ]
  }
}

Step 3: Verifica della VP Token

Quando il wallet risponde con una vp_token, il Relying Party deve eseguire le seguenti verifiche:

// Pseudo-codice Python per verifica VP Token

import jwt
import hashlib
import base64

def verify_vp_token(vp_token: str, expected_nonce: str) -> dict:
    # 1. Splitta SD-JWT in parti (~ come separatore)
    parts = vp_token.split("~")
    sd_jwt = parts[0]
    disclosures = parts[1:-1]  # ultime parte potrebbe essere KB-JWT
    key_binding_jwt = parts[-1] if len(parts) > 1 else None

    # 2. Decodifica e verifica il JWT principale
    header = jwt.get_unverified_header(sd_jwt)
    # Recupera il certificato dell'issuer dalla PKI europea
    issuer_cert = fetch_issuer_cert(header.get("x5c"))
    payload = jwt.decode(sd_jwt, issuer_cert, algorithms=["ES256"])

    # 3. Verifica nonce nel Key Binding JWT
    if key_binding_jwt:
        kb_payload = jwt.decode(key_binding_jwt, options={"verify_signature": False})
        assert kb_payload["nonce"] == expected_nonce, "Nonce mismatch"
        assert kb_payload["aud"] == "https://my-service.comune.it/eudi-rp"

    # 4. Risolvi le disclosures
    disclosed_claims = {}
    for disclosure in disclosures:
        # Verifica hash
        disclosure_hash = base64.urlsafe_b64encode(
            hashlib.sha256(disclosure.encode()).digest()
        ).rstrip(b"=").decode()
        if disclosure_hash in payload.get("_sd", []):
            decoded = json.loads(base64.urlsafe_b64decode(disclosure + "=="))
            # formato: [salt, claim_name, claim_value]
            disclosed_claims[decoded[1]] = decoded[2]

    return disclosed_claims

IT Wallet Italiano: Lo Stato dell’Arte

L’Italia si avvicina all’ecosistema EUDI Wallet attraverso il proprio IT Wallet, previsto dal D.Lgs. 07/03/2024 n. 31 e sviluppato nell’ambito del PNRR. Il sistema è gestito da PagoPA S.p.A. e integra i sistemi già esistenti di SPID e CIE (Carta d’Identità Elettronica).

L’IT Wallet è progettato come soluzione transitoria verso l’EUDI Wallet compliant, e dall’inizio del 2025 ha avviato la fase pilota con la patente di guida digitale, la tessera sanitaria e il certificato di disabilità come prime credenziali disponibili.

OpenID4VP con SIOPv2: Il Flusso Cross-Device

Uno scenario comune è il cross-device flow: l’utente visita un sito web su desktop e usa lo smartphone per autenticarsi con il wallet. Il flusso tipico usa un QR Code come canale di comunicazione iniziale:

// Flusso cross-device EUDI Wallet

// 1. Il RP genera il Request Object e lo rende disponibile
GET /eudi/request.jwt HTTP/1.1
// Risposta: signed JWT con presentation_definition

// 2. Il RP mostra un QR code che contiene:
eudi-openid4vp://?
  client_id=https%3A%2F%2Fmy-service.comune.it%2Feudi-rp&
  request_uri=https%3A%2F%2Fmy-service.comune.it%2Feudi-rp%2Frequest.jwt&
  state=af0ifjsldkj

// 3. Il wallet dell'utente scansiona il QR:
//    - Risolve il request_uri
//    - Valida la firma del Request Object
//    - Mostra all'utente quale attributo viene richiesto
//    - Chiede il consenso

// 4. Il wallet invia la risposta via direct_post al response_uri:
POST /eudi-rp/callback HTTP/1.1
Content-Type: application/x-www-form-urlencoded

vp_token=eyJhbGciOiJFUzI1NiJ9...&
state=af0ifjsldkj

// 5. Il RP verifica la VP Token
// 6. Il RP redirige il browser desktop tramite session polling o SSE

Interoperabilità con SPID e CIE

I developer italiani devono comprendere come coesistono i sistemi attuali con il nuovo ecosistema EUDI:

Sicurezza e Considerazioni Crittografiche

L’implementazione EUDI Wallet richiede attenzione a diversi aspetti di sicurezza:

Key Binding

Ogni credenziale è legata crittograficamente al wallet (e quindi al dispositivo fisico del cittadino) tramite un meccanismo chiamato Key Binding. La chiave privata del holder non deve mai lasciare il secure element del dispositivo. Il Key Binding JWT (KB-JWT) dimostra che il presentatore possiede la chiave privata corrispondente alla chiave pubblica registrata nell’SD-JWT.

Replay Attack Prevention

Il campo nonce nell’Authorization Request è generato casualmente dal RP e deve essere incluso nel KB-JWT firmato dal wallet. Il RP verifica che il nonce corrisponda a quello originariamente generato, prevenendo attacchi di replay.

Certificate Validation

I certificati degli Issuers devono essere validati lungo la catena PKI fino ai trust anchors europei. Usa sempre la versione aggiornata della Trusted List europea (disponibile via API dalla Commissione UE).

Strumenti e Librerie per Developer

L’ecosistema open source attorno a EUDI Wallet sta crescendo rapidamente. Questi sono i riferimenti più importanti:

# Librerie ufficiali EU (reference implementations)

# Python - EUDI Wallet Issuer SDK
pip install eudi-srv-pid-issuer

# Python - SD-JWT Reference Implementation
pip install sd-jwt

# Java - EUDI Wallet Core Library
# gradle dependency:
# implementation("eu.europa.ec.eudi:eudi-lib-jvm-sdjwt-kt:latest")

# TypeScript/JavaScript
npm install @sd-jwt/sd-jwt-vc @sd-jwt/decode
npm install openid4vc  # OID4VCI + OID4VP client

# --- Esempio uso sd-jwt in TypeScript ---
import { SDJwtVcInstance } from "@sd-jwt/sd-jwt-vc";
import { digest, generateSalt } from "@sd-jwt/crypto-nodejs";

const sdjwt = new SDJwtVcInstance({
  signer: async (data: string) => sign(data, issuerPrivateKey),
  signAlg: "ES256",
  verifier: async (data: string, sig: string) => verify(data, sig, issuerPublicKey),
  hasher: digest,
  hashAlg: "sha-256",
  saltGenerator: generateSalt,
});

// Emetti una credenziale
const credential = await sdjwt.issue(
  {
    iss: "https://issuer.gov.it",
    iat: Math.floor(Date.now() / 1000),
    vct: "PersonIdentificationData",
    given_name: "Mario",
    family_name: "Rossi",
    age_over_18: true,
    birthdate: "1990-01-15",
  },
  // Indica quali claim sono selectively disclosable
  {
    _sd: ["given_name", "family_name", "birthdate", "age_over_18"],
  }
);

console.log(credential); // eyJhbGciOiJFUzI1NiJ9...~...

Testing e Ambienti Sandbox

Prima di andare in produzione, utilizza gli ambienti sandbox ufficiali:

• EU EUDI Wallet Reference Application: disponibile su GitHub (eu-digital-identity-wallet) come app Android/iOS open source. Include issuer demo, verifier demo e PID issuer di test.
• Italia IT Wallet Sandbox: PagoPA fornisce ambiente di test per l’integrazione come Relying Party (contattare la community developers.italia.it per accesso).
• EUDIW Conformance Testing Tool: strumento della Commissione UE per testare la conformità agli Implementing Acts.

Roadmap per i Developer Italiani

Se lavori per un’amministrazione pubblica o per un’azienda privata che eroga servizi ai cittadini italiani, ecco le azioni concrete da intraprendere nei prossimi mesi:

Conclusioni

eIDAS 2.0 e l’EUDI Wallet rappresentano la trasformazione più profonda del panorama dell’identità digitale europea degli ultimi decenni. Per i developer, questo significa abbracciare un ecosistema tecnologico completamente nuovo: SD-JWT, OpenID4VCI, OpenID4VP, SIOPv2, e una PKI a scala continentale.

La transizione non è immediata - SPID e CIE continueranno a operare in parallelo per anni - ma il momento di iniziare a prepararsi è adesso. I servizi che si adeguano per tempo avranno un vantaggio competitivo reale e saranno pronti quando l’adozione di massa dell’EUDI Wallet trasformerà le aspettative degli utenti in termini di privacy, controllo e interoperabilità transfrontaliera.