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 / Stargate

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 / Stargate

Il motore di policy di Stargate (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 / Stargate

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 / Stargate

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à. Stargate combina entrambi, impiegando ciascuno dove è lo strumento corretto.

Allineato con il programma nazionale eID della Svizzera

Swiyu è il programma nazionale svizzero di identità elettronica, attualmente in fase di sviluppo. Si basa sullo stesso modello di Self-Sovereign Identity (SSI) e fiducia decentralizzata che è alla base di Stargate e SEAL. Non è una coincidenza — gli stessi principi architetturali che risolvono la fiducia istituzionale su larga scala vengono ora adottati a livello nazionale.

Vereign è coinvolta nel processo di consultazione Swiyu fin dalle prime fasi. Georg Greve ha fatto parte del Swiyu Technical Advisory Council, contribuendo con esperienza pratica dall'implementazione DKMS su scala produttiva nella sanità svizzera. Questo coinvolgimento diretto garantisce che l'architettura di Vereign rimanga allineata con l'infrastruttura regolatoria e identitaria in evoluzione della Svizzera.

Per le organizzazioni che implementano Stargate oggi, l'allineamento con Swiyu significa che la loro infrastruttura di fiducia è a prova di futuro rispetto alla direzione regolatoria svizzera. Le decisioni architetturali sono compatibili — le organizzazioni non stanno costruendo solo per i requisiti di oggi, ma per l'ambiente di fiducia che la Svizzera sta sviluppando.

Stargate fornisce questa architettura

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 Stargate, elabora già oltre 800'000 messaggi verificati al mese nella sanità svizzera. L'implementazione completa di Stargate prosegue nel corso del 2026, scelta dalla sanità svizzera come futura infrastruttura di fiducia.

Scopra Stargate

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 Stargate 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. Stargate 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.

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