Architettura del consenso

Il consenso non è una casella da spuntare.

EHDS Article 71 ha reso il diritto di opposizione un diritto legale lo scorso anno. Decentralized Key Management è l'unica architettura in grado di onorarlo attraverso i confini istituzionali.

Prenoti una revisione dell'architettura del consenso di 30 minuti

Cinque regimi che convergono in una finestra di 24 mesi

Il consenso non è più un elemento facoltativo per le organizzazioni. In tutta Europa e in Svizzera, cinque regimi normativi distinti hanno reso l’opposizione un obbligo giuridico vincolante, e ciascuno è stato redatto indipendentemente dagli altri. Condividono una caratteristica: presuppongono che il titolare del trattamento possa smettere su richiesta di usare dati identificabili, propagare quella cessazione a ogni parte a valle e dimostrarlo in un secondo momento. L’infrastruttura di identità centralizzata non è mai stata progettata per nessuna di queste garanzie.

  • EHDS, articolo 71

    In vigore dal 26 marzo 2025

    L’opposizione come diritto sancito per legge; l’articolo 71(8) preclude i registri di re-identificazione; il considerando 54 impone la reversibilità.

  • GDPR, art. 7(3) + art. 17(2)

    In vigore dal 25 maggio 2018

    La revoca deve essere facile quanto la prestazione del consenso; i titolari devono propagare la cancellazione a ogni destinatario a valle.

  • eIDAS 2.0, articolo 5a

    In vigore dal 20 maggio 2024; wallet entro il quarto trimestre 2026

    Wallet di identità controllati dai cittadini, con divulgazione selettiva e obblighi di non collegabilità per le parti facenti affidamento.

  • nLPD svizzera / revisione LRUm

    nLPD in vigore dal 1° settembre 2023; modifica della LRUm in consultazione

    Obbligo di revoca del consenso per l’uso secondario a fini di ricerca; divieto esplicito di re-identificazione dei dati pseudonimizzati.

  • PDSG tedesco

    In vigore dal 20 ottobre 2020

    Accesso controllato dal paziente ai fascicoli ePA; opposizione granulare per categoria di dati, esigibile presso tutti i fornitori.

Preso singolarmente, ciascuno è gestibile. Insieme rendono insufficiente l’architettura basata su CA centralizzate.

I cinque requisiti non negoziabili

Senza il linguaggio giuridico, i cinque regimi impongono cinque requisiti tecnici all’infrastruttura di attuazione. Nessuno è facoltativo, nessuno è eliminabile per contratto, ciascuno è nominato per clausola nel diritto primario.

I cinque requisiti non negoziabili: X.509 PKI, IAM federata e DKMS a confronto Confronto: quale architettura soddisfa quale requisito. X.509 non ne soddisfa nessuno. La federazione nemmeno (propaga solo violando la non collegabilità). DKMS li soddisfa tutti e cinque. Requisito X.509 PKI IAM federata DKMS Identificatori specifici per persona ✗ i ✗ ✓ Opposizione verificabile con marca temporale ✗ ✗ ✓ Reversibilità senza re-identificazione ✗ ✗ ✓ Propagazione tra titolari ✗ i ✗ i ✓ i Non collegabilità ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a requirements: X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG: Requirements for Lawful Consent

Fate clic su una (i) per il ragionamento · Fate clic per ingrandire il diagramma

I cinque requisiti non negoziabili: X.509 PKI, IAM federata e DKMS a confronto Confronto: quale architettura soddisfa quale requisito. X.509 non ne soddisfa nessuno. La federazione nemmeno (propaga solo violando la non collegabilità). DKMS li soddisfa tutti e cinque. Requisito X.509 PKI IAM federata DKMS Identificatori specifici per persona ✗ i ✗ ✓ Opposizione verificabile con marca temporale ✗ ✗ ✓ Reversibilità senza re-identificazione ✗ ✗ ✓ Propagazione tra titolari ✗ i ✗ i ✓ i Non collegabilità ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a requirements: X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG: Requirements for Lawful Consent

Perché X.509 non può fornire identificatori specifici per persona

