Architettura del consenso

Il consenso non è una casella da spuntare.

Il GDPR lo impone dal 2018; EHDS Article 71 lo ha reso esecutivo lo scorso anno. Decentralized Key Management è l'unica architettura in grado di onorare il ritiro del consenso oltre 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ù una questione di buona volontà organizzativa. In tutta Europa e in Svizzera, cinque regimi normativi distinti hanno reso il diritto di opposizione un obbligo legale vincolante — e ciascuno è stato redatto indipendentemente dagli altri. Condividono una caratteristica: presuppongono che il titolare del trattamento possa cessare di utilizzare dati identificabili su richiesta, propagare tale cessazione a tutte le parti a valle e dimostrarlo in seguito. L\'infrastruttura di identità centralizzata non è mai stata progettata per garantire nessuna di queste condizioni.

  • EHDS Article 71

    In vigore dal 26 marzo 2025

    Il diritto di opposizione come diritto legale; Article 71(8) preclude i registri di re-identificazione; Recital 54 impone la reversibilità.

  • GDPR Art 7(3) + Art 17(2)

    In vigore dal 25 maggio 2018

    La revoca deve essere semplice quanto il rilascio del consenso; i titolari del trattamento devono propagare la cancellazione a ogni destinatario a valle.

  • eIDAS 2.0 Article 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à a carico delle parti che si affidano al sistema.

  • FADP svizzera / revisione HFG

    FADP in vigore dal 1 settembre 2023; emendamento HFG in consultazione

    Obbligo di revoca del consenso per l\'uso secondario nella ricerca; divieto esplicito di re-identificazione di dati pseudonimizzati.

  • PDSG tedesco

    In vigore dal 20 ottobre 2020

    Accesso controllato dal paziente ai fascicoli ePA; diritto di opposizione granulare per categoria di dati, applicabile trasversalmente ai provider.

Ciascuno da solo è gestibile. Insieme rendono l\'architettura CA centralizzata insufficiente.

I cinque invarianti ingegneristici

Si leggano i cinque regimi come farebbe un ingegnere. Si elimini il linguaggio giuridico e ciò che rimane è un elenco di cinque invarianti tecnici che l\'infrastruttura di implementazione deve soddisfare. Nessuno di essi è facoltativo. Nessuno viene negoziato via da un ragionevole linguaggio contrattuale. Ciascuno è nominato, per clausola, nel diritto primario.

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Confronto: quale architettura soddisfa quale invariante ingegneristico. X.509 soddisfa zero. La federazione soddisfa zero (la propagazione solo violando la non collegabilità). DKMS soddisfa tutti e cinque. Invariante ingegneristico X.509 PKI IAM federata DKMS Identificatori a portata personale ✗ i ✗ ✓ Opposizione verificabile con marca temporale ✗ ✗ ✓ Reversibilità senza re-identificazione ✗ ✗ ✓ Propagazione tra titolari del trattamento ✗ i ✗ i ✓ i Non collegabilità ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Fare clic su una (i) per il ragionamento · Fare clic per espandere il diagramma

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Confronto: quale architettura soddisfa quale invariante ingegneristico. X.509 soddisfa zero. La federazione soddisfa zero (la propagazione solo violando la non collegabilità). DKMS soddisfa tutti e cinque. Invariante ingegneristico X.509 PKI IAM federata DKMS Identificatori a portata personale ✗ i ✗ ✓ Opposizione verificabile con marca temporale ✗ ✗ ✓ Reversibilità senza re-identificazione ✗ ✗ ✓ Propagazione tra titolari del trattamento ✗ i ✗ i ✓ i Non collegabilità ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Perché X.509 non può fornire identificatori a portata personale

X.509 identifica le entità tramite certificati emessi da una Certificate Authority, non tramite chiavi controllate dal soggetto. Il cittadino non ha alcuna agency architetturale a livello della radice di fiducia — la CA decide chi è chi. EHDS Recital 54 ed eIDAS 2.0 Article 5a richiedono identificatori controllati dal soggetto; X.509 soddisfa tale 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

