I sistemi di identità tradizionali si fermano ai confini organizzativi. Ecco cosa li supera.

Gli strumenti di identità standard sono stati progettati per una singola organizzazione. La fiducia inter-istituzionale su scala richiede fondamenta diverse — la scelta della sanità svizzera.

Discutere questa architettura per la vostra organizzazione — senza impegno

Quattro limiti strutturali degli strumenti di identità standard

OAuth (Open Authorization) e l'infrastruttura a chiave pubblica (PKI) sono strumenti eccellenti — entro i confini di una singola organizzazione. Non sono difetti. Sono vincoli architetturali che diventano visibili quando la fiducia deve estendersi tra organizzazioni.

Fiducia dei token

Vincolo OAuth / PKI

I token OAuth sono attendibili all'interno dei confini del loro emittente. Tra organizzazioni, quel confine si rompe — l'organizzazione ricevente non ha modo di verificare l'autorità dell'organizzazione emittente.

Soluzione DKMS / Verimesh

DKMS stabilisce un'identità crittografica autocertificante — l'identità di ogni organizzazione è verificabile da qualsiasi altra organizzazione, senza dipendere da un'autorità di certificazione condivisa.

Granularità degli accessi

Vincolo OAuth / PKI

Gli scope OAuth sono approssimativi — progettati per le autorizzazioni a livello applicativo. Il consenso a livello di grafo delle risorse tra confini organizzativi richiede un modello diverso.

Soluzione DKMS / Verimesh

Il motore di policy di Verimesh (Open Policy Agent, OPA) consente un controllo degli accessi programmabile e granulare che opera attraverso i confini di fiducia organizzativi.

Verificabilità

Vincolo OAuth / PKI

I log OAuth sono organizzativi. Le tracce di audit tra organizzazioni — chi ha acceduto a cosa, quando, autorizzato da chi — richiedono un collegamento crittografico che OAuth non è stato progettato per fornire.

Soluzione DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) fornisce tracce di audit a prova di manomissione. Ogni evento di identità è collegato crittograficamente e verificabile indipendentemente, creando verificabilità tra organizzazioni.

Architettura della fiducia

Vincolo OAuth / PKI

OAuth presuppone un'autorità centrale — un provider di identità di cui tutti si fidano. La fiducia istituzionale distribuita tra organizzazioni sovrane non può dipendere da una singola autorità.

Soluzione DKMS / Verimesh

DKMS consente la gestione sovrana delle identità — ogni organizzazione controlla le proprie radici crittografiche. La fiducia viene stabilita bilateralmente, non delegata a un coordinatore centrale.

OAuth per token locali, DKMS per fiducia istituzionale scalabile

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organizational trust establishment
Infrastruttura di identità KERI — identificatori autocertificanti, ricevute di eventi chiave e fiducia bilaterale senza autorità centrale

Si tratta di un'evoluzione, non di una sostituzione. OAuth (Open Authorization) è lo strumento giusto per l'autenticazione locale all'interno dei confini di una singola organizzazione. DKMS (Decentralized Key Management System) è lo strumento giusto per la fiducia istituzionale su scala — tra organizzazioni sovrane che non condividono un provider di identità. Verimesh combina entrambi, impiegando ciascuno dove è lo strumento corretto.

Complementare ai programmi nazionali di identità elettronica

Swiyu è il programma nazionale svizzero di identità elettronica. Oggi gestisce un progetto pilota attivo in tutti i cantoni, la licenza di allievo conducente elettronica, mentre l'infrastruttura di fiducia per l'e-ID stessa dovrebbe entrare in funzione nel primo semestre del 2027. L'introduzione dell'e-ID è stata rinviata, senza che sia stata annunciata una nuova data, per cui il wallet nazionale non è ancora in produzione. Le credenziali swiyu sono emesse nel formato SD-JWT VC, con identificatori e attestazioni di fiducia pubblicati in registri federali. Per l'e-ID stessa l'emittente è lo Stato, per mandato della legge sull'e-ID del 2025, e la credenziale risiede sul dispositivo del cittadino. Altre credenziali sulla stessa infrastruttura sono emesse da cantoni, università e datori di lavoro.