X.509 identifica le entità tramite certificati emessi da una Certificate Authority, non tramite chiavi controllate dal soggetto. Il cittadino non ha alcun ruolo architetturale nella radice di fiducia: è la CA a decidere chi è chi. Il considerando 54 dell’EHDS e l’art. 5a di eIDAS 2.0 richiedono identificatori controllati dal soggetto; X.509 soddisfa questo requisito solo avvolgendo la PKI in una cerimonia lato soggetto che il protocollo sottostante non supporta nativamente.

Perché X.509 non può propagare la revoca del consenso

X.509 non ha un meccanismo nativo di propagazione. La revoca delle credenziali passa da CRL e responder OCSP che ogni verificatore deve scegliere esplicitamente di consultare, e nulla permette di trasmetterla a ritroso ai dati già condivisi. Quando un certificato ha firmato l’autorizzazione a un flusso di dati, la revoca del consenso resta a discrezione del verificatore.

Perché X.509 viola la non collegabilità

Ogni certificato X.509 reca un numero di serie stabile e un DN dell’emittente visibili a ogni verificatore. Due parti che fanno affidamento possono correlare lo stesso soggetto tra transazioni diverse confrontando i seriali. La pseudonimizzazione richiede una nuova emissione, operativamente onerosa: la collegabilità è una scelta di progettazione, non un difetto.

Perché la federazione soddisfa solo in parte la propagazione

L’IAM federata soddisfa la propagazione tra titolari solo violando la non collegabilità: il provider di identità vede ogni accesso presso ogni parte che fa affidamento e crea così la superficie di correlazione tra RP vietata dall’art. 5a(16)(b) di eIDAS 2.0. La propagazione tramite federazione è quindi conteggiata come non soddisfatta.

Perché la federazione non può fornire la non collegabilità

Un provider di identità federato vede ogni tentativo di accesso presso ogni parte che fa affidamento. Anche se le singole credenziali sono pseudonime, l’IdP detiene per costruzione il grafo di correlazione tra RP. L’art. 5a(16)(b) di eIDAS 2.0 vieta esattamente questa superficie.

Come DKMS propaga la revoca del consenso

Le autorizzazioni si concatenano al Key Event Log (KEL) del soggetto. Quando il soggetto ruota le chiavi, ogni verificatore a valle che ricontrolla il KEL al momento del trattamento vede la rotazione e considera non valide le credenziali obsolete. Nessun invio dell’operatore, nessun registro centrale: la propagazione avviene per interrogazione del verificatore all’uso.

Come DKMS preserva la non collegabilità

I soggetti possono generare un nuovo AID per ogni parte che fa affidamento. Il KEL dietro ogni AID è indipendente: non esiste alcun registro centrale delle identità né un IdP che veda ogni transazione. La correlazione tra RP richiede che sia il soggetto stesso a collegare deliberatamente gli AID.

  1. Identificatori specifici per persona

    L’identificatore controllato dall’interessato deve essere la radice di fiducia, non un identificatore emesso da una parte facente affidamento. Il considerando 54 dell’EHDS e l’articolo 5a di eIDAS 2.0 lo dicono entrambi in modo diretto: il cittadino deve poter agire senza che il titolare debba cercarlo in un registro separato. Ogni architettura in cui è il titolare a coniare e conservare l’identificatore fallisce qui fin dal primo giorno.

  2. Opposizione verificabile e con marca temporale

    La revoca deve essere un evento firmato crittograficamente e con marca temporale, che l’autorità di controllo (e un futuro tribunale) possa verificare senza doversi fidare dei log del titolare. L’articolo 7(3) del GDPR lo dice esplicitamente: l’onere della prova è a carico del titolare. Una riga in un database interno non è una prova in nessuna sede in cui il titolare è il convenuto.

  3. Reversibilità senza re-identificazione

    Il considerando 54 dell’EHDS esige che l’opposizione resti reversibile (il cittadino può revocarla e tornare a partecipare) senza che nessuno debba re-identificare i record sottostanti. Questo richiede che l’opposizione operi su una credenziale controllata dall’interessato, non su una tabella di corrispondenza lato server. I registri di consenso centralizzati falliscono qui per ragioni strutturali.

  4. Propagazione tra titolari

    L’articolo 17(2) del GDPR e l’articolo 71 dell’EHDS richiedono entrambi che la revoca si propaghi a ogni destinatario a valle. In pratica questo significa che il titolare originario non può limitarsi ad aggiornare la propria riga locale: ogni parte che abbia mai ricevuto i dati deve ri-autenticare l’autorizzazione e scoprire che è stata revocata. La federazione può farlo solo condividendo gli identificatori, il che viola il requisito successivo.

  5. Non collegabilità

    L’articolo 5a di eIDAS 2.0 impone che le parti facenti affidamento non possano correlare lo stesso cittadino tra transazioni distinte senza consenso. L’articolo 71(8) dell’EHDS preclude l’identificatore centralizzato tra organizzazioni che renderebbe banale la propagazione federata. I due requisiti insieme (propagare, ma non correlare) sono ciò che mette fuori gioco le architetture convenzionali.

