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 minuti

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

1

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.

2

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.

3

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.

4

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.

5

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.

6

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.

7

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.

L'architettura di fiducia a cinque livelli di Stargate — identità ancorata al margine, policy al centro, compatibilità in superficie
Stargate Five-Layer Trust Architecture Stargate Five-Layer Trust Architecture Each layer handles one concern — trust flows upward from identity to audit 5 Audit KEL · TEL Tamper-evident Key Event & Transaction Event Logs Independently verifiable audit trails — no central log server 4 Compatibility JWT · X.509 · OAuth Translates KERI credentials to formats existing systems understand Stargate extends your token infrastructure — does not replace it 3 Authorization OPA · ACDC · FHIR Policy engine evaluates consent before any data moves Machine-readable data sharing agreements at infrastructure layer 2 Transport WireGuard Encrypted bilateral tunnel — keys derived from DKMS, not issued by CA No third party can intercept or revoke — each org controls its own keys 1 Identity DKMS · KERI Cryptographic root — each organization controls its own key event log PKI at the edge — no central authority, bilateral trust establishment trust flows up Foundation (sovereign) Policy centre Compatibility Audit surface

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.

Protezione dei dati svizzera Conforme al GDPR Open Source AGPLv3+ Hosting svizzero