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. A mesma verificação de políticas cobre o âmbito delegado: a parte recetora pode confirmar que uma pessoa, um papel ou um agente atua dentro das autorizações concedidas pela sua organização, verificado contra a cadeia de credenciais própria dessa organização em vez de um registo central.
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 tornam evidente qualquer adulteração e são 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.