X.509 ne soddisfa zero. La federazione soddisfa la propagazione violando la non collegabilità. DKMS li soddisfa tutti e cinque.

La trappola dell’articolo 71(8)

La risposta ingegneristica intuitiva alla richiesta di "onorare l’opposizione in tutta la rete" è tenere un elenco degli identificatori di chi si è opposto: un registro centrale di non trattamento che ogni sistema a valle interroga prima di toccare un record. L’articolo 71(8) dell’EHDS vieta esattamente questa costruzione. La clausola proibisce ai detentori dei dati di acquisire o conservare dati identificativi aggiuntivi al solo scopo di onorare le opposizioni.

Il ragionamento, reso esplicito nel considerando 54, è che il registro stesso diventa un database di re-identificazione: esattamente il danno che la norma è stata scritta per prevenire. Nel momento in cui mantenete un elenco di "persone che si sono opposte", avete ricostruito l’archivio centrale che attira gli attacchi. L’implicazione strutturale è inevitabile: il segnale di opposizione deve viaggiare con una credenziale controllata dall’interessato, non in un elenco mantenuto dal titolare.

The DKMS thesis DKMS è la risposta

La gestione decentralizzata delle chiavi è il primo fondamento strutturalmente solido per onorare l’opposizione end-to-end in condizioni interorganizzative, post-divulgazione e sotto l’occhio delle autorità di controllo.

(La gestione decentralizzata delle chiavi si basa su KERI, una specifica aperta della Trust over IP Foundation.)

Come funziona:

  1. L’AID di controllo dell’utente è la radice di fiducia. Le autorizzazioni vi si concatenano crittograficamente, non a un account emesso dal titolare.
  2. Ogni autorizzazione è ancorata nel Key Event Log (KEL) dell’AID: un registro append-only, concatenato tramite hash, il cui stato l’interessato può dimostrare unilateralmente.
  3. La revoca è una rotazione delle chiavi che l’interessato esegue in autonomia. La vecchia chiave viene invalidata; l’evento di rotazione è firmato e marcato temporalmente nel KEL.
  4. Le parti a valle che detengono credenziali obsolete devono ri-autenticarsi rispetto allo stato più recente del KEL. La revoca si propaga con un comportamento fail-closed presso ogni verificatore a valle.

Nulla nel protocollo richiede un operatore centrale. Nulla richiede che le parti facenti affidamento condividano identificatori. Nulla richiede che l’autorità di controllo si fidi dei log del titolare più che di quelli dell’interessato. Ciascuno dei cinque requisiti è soddisfatto per costruzione, non per audit.

Dove DKMS domina e dove non offre alcun vantaggio

L’onestà sull’ambito di applicazione è ciò che rende la tesi difendibile. DKMS domina in quattro condizioni: flussi di dati interorganizzativi, revoca post-divulgazione, trattamenti sotto l’occhio delle autorità di controllo e controparti ostili. Al di fuori di queste condizioni (carichi di lavoro single-tenant, artefatti derivati come i pesi di modelli ML addestrati, backup eseguiti prima della revoca, singole controparti disoneste che agiscono da sole) DKMS offre rilevamento forense, non prevenzione.

Dove DKMS domina Dove DKMS non offre benefici Flussi di dati tra organizzazioni Fate clic su una riga per il ragionamento Persistenza del consenso post-divulgazione Fate clic su una riga per il ragionamento Custodia decisiva per le autorità di controllo Fate clic su una riga per il ragionamento Le parti adottano DKMS end-to-end Fate clic su una riga per il ragionamento Derivati (analisi, pesi dei modelli ML) Fate clic su una riga per il ragionamento Backup già effettuati Fate clic su una riga per il ragionamento Singola controparte disonesta Fate clic su una riga per il ragionamento Carichi di lavoro single-tenant Fate clic su una riga per il ragionamento Dove DKMS domina e dove non offre benefici. Fate clic su una riga per il ragionamento.

