Dalla query DNS allo scambio di dati verificato — in millisecondi.
Stargate trasforma l'infrastruttura di posta elettronica da dipendente dalla fiducia a verificata dalla fiducia. Ogni scambio di messaggi tra organizzazioni risolve l'identità crittografica, stabilisce il consenso alle politiche e crea una traccia di audit verificabile — senza oneri aggiuntivi per gli utenti.
Prenota un percorso architetturale di 30 minutiGli attuali sistemi di fiducia costringono le organizzazioni a dipendere da autorità centrali per ogni verifica di identità e ogni scambio di dati. L'architettura di Vereign elimina queste dipendenze, consentendo a ogni organizzazione di controllare la propria identità crittografica e verificare le altre direttamente. Ecco come funziona nella pratica, dalla gestione delle chiavi allo scambio di dati verificato.
Cosa succede quando invii un messaggio
La sequenza in 7 fasi di seguito è il percorso di ogni messaggio Stargate — dal momento in cui il tuo client DNS emette una query al momento in cui i dati arrivano verificati e auditati a destinazione.
Fase 1: Il proxy DNS intercetta la query
Quando la tua applicazione risolve il dominio di una controparte (es. ospedale-b.ch), il proxy DNS di Stargate intercetta la query prima che raggiunga il resolver upstream. Questo è il punto di ingresso — nessuna modifica al codice applicativo richiesta. Il proxy opera in modo trasparente a livello di rete.
Fase 2: L'agente di identità verifica lo stato della controparte
L'agente di identità interroga il record di identità pubblicato dalla controparte tramite Stargate. Due esiti: la controparte è abilitata a Stargate (verifica crittografica completa) oppure no (consegna standard, messaggio contrassegnato come non verificato). Così Stargate garantisce la retrocompatibilità — i messaggi verso controparti non-Stargate non vengono mai bloccati.
Fase 3: Tunnel WireGuard stabilito con chiavi derivate dal DKMS
Se la controparte è abilitata a Stargate, viene stabilito un tunnel VPN WireGuard con chiavi derivate dai record di identità DKMS di entrambe le organizzazioni. Queste chiavi non sono emesse da un'autorità di certificazione centrale — sono derivate dal log eventi KERI di ciascuna organizzazione. Il tunnel è bilaterale: ciascuna parte autentica l'altra in modo indipendente.
Fase 4: Il motore di policy valuta il consenso
Prima che qualsiasi dato si muova, il motore di policy di Stargate (Open Policy Agent, OPA) valuta se questo scambio è autorizzato dalle policy di entrambe le parti. Per i dati sanitari, il FHIR Resolver verifica il consenso a livello di risorsa: consensi dei pazienti, autorizzazioni organizzative e normative di settore (EHDS, LPD svizzero) sono valutati in tempo reale. I dati non autorizzati dalle policy non vengono trasferiti.
FHIR-over-Stargate è architetturale — il dispiegamento in produzione dipende dall'onboarding degli ospedali; data plausibile più precoce: settembre 2026.
Leggere perché questa architettura è necessaria, non solo migliore →
Fase 5: Token tradotto localmente
I tuoi token OAuth e certificati X.509 esistenti rimangono validi. Il bridge di compatibilità di Stargate traduce le credenziali KERI-ancorate in formato JWT o X.509 sul lato ricevente — localmente, senza contattare autorità esterne. La tua infrastruttura di identità non cambia. Stargate la estende per operare oltre i confini organizzativi.
Fase 6: Scambio di dati sulla mesh cifrata
Con il consenso alle policy confermato e il tunnel WireGuard cifrato stabilito, lo scambio di dati avviene. SEAL (Secure Edge Application Layer) avvolge ogni messaggio con uno strato di autenticità verificabile — l'organizzazione ricevente può dimostrare chi ha inviato i dati, quando sono stati inviati e che non sono stati modificati in transito. Questo sostituisce la dipendenza di S/MIME da autorità di certificazione terze con verifica bilaterale derivata da DKMS.
Fase 7: Traccia di audit registrata in KEL/TEL
Ogni scambio crea una voce nel Key Event Log (KEL) e nel Transaction Event Log (TEL) di KERI. Questi log sono a prova di manomissione e verificabili in modo indipendente da qualsiasi parte — non solo da un server di log centrale. Per i settori regolamentati, significa tracce di audit inter-organizzative crittograficamente solide, disponibili senza infrastruttura centralizzata.
Cinque livelli di infrastruttura di fiducia
Lo stack di fiducia di Stargate è progettato a livelli. Ogni livello fa una cosa bene e passa in modo pulito al successivo. L'infrastruttura esistente si collega al livello di compatibilità — nulla viene rimosso.
Cosa resta. Cosa cambia.
Stargate non è un progetto di sostituzione. È un'estensione dell'infrastruttura che già operi. La tabella seguente mostra cosa mantieni e cosa Stargate aggiunge.
443 violazioni GDPR segnalate quotidianamente in Europa, con sanzioni cumulative superiori a 1,2 miliardi di EUR — DLA Piper GDPR Fines and Data Breach Survey
Cosa resta
- ✓OAuth 2.0 / OIDC — continua a gestire l'autenticazione interna e l'emissione di token locali. Nessuna modifica richiesta.
- ✓Certificati X.509 — rimangono validi. Il bridge KERI-a-X.509 traduce al confine senza toccare la tua PKI.
- ✓JWT — il tuo formato token è invariato. Stargate produce credenziali verificabili ancorate a KERI che si traducono in JWT sul lato ricevente.
- ✓SMTP / DKIM / DMARC — il routing e-mail e l'infrastruttura anti-spam rimangono in place. SEAL aggiunge un livello di autenticità verificabile sopra DKIM, non al posto di esso.
- ✓Flussi di lavoro esistenti — gli utenti finali inviano e-mail come prima. La verifica della fiducia è invisibile per loro.
Cosa cambia
- →Dipendenza da autorità di certificazione centralizzata — sostituita da derivazione di chiavi bilaterale ancorata nel DKMS. Nessuna terza parte può revocare la capacità comunicativa della tua organizzazione.
- →E-mail con fiducia al primo utilizzo — sostituita da identità organizzativa verificata crittograficamente ad ogni scambio. Gli attacchi di phishing e impersonazione sono strutturalmente prevenuti.
- →Flussi di consenso manuali — sostituiti da consenso valutato dal motore di policy (OPA). Gli accordi di condivisione dati sono leggibili da macchina e applicati a livello infrastrutturale.
- →Tracce di audit frammentate — sostituite da record KEL/TEL crittograficamente collegati, verificabili indipendentemente oltre i confini organizzativi.
Altri hanno tentato l'identità decentralizzata. Cosa cambia qui?
Questa è la domanda giusta. Tre progetti ben finanziati non sono riusciti a consegnare l'identità decentralizzata su larga scala:
- Sovrin — La Fondazione Sovrin ha esaurito il capitale operativo nel 2023. La sua blockchain Hyperledger Indy richiedeva coordinamento continuo dei nodi validatori e una fondazione finanziata. Il fallimento non era tecnico — era di governance ed economico.
- uPort — Il progetto di identità di ConsenSys è stato ribattezzato Serto, poi ha abbandonato il campo dell'identità. uPort si basava su Ethereum, il che significava commissioni gas e latenza di transazione on-chain per ogni operazione di identità. La gestione dell'identità su scala di produzione non è economicamente sostenibile su una blockchain pubblica.
- Jolocom — Ha abbandonato l'infrastruttura di identità dopo non aver raggiunto l'adozione in produzione. Il modello di fallimento comune: dipendenza da infrastruttura blockchain che non può scalare economicamente.
KERI è strutturalmente diverso. Non ha dipendenze blockchain. Gli eventi chiave sono ancorati in log append-only che ogni controller mantiene indipendentemente — nessun registro condiviso, nessuna commissione gas, nessuna governance di fondazione richiesta.
La validazione istituzionale: GLEIF — la Global Legal Entity Identifier Foundation — gestisce il sistema LEI globale per istituzioni finanziarie in 180 paesi. GLEIF ha scelto KERI per il sistema vLEI. Non è una prova di concetto. È un'infrastruttura di produzione che verifica l'identità di istituzioni finanziarie globalmente. Stargate si basa sulla stessa fondazione KERI che GLEIF ha validato a scala istituzionale.
Desidera capire come questo si applica alla Sua organizzazione?
Scopra come l'infrastruttura di fiducia verificata si applica ai Suoi requisiti specifici e al Suo contesto normativo.