Vereign è coinvolta nel processo svizzero dell'e-ID dall'inizio, attraverso riunioni di partecipazione e scambi bilaterali, e Georg Greve ha fatto parte del Technical Advisory Circle convocato da fedpol che ha preparato la decisione tecnologica del 2024.

L'Unione europea conduce il programma parallelo. L'Architecture and Reference Framework dell'EUDI prevede un wallet per i cittadini in ogni Stato membro, e anche per la credenziale d'identità fondamentale della persona l'emittente è lo Stato. Risponde alla stessa domanda, come una persona dimostra la propria identità a un'istituzione, e raggiunge lo stesso limite: non fa da ponte tra due istituzioni in giurisdizioni diverse. Verimesh è progettato per completare entrambi, non per competere con loro.

Per le organizzazioni che implementano Verimesh, i due approcci sono complementari piuttosto che concorrenti. Un wallet nazionale risponde a come una persona dimostra la propria identità a un'istituzione. Non risponde a come due istituzioni in giurisdizioni diverse si verificano a vicenda, né a cosa accade a una decisione di consenso dopo che i dati sono già stati condivisi. Verimesh mantiene il proprio livello di fiducia ed è progettato per parlare i protocolli dei wallet al margine, così un cliente Verimesh può accettare un'e-ID statale in fase di onboarding ed emettere le proprie credenziali nello stesso wallet, non appena questi sistemi saranno in produzione.

Verimesh fornisce questa architettura

Verimesh (precedentemente il progetto Stargate) è l'implementazione in produzione dell'architettura di fiducia basata su DKMS descritta sopra. Combina OAuth per l'autenticazione locale con DKMS ancorato a KERI per la fiducia interorganizzativa, un motore di policy programmabile basato su OPA, interoperabilità semantica tramite Overlays Capture Architecture (OCA) e comunicazione verificabile tramite SEAL.

SEAL, il componente di comunicazione verificabile di Verimesh, elabora già oltre 800'000 messaggi verificati al mese nella sanità svizzera. L'implementazione completa di Verimesh prosegue nel corso del 2026, scelta dalla sanità svizzera come futura infrastruttura di fiducia.

Scopra Verimesh

Una sola radice, dall'applicazione fino al cavo

La mesh di Verimesh funziona su WireGuard e la chiave del tunnel condivide la stessa radice dell'identità applicativa. Le chiavi Curve25519 del tunnel di ciascuna organizzazione derivano dal suo stesso materiale Decentralized Key Management (DKMS) — nessuna autorità centrale le emette e non esiste alcuno scarto tra l'identità a livello di rete e quella a livello applicativo. La rotazione delle chiavi è coordinata con DKMS (pre-rotazione costruita su KERI) e ogni stabilimento di tunnel è verificabile rispetto al Key Event Log. Nessun intermediario possiede il flusso dei dati.

Silenzioso per progettazione

I pacchetti non autenticati non ricevono risposta. La mesh è invisibile a una scansione delle porte — non c'è alcuna superficie di attacco pubblica da sondare.

Circa 4.000 righe che si possono leggere

WireGuard conta all'incirca 4.000 righe di codice, contro circa 100.000 per OpenVPN e 400.000 per IPsec. La verificabilità è di per sé una proprietà di sicurezza.

Nessuna negoziazione, nessun downgrade

Primitive moderne e fisse — Curve25519, ChaCha20-Poly1305, BLAKE2s, l'handshake Noise_IKpsk2. Perfect forward secrecy con rinnovo delle chiavi ogni due minuti circa e occultamento dell'identità sono integrati, non configurati.

