O Stargate transforma a infraestrutura de correio eletrónico de dependente da confiança para verificada pela confiança. Cada troca de mensagens entre organizações resolve a identidade criptográfica, estabelece o consentimento de políticas e cria um rasto de auditoria verificável — sem sobrecarga nos fluxos de trabalho nem alterações na forma como os utilizadores trabalham.
Reserve um percurso arquitetural de 30 minutosOs sistemas de confiança atuais obrigam as organizações a depender de autoridades centrais para cada verificação de identidade e cada troca de dados. A arquitetura da Vereign elimina estas dependências, permitindo a cada organização controlar a sua própria identidade criptográfica e verificar as outras diretamente. Eis como funciona na prática — da gestão de chaves à troca de dados verificada.
A sequência de 7 passos abaixo é o caminho de cada mensagem habilitada pelo Stargate — desde o momento em que o seu cliente DNS faz uma consulta até ao momento em que os dados chegam verificados e auditados ao destino.
Quando a sua aplicação resolve o domínio de uma contraparte (p. ex., hospital-b.ch), o proxy DNS do Stargate interceta a consulta antes de esta chegar ao seu resolver upstream. Este é o ponto de entrada — não são necessárias alterações ao código da aplicação. O proxy opera de forma transparente ao nível da rede.
O agente de identidade consulta o registo de identidade publicado pela contraparte via Stargate. Dois resultados: a contraparte está habilitada para o Stargate (verificação criptográfica completa) ou não (entrega padrão, mensagem marcada como não verificada). É assim que o Stargate garante retrocompatibilidade — as mensagens para contrapartes não habilitadas nunca são bloqueadas.
Se a contraparte estiver habilitada para o Stargate, é estabelecido um túnel VPN WireGuard com chaves derivadas dos registos de identidade DKMS de ambas as organizações. Estas chaves não são emitidas por uma autoridade de certificação central — são derivadas do registo de eventos de chaves KERI de cada organização. O túnel é bilateral: cada parte é autenticada pela outra de forma independente.
Antes de quaisquer dados se moverem, o motor de políticas do Stargate (Open Policy Agent, OPA) avalia se esta troca de dados está autorizada pelas políticas de ambas as partes. Para dados de saúde, o FHIR Resolver verifica o consentimento ao nível do recurso: consentimentos de pacientes, autorizações organizacionais e regulamentações setoriais (EHDS, LPD suíça) são avaliados em tempo real. Dados não autorizados pelas políticas não são transferidos.
Os seus tokens OAuth e certificados X.509 existentes continuam válidos. A ponte de compatibilidade do Stargate traduz as credenciais ancoradas no KERI para formato JWT ou X.509 no lado recetor — localmente, sem contactar qualquer autoridade externa. A sua infraestrutura de identidade não muda. O Stargate alarga-a para operar além das fronteiras organizativas.
Com o consentimento de políticas confirmado e o túnel WireGuard cifrado estabelecido, a troca de dados prossegue. O SEAL (Secure Edge Application Layer) envolve cada mensagem com uma camada de autenticidade verificável — a organização recetora pode provar quem enviou os dados, quando foram enviados e que não foram modificados em trânsito. Isto substitui a dependência do S/MIME de autoridades de certificação de terceiros por verificação bilateral derivada do DKMS.
Cada troca cria uma entrada no Key Event Log (KEL) e no Transaction Event Log (TEL) do KERI. Estes registos são à prova de adulteração e verificáveis de forma independente por qualquer parte — não apenas por um servidor de registos central. Para setores regulados, isto significa rastos de auditoria interorganizacionais criptograficamente sólidos, disponíveis sem infraestrutura centralizada.
A pilha de confiança do Stargate é concebida por camadas. Cada camada faz uma coisa bem e passa-a de forma limpa à seguinte. A infraestrutura existente liga-se à camada de compatibilidade — nada é removido.
O Stargate não é um projeto de substituição. É uma extensão da infraestrutura que já opera. A tabela abaixo mostra o que mantém e o que o Stargate adiciona.
443 violações do RGPD reportadas diariamente na Europa, com coimas acumuladas superiores a 1,2 mil milhões de EUR — DLA Piper GDPR Fines and Data Breach Survey
Esta é a pergunta certa. Três projetos bem financiados não conseguiram entregar identidade descentralizada em grande escala:
O KERI é estruturalmente diferente. Não tem dependência de blockchain. Os eventos de chaves são ancorados em registos de só adição que cada controlador mantém de forma independente — sem livro-razão partilhado, sem taxas de gás, sem governação de fundação necessária.
A validação institucional: O GLEIF — a Global Legal Entity Identifier Foundation — opera o sistema LEI global para instituições financeiras em 180 países. O GLEIF escolheu o KERI para o sistema vLEI. Isto não é uma prova de conceito. É infraestrutura de produção que verifica a identidade de instituições financeiras em todo o mundo. O Stargate assenta na mesma base KERI validada pelo GLEIF à escala institucional.
Veja como a infraestrutura de confiança verificada se aplica aos seus requisitos específicos e ao seu ambiente regulatório.