Flussi di dati tra organizzazioni

La cancellazione lato operatore non può raggiungere i dati già condivisi con le parti a valle. DKMS estende la gestione delle chiavi controllata dal detentore lungo tutta la catena di trattamento: ogni ricevente ricontrolla il KEL al momento dell’uso. Il CMK centralizzato cancella solo entro il perimetro del tenant dell’operatore.

Persistenza del consenso post-divulgazione

EUDIW ARF §6.6 riconosce esplicitamente che la revoca del consenso non annulla retroattivamente un trattamento lecito precedente. DKMS riduce il divario: i verificatori ricontrollano il KEL pubblicato al momento del trattamento e le credenziali obsolete diventano verificabili come tali. Il meccanismo architetturale di base è del detentore, non dell’operatore.

Custodia decisiva per le autorità di controllo

Schrems II / Raccomandazioni EDPB 01/2020, Use Case 3, richiedono che l’importatore dei dati NON detenga le chiavi. Il CMK centralizzato non supera questo test per definizione (ad es. dati sanitari USA in Azure sotto la FISA 702). DKMS rende la custodia delle chiavi una proprietà lato detentore: l’importatore non può decifrare senza uno stato del KEL del detentore che lo consenta.

Le parti adottano DKMS end-to-end

L’architettura conta solo se tutte le parti la applicano. Un verificatore che ignora il KEL annulla l’intera catena. Quando tutte le parti adottano DKMS, la revoca del consenso si propaga con una semplice riverifica: nessun operatore deve «spingere» la cancellazione.

Derivati (analisi, pesi dei modelli ML)

Il Parere EDPB 28/2024 conferma esplicitamente che gli obblighi di cancellazione non si propagano in modo pulito ai pesi dei modelli dopo l’addestramento. Qui DKMS non copre meglio del CMK. La revoca del consenso non può annullare retroattivamente gli output analitici né le segnalazioni già inviate alle autorità di controllo.

Backup già effettuati

Nessuna architettura può richiamare dati già replicati su supporti di backup offline o immutabili. La cifratura a riposo con distruzione delle chiavi copre i residui entro la finestra di conservazione; non recupera gli archivi a lungo termine. DKMS non modifica questa proprietà fondamentale.

Singola controparte disonesta

DKMS offre rilevamento forense (le firme successive a una rotazione di chiavi pubblicata sono verificabili come obsolete), non prevenzione. Un sub-responsabile del trattamento del tutto non cooperativo che decifra il testo in chiaro e lo conserva fuori dall’involucro cifrato annulla la catena: DKMS rende evidente la violazione, non la blocca.

Carichi di lavoro single-tenant

Per un SaaS con un solo titolare del trattamento, la cancellazione crittografica NIST SP 800-88 §2.5 tramite CMK centralizzato è adeguata e più semplice. Passare a DKMS aggiunge onere operativo senza beneficio architetturale, se non ci sono confini tra domini di fiducia distinti.

Al di fuori delle quattro condizioni in cui DKMS domina, il CMK centralizzato è una scelta razionale. Dirlo rende la tesi più solida.

Collaudato in produzione

HIN (Health Info Net) è la dorsale dell’informazione sanitaria svizzera: collega ospedali, cliniche e specialisti oltre i confini cantonali. SEAL, il livello di consegna verificabile delle email che Vereign fornisce all’interno di HIN, è oggi in produzione e trasporta oltre 800.000 messaggi verificati al mese: la prova che Vereign gestisce già infrastruttura di livello produttivo nella sanità svizzera.

Verimesh (in precedenza il progetto Stargate), il runtime di gestione decentralizzata delle chiavi che porta all’uso operativo il meccanismo di opposizione in quattro passaggi descritto sopra, è in produzione nella sanità svizzera.

