Tutorial OID4VP: Verifica Online e Offline di Patente e Tessera Sanitaria in IT Wallet

Con l’evoluzione dell’ecosistema europeo di identità digitale eIDAS 2.0 e l’integrazione di IT Wallet all’interno dell’App IO, i Relying Party (RP) pubblici e privati devono aggiornare i propri meccanismi di autenticazione e verifica delle credenziali. In questo tutorial tecnico analizziamo l’adozione e il flusso OID4VP per verificare documenti digitali quali patente di guida (mDL) e Tessera Sanitaria (TS-CNS). Per una visione sistemica dell’infrastruttura sottostante, ti invitiamo a consultare la nostra guida all’architettura di IT Wallet su App IO.

Prerequisiti: Conoscenza dei concetti base di crittografia asimmetrica (ECDSA su curve P-256 o Ed25519), familiarità con lo standard OpenID Connect e con i formati di credenziali SD-JWT (Selective Disclosure JWT) e ISO/IEC 18013-5 mdoc.

1. Architettura di OID4VP e Formati delle Credenziali

Il protocollo OpenID for Verifiable Presentations definisce le modalità con cui un verificatore richiede a un Wallet crittografico una presentazione verificabile (Verifiable Presentation) contenente claims selettivi. Nel contesto italiano di IT Wallet, i documenti principali adottano due standard complementari:

  • Patente di guida (mDL): Codificata prevalentemente in formato CBOR conforme allo standard ISO/IEC 18013-5 (mdoc), ottimizzato per la verifica offline ad alta velocità.
  • Tessera Sanitaria (TS-CNS): Basata prevalentemente su SD-JWT VC, che consente la divulgazione selettiva degli attributi (es. solo codice fiscale o maggiore età) proteggendo gli altri dati anagrafici.

2. Scenario 1: Verifica Online (App-to-App e Web)

Nella modalità connessa, la comunicazione avviene via HTTPS tra il browser o server del Relying Party e l’applicazione IT Wallet dell’utente.

Fase 1: Invio dell’Authorization Request

Nel contesto della verifica remota via web o app-to-app, il flusso OID4VP orchestra lo scambio sicuro tramite uno standard RESTful conforme alle specifiche DIF Presentation Exchange. Il verificatore genera una richiesta firmata contenente un presentation_definition:

{
  "client_id": "https://verifier.example.it/cb",
  "response_type": "vp_token",
  "response_mode": "direct_post",
  "response_uri": "https://verifier.example.it/api/present-response",
  "nonce": "n-0S6_WzA2Mj",
  "presentation_definition": {
    "id": "verifica_patente_richiesta",
    "input_descriptors": [{
      "id": "driving_licence",
      "format": {"mso_mdoc": {"alg": ["ES256"]}},
      "constraints": {
        "fields": [
          {"path": ["$['org.iso.18013.5.1']['driving_privileges']"]},
          {"path": ["$['org.iso.18013.5.1']['expiry_date']"]}
        ]
      }
    }]
  }
}

Fase 2: Interazione dell’Utente e Selezione dei Dati

L’utente riceve la notifica su App IO o scansiona un QR Code sul portale web. L’interfaccia di IT Wallet mostra i soli campi richiesti dal verificatore, consentendo l’approvazione biometrica (TouchID o FaceID) per sbloccare la chiave privata contenuta nel Secure Enclave.

Fase 3: Ricezione e Validazione del VP Token

Il Relying Party riceve il payload crittografico tramite la callback response_uri. Il processo di validazione lato server deve eseguire rigorosamente i seguenti step:

  1. Verifica del Nonce: Assicurarsi che il nonce ritornato corrisponda alla sessione attiva e non sia stato riutilizzato (prevenzione attacchi replay).
  2. Verifica della Firma dell’Issuer: Validare il Mobile Security Object (MSO) o l’Issuer Signed JWT verificando la catena di certificati con il Trust Anchor nazionale accreditato da AgID.
  3. Verifica del Device Binding: Controllare la signature del Wallet per verificare il possesso della chiave effimera o di legame del dispositivo associata alla credenziale.

3. Scenario 2: Verifica Offline Proximity (BLE e mdoc)

Nelle situazioni in cui la connettività di rete è assente o degradata (es. controlli di polizia stradale o varchi montani), la verifica si sposta sul layer radio di prossimità.

Architettura di prossimità BLE e QR Code

Quando manca la connettività Internet, il flusso OID4VP si adatta alla trasmissione in prossimità sfruttando Bluetooth Low Energy (BLE) e codici QR conformi a ISO/IEC 18013-5. Il flusso operativo prevede quattro momenti chiave:

  1. Device Engagement: Il lettore mostra un QR statico o dinamico con i parametri radio BLE (MAC address effimero e chiave pubblica effimera Verifier).
  2. BLE Handshake: Lo smartphone dell’utente avvia la connessione come Central o Peripheral BLE e stabilisce un canale cifrato TLS su BLE via curve ECDH.
  3. Session Transcript Hashing: La chiave di sessione include un hash di tutti i parametri scambiati durante l’engagement, garantendo la protezione contro attacchi Man-in-the-Middle (MitM).
  4. Data Transfer: Trasferimento compatto dei CBOR bytes contenenti la patente o la tessera sanitaria, e chiusura immediata del canale radio.
Sicurezza Offline: Nelle verifiche offline è indispensabile che il software del lettore disponga di una copia locale regolarmente sincronizzata delle Certificate Revocation Lists (CRL) o delle Trusted Public Keys degli Issuer emittenti.

4. Considerazioni su Minimizzazione dei Dati e Privacy

L’uso congiunto di SD-JWT e mdoc garantisce che il verificatore riceva unicamente i campi strettamente pertinenti al servizio richiesto. Ad esempio, per accertare il diritto all’accesso ad un servizio sanitario o l’acquisto di prodotti con limite anagrafico, il sistema non richiede data di nascita e indirizzo di residenza completi, bensì un predicato booleano age_over_18: true certificato dall’emittente originario.

Conclusioni e Prossimi Passi

In questa guida abbiamo visto come configurare il flusso OID4VP garantendo privacy, selettività degli attributi e crittografia allo stato dell’arte. Il passaggio successivo consiste nell’eseguire il deployment di un endpoint verificatore conforme alle linee guida tecniche di interoperabilità e testare le transazioni nel sandbox ufficiale prima della messa in produzione.

Articoli simili