X.509 non dispone di una primitiva nativa di propagazione. La revoca si diffonde tramite CRL e responder OCSP che ogni verificatore deve scegliere esplicitamente di consultare — e non esiste un modo per inviare una revoca a ritroso ai dati già condivisi. Una volta che un certificato ha firmato l'autorizzazione per un flusso di dati, la revoca 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 si affidano al sistema possono correlare lo stesso soggetto tra transazioni confrontando i numeri di serie. La pseudonimizzazione richiede una nuova emissione, operativamente onerosa — la collegabilità è qui una scelta di progettazione, non un difetto.

Perché la federazione soddisfa solo parzialmente la propagazione

L'IAM federata soddisfa la propagazione tra titolari del trattamento solo violando la non collegabilità — il provider di identità registra ogni accesso alle parti che si affidano al sistema, creando una superficie di correlazione cross-RP vietata (eIDAS 2.0 Art 5a(16)(b)). 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 a ogni parte che si affida al sistema. Anche se le credenziali individuali sono pseudonime, l'IdP detiene per costruzione il grafo di correlazione cross-RP. eIDAS 2.0 Article 5a(16)(b) vieta precisamente questa superficie.

Come DKMS propaga la revoca

Le autorizzazioni si concatenano al Key Event Log (KEL) del soggetto. Quando il soggetto ruota le chiavi, ogni verificatore a valle che ri-controlla il KEL al momento del trattamento vede la rotazione e tratta le credenziali obsolete come non valide. Nessun push dell'operatore, nessun registro centrale — la propagazione è verifier-pull al momento dell'utilizzo.

Come DKMS preserva la non collegabilità

I soggetti possono coniare una nuova AID per ciascuna parte che si affida al sistema. Il KEL dietro ogni AID è indipendente — non esiste alcun registro centrale di identità e nessun IdP che veda ogni transazione. La correlazione cross-RP richiede che il soggetto colleghi deliberatamente le AID.

  1. Identificatori a portata personale

    L\'identificatore controllato dall\'interessato deve essere la radice di fiducia, non un identificatore emesso da una parte che si affida al sistema. EHDS Recital 54 e eIDAS 2.0 Article 5a lo enunciano entrambi direttamente: il cittadino deve poter agire senza che il titolare del trattamento debba cercarlo in un registro separato. Ogni architettura che dipende dall\'emissione e dall\'archiviazione dell\'identificatore da parte del titolare fallisce qui fin dal primo giorno.

  2. Opposizione verificabile con marca temporale

    La revoca deve essere un evento firmato crittograficamente e con marca temporale che il regolatore (e un futuro tribunale) possa verificare senza dover fidarsi dei log del titolare. GDPR Article 7(3) lo rende esplicito: il titolare porta l\'onere della prova. Una riga in un database interno non costituisce prova in alcun contesto in cui il titolare è il convenuto.

  3. Reversibilità senza re-identificazione

    Recital 54 dell\'EHDS impone che l\'opposizione rimanga reversibile — il cittadino può revocarla — senza che nessuno debba re-identificare i record sottostanti. Ciò richiede che l\'opposizione operi su una credenziale controllata dal soggetto, non su una tabella di mapping lato server. I registri di consenso centralizzati falliscono strutturalmente qui.

  4. Propagazione tra titolari del trattamento

    GDPR Article 17(2) e EHDS Article 71 richiedono entrambi che la revoca si propaghi a ogni destinatario a valle. In pratica, ciò significa che il titolare originario non può semplicemente aggiornare la propria riga locale — ogni parte che abbia mai ricevuto i dati deve ri-autenticare l\'autorizzazione e verificare che sia stata revocata. La federazione può farlo solo condividendo identificatori, il che viola l\'invariante successivo.

  5. Non collegabilità

    eIDAS 2.0 Article 5a richiede che le parti che si affidano al sistema non possano correlare lo stesso cittadino tra transazioni separate senza consenso. Article 71(8) dell\'EHDS preclude l\'identificatore interorganizzativo centralizzato che renderebbe banale la propagazione federata. I due invarianti insieme — propagare, ma non correlare — sono ciò che elimina le architetture convenzionali.

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