Il livello FHIR di Verimesh, cioè le stesse garanzie applicate allo scambio di cartelle cliniche e non solo ai messaggi, è oggi a livello architetturale. Portarlo in produzione dipende dall’onboarding lato ospedali; la prima data realistica è fine 2026.

Cinque incidenti che dimostrano lo schema strutturale

  1. Kaiser Foundation Health Plan ha chiuso una class action con una transazione da 47,5 milioni di USD (2026). I dati del portale pazienti erano finiti a piattaforme pubblicitarie tramite pixel di tracciamento incorporati. L’architettura non offriva all’interessato alcun meccanismo per revocare la propagazione a valle.
  2. Sutter Health ha chiuso una class action con una transazione da 21,5 milioni di USD (2026). Stesso schema: tag di terze parti lato portale, nessuna primitiva di revoca controllata dall’interessato, nessun modo di dimostrare a posteriori il mancato trattamento.
  3. NHS National Data Opt-Out (2021): ammissione di non retroattività; il programma GPDPR è stato rinviato perché l’architettura non era in grado di onorare la revoca sui dati già condivisi con i ricercatori a valle.
  4. SingHealth (2018): 1,5 milioni di record violati perché i dati dei pazienti risiedevano in un unico database monolitico, senza confini crittografici per singolo paziente. Non c’era nulla che l’interessato potesse revocare; non c’era nessuna chiave da ruotare.
  5. DigiNotar (2011): la compromissione della CA radice ha portato i browser a togliere la fiducia a ogni certificato che quella CA avesse mai emesso. Gli interessati non avevano alcun potere di intervento a livello architetturale: identificatori e relazioni di fiducia erano interamente nelle mani dell’operatore.

Ogni incidente centralizzato condivide una caratteristica: l’utente non aveva alcun potere di intervento a livello architetturale.

Da dove iniziare

Se la vostra organizzazione tratta dati personali identificabili di natura sanitaria, finanziaria o regolamentata ed è esposta a uno qualsiasi dei cinque regimi qui sopra, il passo successivo è una revisione dell’architettura (30 minuti). Mappiamo il vostro attuale flusso di consenso rispetto ai cinque requisiti, individuiamo le lacune e vi diciamo onestamente se DKMS è la risposta giusta per il vostro ambiente.

Prenotate una revisione dell’architettura del consenso (30 minuti) Scaricate la tesi sul consenso (PDF, 24 pagine)

Per il vostro settore

Applicazione del consenso nella sanità

Per saperne di più

Applicazione del consenso nella finanza

Per saperne di più

Domande frequenti

Cosa richiede l’articolo 71 dell’EHDS?
L’articolo 71 dell’EHDS (in vigore dal 26 marzo 2025) dà a ogni cittadino dell’UE il diritto di opporsi all’uso secondario dei dati sanitari identificabili. L’articolo 71(8) vieta ai detentori dei dati di acquisire dati identificativi aggiuntivi al solo scopo di onorare l’opposizione, precludendo così le implementazioni centralizzate basate su "elenchi di ID che si sono opposti": l’elenco stesso è un registro di re-identificazione vietato. Il considerando 54 impone che l’opposizione sia reversibile e in forma libera.
Perché un registro centralizzato dei consensi non può funzionare?
L’articolo 71(8) lo vieta esplicitamente. Il registro stesso diventa un archivio di re-identificazione: esattamente ciò che la norma è stata scritta per prevenire. La risposta strutturale richiede identificatori controllati dall’interessato, non un elenco centrale controllato da un operatore.
DKMS garantisce l’applicazione del consenso?
No. DKMS è il primo fondamento strutturalmente solido per onorare l’opposizione end-to-end in condizioni interorganizzative, post-divulgazione e sotto l’occhio delle autorità di controllo. Al di fuori di queste condizioni (carichi di lavoro single-tenant, derivati come i pesi di modelli ML, backup già eseguiti, singole controparti disoneste) DKMS offre rilevamento forense, non prevenzione.
Come interopera DKMS con controparti X.509 / S/MIME?
Tramite bridge S/MIME ancorati a KERI, che consentono alla revoca di propagarsi anche alle parti che usano X.509. Il bridge ancora il certificato X.509 a un AID KERI; la revoca del consenso attiva una rotazione delle chiavi dell’AID; i verificatori X.509 a valle devono recuperare di nuovo lo stato e ri-autenticare.