Da consulta DNS à troca de dados verificada — em milissegundos.
O Verimesh 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.
O que acontece quando envia uma mensagem
A sequência de 7 passos abaixo é o caminho de cada mensagem habilitada pelo Verimesh — 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.
Passo 1: O proxy DNS interceta a consulta
Quando a sua aplicação resolve o domínio de uma contraparte (p. ex., hospital-b.ch), o proxy DNS do Verimesh 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.
Passo 2: O agente de identidade verifica o estado da contraparte
O agente de identidade consulta o registo de identidade publicado pela contraparte via Verimesh. Dois resultados: a contraparte está habilitada para o Verimesh (verificação criptográfica completa) ou não (entrega padrão, mensagem marcada como não verificada). É assim que o Verimesh garante retrocompatibilidade — as mensagens para contrapartes não habilitadas nunca são bloqueadas.
Passo 3: Túnel WireGuard estabelecido com chaves derivadas do DKMS
Se a contraparte estiver habilitada para o Verimesh, é 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.
Passo 4: O motor de políticas avalia o consentimento
Antes de quaisquer dados se moverem, o motor de políticas do Verimesh (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.
FHIR-over-Verimesh é arquitetónico — o deployment em produção depende do onboarding dos hospitais; data mais precoce plausível: finais de 2026.
Ler por que esta arquitetura é necessária, não apenas melhor →
Passo 5: Token traduzido localmente
Os seus tokens OAuth e certificados X.509 existentes continuam válidos. A ponte de compatibilidade do Verimesh 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 Verimesh alarga-a para operar além das fronteiras organizativas.
Passo 6: Troca de dados pela malha cifrada
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.
Passo 7: Rasto de auditoria registado no KEL/TEL
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.
Cinco camadas de infraestrutura de confiança
A pilha de confiança do Verimesh é 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 que fica. O que muda.
O Verimesh 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 Verimesh 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
O que fica
- ✓OAuth 2.0 / OIDC — continua a gerir a autenticação interna e a emissão local de tokens. Sem alterações necessárias.
- ✓Certificados X.509 — continuam válidos. A ponte KERI-para-X.509 traduz na fronteira sem tocar na sua PKI.
- ✓JWT — o seu formato de token não muda. O Verimesh produz credenciais verificáveis ancoradas no KERI que se traduzem em JWT no lado recetor.
- ✓SMTP / DKIM / DMARC — o encaminhamento de correio e a infraestrutura anti-spam mantêm-se. O SEAL adiciona uma camada de autenticidade verificável sobre o DKIM, não no seu lugar.
- ✓Fluxos de trabalho existentes — os utilizadores finais enviam e-mails como antes. A verificação de confiança é-lhes invisível.
O que muda
- →Dependência de autoridade de certificação centralizada — substituída por derivação de chaves bilateral ancorada no DKMS. Nenhum terceiro pode revogar a capacidade de comunicação da sua organização.
- →E-mail com confiança ao primeiro uso — substituído por identidade organizacional verificada criptograficamente em cada troca. Os ataques de phishing e usurpação de identidade organizacional são estruturalmente prevenidos.
- →Fluxos de consentimento manuais — substituídos por consentimento avaliado pelo motor de políticas (OPA). Os acordos de troca de dados são legíveis por máquina e aplicados ao nível da infraestrutura.
- →Rastos de auditoria fragmentados — substituídos por registos KEL/TEL criptograficamente ligados, verificáveis de forma independente além das fronteiras organizativas.
Outros tentaram a identidade descentralizada. O que torna isto diferente?
Esta é a pergunta certa. Três projetos bem financiados não conseguiram entregar identidade descentralizada em grande escala:
- Sovrin — A Fundação Sovrin ficou sem capital operacional em 2023. A sua blockchain Hyperledger Indy requeria coordenação contínua de nós validadores e uma fundação financiada. A falha não foi técnica — foi de governação e económica.
- uPort — O projeto de identidade da ConsenSys foi rebatizado como Serto e depois abandonou o campo da identidade. O uPort assentava no Ethereum, o que significava taxas de gás e latência de transações on-chain para cada operação. A gestão de identidade à escala de produção não é economicamente viável numa blockchain pública.
- Jolocom — Afastou-se da infraestrutura de identidade após não conseguir adoção em produção. O padrão de falha comum: dependência de infraestrutura blockchain que não consegue escalar economicamente.
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 Verimesh assenta na mesma base KERI validada pelo GLEIF à escala institucional.
Quer perceber como isto se aplica à sua organização?
Veja como a infraestrutura de confiança verificada se aplica aos seus requisitos específicos e ao seu ambiente regulatório.