Sovrana fino al cavo

Open Source da un capo all'altro, self-hosted, senza alcun piano di controllo SaaS sul percorso. La sovranità si estende dall'applicazione fino al trasporto stesso.

Infrastruttura collaudata, senza sorprese

Nel kernel Linux mainline dal 2020 — lo stesso protocollo raccomandato da fornitori di sicurezza come Palo Alto Networks. Sostiene l'implementazione di Verimesh con HIN già oggi.

Pronta per la migrazione quantistica

Il livello a chiave pre-condivisa di WireGuard protegge già il traffico di oggi dagli attacchi «memorizza ora, decifra dopo». E poiché le chiavi del tunnel derivano da DKMS, il passaggio agli algoritmi post-quantistici diventa una rotazione delle chiavi di routine sul Key Event Log esistente — non una riemissione massiva di tutte le chiavi in un colpo solo.

Veda l'intero ciclo di vita della connessione

L'applicazione del consenso è lo scopo fondamentale di DKMS

L'articolo 71(8) dell'EHDS crea un vincolo strutturale che nessuna autorità centrale può soddisfare: quando una persona revoca il consenso all'uso secondario, tale revoca deve propagarsi a ogni istituzione che detiene o ha derivato dati dalla fonte originale. Nessuna CA può co-firmare la revoca; nessun fornitore di identità può cascadare la revoca. Questo vincolo è architetturalmente incompatibile con l'identità centralizzata.

DKMS soddisfa cinque invarianti richiesti dall'articolo 71 dell'EHDS: identificatori legati alla persona che sopravvivono a una nuova registrazione; record di revoca verificabili e con marca temporale, ancorati nel Key Event Log; reversibilità senza re-identificazione; propagazione tra controller senza accordi bilaterali tra ogni coppia di istituzioni; e impossibilità di collegare il record del consenso ai dati che copre.

Dopo che i dati sono stati divulgati — condivisi in una rete ospedaliera, un consorzio di ricerca o una catena di pagatori — una revoca successiva del consenso deve comunque raggiungere ogni responsabile del trattamento a valle. I Key Event Log di DKMS propagano la revoca in modo crittografico: il KEL di ogni responsabile è append-only e attestato, quindi una revoca aggiunta all'edge della persona diventa verificabile in ogni istituzione che detiene un record derivato.

Leggere la tesi sull'architettura del consenso

Collaudato nella sanità svizzera — scelto per l'implementazione su scala nazionale

HIN — Health Info Net — è la rete svizzera di informazione sanitaria, che collega ospedali, studi di medicina generale e specialisti oltre i confini cantonali. SEAL, il componente di comunicazione verificabile costruito su questa architettura di fiducia, elabora già oltre 800'000 messaggi verificati al mese. L'implementazione completa di Verimesh con scambio di dati strutturati prosegue nel corso del 2026.

HIN — Health Info Net

800.000+

messaggi verificati al mese

850+

gateway nella sanità svizzera

30.000+

studi medici e istituzioni sanitarie

Architettura di fiducia — domande frequenti