La trappola dell\'Article 71(8)

La risposta ingegneristica intuitiva a "onorare l\'opposizione attraverso la rete" è mantenere un elenco di identificatori che hanno espresso opposizione — un registro centralizzato di non-trattamento che ogni sistema a valle consulta prima di accedere a un record. Article 71(8) dell\'EHDS vieta specificamente esattamente questa costruzione. La clausola proibisce ai titolari dei dati di acquisire o conservare ulteriori dati identificativi al solo scopo di onorare le opposizioni.

Il ragionamento, reso esplicito nel Recital 54, è che il registro stesso diventa un database di re-identificazione — il danno preciso che la normativa intendeva prevenire. Non appena si mantiene un elenco di "persone che hanno espresso opposizione", si è ricostruito il punto centrale di vulnerabilità. L\'implicazione strutturale è inevitabile: il segnale di opposizione deve viaggiare con una credenziale controllata dal soggetto, non in un elenco mantenuto dal titolare.

The DKMS thesis DKMS è la risposta

Decentralized Key Management è il primo fondamento strutturalmente solido per onorare il ritiro del consenso end-to-end in condizioni interorganizzative, post-divulgazione, sotto vigilanza regolatoria.

(Decentralized Key Management 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 collegano crittograficamente, non a un account emesso dal titolare.
  2. Ogni autorizzazione è ancorata nel Key Event Log (KEL) dell'AID — un registro append-only con hash collegati che il soggetto può dimostrare unilateralmente.
  3. La revoca è una rotazione di chiavi che il soggetto esegue autonomamente. La vecchia chiave viene invalidata; l\'evento di rotazione è firmato e ha marca temporale nel KEL.
  4. Le parti a valle che detengono credenziali obsolete devono ri-autenticarsi rispetto all\'ultimo stato del KEL. La revoca si propaga fallendo in modo chiuso presso ogni verificatore a valle.

Nulla nel protocollo richiede un operatore centrale. Nulla richiede che le parti che si affidano al sistema condividano identificatori. Nulla richiede che il regolatore si fidi dei log del titolare più di quelli del soggetto. Ciascuno dei cinque invarianti è soddisfatto per costruzione, non per audit.

Dove DKMS domina — e dove non offre benefici

L\'onestà sull\'ambito è ciò che rende la tesi difendibile. DKMS domina quattro condizioni: flussi di dati interorganizzativi, revoca post-divulgazione, trattamento sotto vigilanza regolatoria e controparti avversariali. Al di fuori di tali condizioni — carichi di lavoro a tenant singolo, artefatti derivati come pesi di modelli ML addestrati, backup già effettuati prima della revoca e controparti singole disoneste che agiscono da sole — DKMS fornisce rilevamento forense ma non prevenzione.

Dove DKMS domina Dove DKMS non offre benefici Flussi di dati interorganizzativi Fare clic su una riga per il ragionamento Persistenza del consenso post-divulgazione Fare clic su una riga per il ragionamento Custodia determinativa del regolatore Fare clic su una riga per il ragionamento Le parti compongono DKMS end-to-end Fare clic su una riga per il ragionamento Derivati (analitiche, pesi ML) Fare clic su una riga per il ragionamento Backup già effettuati Fare clic su una riga per il ragionamento Controparte singola disonesta Fare clic su una riga per il ragionamento Carichi di lavoro a tenant singolo Fare clic su una riga per il ragionamento Dove DKMS domina — e dove non offre benefici. Fare clic su una riga per il ragionamento.

Flussi di dati interorganizzativi

La cancellazione lato operatore non può raggiungere i dati già condivisi con le parti a valle. DKMS estende la chiave controllata dal titolare lungo la catena di trattamento — ogni ricevente ri-controlla il KEL al momento dell'utilizzo. Il CMK centralizzato fornisce la cancellazione solo all'interno del confine di tenancy dell'operatore.

Persistenza del consenso post-divulgazione

EUDIW ARF §6.6 riconosce esplicitamente che la revoca non annulla retroattivamente un trattamento lecito pregresso. DKMS riduce questo divario: i verificatori ri-controllano il KEL pubblicato al momento del trattamento, rendendo le credenziali obsolete verificabili come tali. Il primitivo architetturale è gestito dal titolare, non dall'operatore.

Custodia determinativa del regolatore

Schrems II / EDPB Recommendations 01/2020 Use Case 3 richiedono che l'importatore dei dati NON detenga le chiavi. Il CMK centralizzato fallisce per definizione questo test (ad es. dati sanitari USA in Azure sotto accesso FISA 702). DKMS rende la custodia delle chiavi una proprietà lato titolare — l'importatore non può decifrare senza il continuo stato KEL del titolare.

Le parti compongono DKMS end-to-end

L'architettura è rilevante solo quando tutte le parti la applicano. Un verificatore che ignora il KEL annulla la catena. Quando tutte le parti compongono DKMS, la revoca si propaga tramite semplice ri-verifica — nessun operatore deve "spingere" la cancellazione.

Derivati (analitiche, pesi ML)

EDPB Opinion 28/2024 conferma esplicitamente che gli obblighi di cancellazione non si propagano chiaramente ai pesi dei modelli una volta completato l'addestramento. DKMS non offre una copertura migliore del CMK in questo ambito. La revoca non può annullare retroattivamente output analitici o report normativi già depositati.

Backup già effettuati

Nessuna architettura può richiamare dati già replicati su supporti di backup offline o immutabili. La crittografia a riposo insieme alla distruzione delle chiavi gestisce i residui entro la finestra di retention; non recupera archivi a lungo termine. DKMS non modifica questa proprietà fondamentale.

Controparte singola disonesta

DKMS fornisce rilevamento forense (le firme successive a una rotazione di chiavi pubblicata sono verificabili come obsolete) ma non prevenzione. Un sub-responsabile del trattamento interamente non cooperativo che decifra il testo in chiaro e lo archivia al di fuori dell'involucro con chiave annulla la catena — DKMS evidenzia la violazione anziché bloccarla.

Carichi di lavoro a tenant singolo

Per SaaS sotto un unico titolare, la cancellazione crittografica tramite CMK centralizzato secondo NIST SP 800-88 §2.5 è adeguata e più semplice. Passare a DKMS aggiunge onere operativo senza alcun beneficio architetturale in assenza di confini tra domini di fiducia distinti.

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

Prova in produzione

HIN — Health Info Net — è la dorsale svizzera dell'informazione sanitaria, che collega ospedali, cliniche e fornitori specialistici oltre i confini cantonali. SEAL, il livello di consegna e-mail verificabile che Vereign fornisce all'interno di HIN, è oggi in produzione e veicola oltre 800.000 messaggi verificati al mese — la prova che Vereign opera già un'infrastruttura di livello produttivo all'interno della sanità svizzera.

Stargate, il runtime di Decentralized Key Management che porta in esercizio operativo il meccanismo di opt-out in quattro passi descritto sopra, entra in produzione iniziale a giugno 2026.

Il livello FHIR di Stargate — le stesse garanzie applicate allo scambio di cartelle cliniche, non solo ai messaggi — è oggi architetturale. Portarlo in produzione dipende dall'onboarding lato ospedale; la data più realistica è settembre 2026.

Cinque incidenti che dimostrano il modello strutturale

  1. Kaiser Foundation Health Plan — accordo transattivo collettivo da USD 47,5M (2026). I dati del portale pazienti sono stati divulgati a piattaforme pubblicitarie tramite pixel di tracciamento incorporati. L\'architettura non prevedeva alcun meccanismo per cui il soggetto potesse revocare la propagazione a valle.
  2. Sutter Health — accordo transattivo collettivo da USD 21,5M (2026). Stesso schema: tag di terze parti lato portale, nessun primitivo di revoca controllato dal soggetto, nessun modo per dimostrare il non-trattamento a posteriori.
  3. NHS National Data Opt-Out (2021) — ammissione di non-retroattività; il programma GPDPR è stato ritardato perché l\'architettura non riusciva a onorare la revoca rispetto ai 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 privo di confini crittografici a livello paziente. Non c\'era nulla che il soggetto potesse revocare; non c\'era alcuna chiave da ruotare.
  5. DigiNotar (2011) — la compromissione della CA radice ha indotto i browser a revocare la fiducia in tutti i certificati emessi da quella CA. I soggetti non avevano alcuna agency architetturale: i loro identificatori e le relazioni di fiducia erano interamente controllati dall\'operatore.

Ogni incidente centralizzato condivide una caratteristica: l\'utente non aveva agency architetturale.

Da dove iniziare

Se la Sua organizzazione tratta dati personali sanitari, finanziari o regolamentati identificabili ed è esposta a uno qualsiasi dei cinque regimi sopra descritti, il passo successivo è una revisione dell\'architettura di 30 minuti. Mappiamo il Suo attuale flusso di consenso rispetto ai cinque invarianti, identifichiamo le lacune e Le diciamo onestamente se DKMS è la risposta giusta per il Suo ambiente.

Prenoti una revisione dell\'architettura del consenso di 30 minuti Scarichi la tesi sul consenso (PDF, 24 pagine)

Per il Suo settore

Applicazione del consenso in sanità

Per saperne di più

Applicazione del consenso in finanza

Per saperne di più

Domande frequenti

Cosa richiede EHDS Article 71?
EHDS Article 71 (in vigore dal 26 marzo 2025) conferisce a ogni cittadino dell\'UE il diritto di opporsi all\'uso secondario di dati sanitari identificabili. Article 71(8) vieta ai titolari dei dati di acquisire ulteriori dati identificativi al solo scopo di onorare l\'opposizione — precludendo le implementazioni centralizzate basate su "elenchi di ID che hanno espresso opposizione", perché l\'elenco stesso costituisce un registro di re-identificazione vietato. Recital 54 impone che l\'opposizione sia reversibile e in forma libera.
Perché un registro di consenso centralizzato non può funzionare?
Article 71(8) lo vieta esplicitamente. Il registro stesso diventa un record di re-identificazione — esattamente ciò che la normativa intendeva prevenire. La risposta strutturale richiede identificatori controllati dal soggetto, non un elenco controllato da un operatore centrale.
DKMS garantisce l\'applicazione del consenso?
No. DKMS è il primo fondamento strutturalmente solido per onorare il ritiro del consenso end-to-end in condizioni interorganizzative, post-divulgazione, sotto vigilanza regolatoria. Al di fuori di tali condizioni — carichi di lavoro a tenant singolo, derivati come pesi di modelli ML, backup già effettuati, controparti singole disoneste — DKMS fornisce rilevamento forense ma non prevenzione.
Come interopera DKMS con controparti X.509 / S/MIME?
Tramite bridge S/MIME ancorati a KERI che consentono alla revoca di propagarsi alle parti che utilizzano X.509. Il bridge ancora il certificato X.509 a un AID KERI; la revoca del consenso attiva la rotazione della chiave AID; i verificatori X.509 a valle devono ri-acquisire e ri-autenticare.