Cos'è DKMS?
DKMS (Decentralised Key Management) è la categoria di infrastruttura di identità in cui la fiducia crittografica è ancorata al confine organizzativo, non in un'autorità di certificazione centrale. Ogni organizzazione controlla il proprio materiale crittografico e il proprio Key Event Log (KEL) append-only. Vereign ha co-fondato la DKMS Alliance per formalizzare DKMS come categoria accanto a PKI e OAuth.
In che modo DKMS è diverso da PKI?
PKI ancora la fiducia a Certificate Authority centrali — una singola compromissione di una CA ha impatto su ogni soggetto che la CA ha firmato. DKMS ancora la fiducia nel Key Event Log di ciascuna organizzazione: un guasto resta limitato a un singolo controller, la rotazione delle chiavi è nativa e atomica tramite gli impegni di pre-rotation, e la fiducia tra giurisdizioni non richiede trattati di riconoscimento CA-to-CA. DKMS è PKI al margine, senza il single point of failure.
DKMS sostituisce OAuth?
No. OAuth è corretto per i flussi di token locali all'interno di una singola organizzazione e va continuato a usare lì. DKMS risolve un problema per cui OAuth non è mai stato progettato: stabilire fiducia verificabile fra organizzazioni senza un intermediario condiviso. I due sono complementari — OAuth per i token locali, DKMS per la fiducia istituzionale scalabile.
DKMS è pronto per il post-quantistico?
Sì. DKMS tratta la rotazione delle chiavi come un'operazione di prima classe. Quando servono algoritmi post-quantistici, la migrazione diventa una rotazione di chiavi di routine sul Key Event Log esistente, non una riemissione massiva di certificati. La proprietà di pre-rotation di KERI significa che la chiave successiva può essere qualsiasi algoritmo il controller si impegni a usare — inclusi schemi post-quantistici — senza rompere le relazioni di fiducia esistenti.
Chi mantiene DKMS?
DKMS è una specifica aperta. La DKMS Alliance — co-fondata da Vereign — coordina la specifica. L'implementazione di riferimento di KERI (il protocollo alla base di DKMS) è mantenuta come open source dalla comunità KERI più ampia. Verimesh e SEAL di Vereign sono implementazioni AGPLv3+ del livello DKMS, in produzione nella sanità svizzera.
DKMS richiede una blockchain?
No. DKMS usa Key Event Log (KEL) concatenati tramite hash per l'integrità append-only, ma non c'è livello di consenso, token né ledger distribuito. La scelta di evitare la blockchain è deliberata — l'infrastruttura regolamentata richiede verifica deterministica, non finalità probabilistica.
Vereign può aiutarmi a integrare il wallet swiyu o EUDI?
Sì. Vereign è il livello di fiducia istituzionale che completa i wallet nazionali di e-ID, non un concorrente. Un wallet nazionale (swiyu, EUDI) dimostra chi è una persona di fronte a un'istituzione. Verimesh risponde al confine che quei wallet non coprono: come due istituzioni si verificano direttamente, tra giurisdizioni, incluse le persone, i ruoli e gli agenti che agiscono al loro interno, e cosa accade a una decisione di consenso dopo che i dati sono stati condivisi.
Vereign è un concorrente dei wallet nazionali?
No. Verimesh è progettato per completare swiyu ed EUDI piuttosto che competere con loro. Un wallet nazionale risponde a come una persona dimostra la propria identità a un'istituzione; non risponde a come due istituzioni in giurisdizioni diverse si verificano a vicenda, né a cosa accade a una decisione di consenso dopo la condivisione dei dati. Verimesh mantiene il proprio livello di fiducia ed è progettato per parlare i protocolli dei wallet al margine.
Il ponte Verimesh verso swiyu o EUDI è in produzione?
No. I componenti del ponte (un provider OID4VCI/VP, l'esportazione di credenziali, la mappatura degli identificatori) sono architetturali, dimostrati a livello di progettazione, non consegnati. Verimesh stesso è in produzione nella sanità svizzera: il gateway e la CA centrale presso HIN sono in produzione, i primi clienti sono migrati e li utilizzano, e la migrazione sulla rete HIN dovrebbe completarsi entro la fine del 2026.

Prenoti una revisione architetturale — mappa i Suoi confini di fiducia.

Questa architettura è implementata nella sanità svizzera su scala nazionale. Che stia valutando alternative all'identità centralizzata o pianificando lo scambio di dati interorganizzativo, lo mapperemo nel Suo ambiente in una chiamata di 30 minuti.

Prenoti una revisione architetturale
Protezione dei dati svizzera Conforme al GDPR Open Source AGPLv3+ Hosting svizzero
Veda come l'architettura funziona passo dopo passo