De la consulta DNS al intercambio de datos verificado, en milisegundos.
Verimesh transforma la infraestructura de correo electrónico de dependiente de la confianza a verificada por la confianza. Cada intercambio de mensajes entre organizaciones resuelve la identidad criptográfica, establece el consentimiento de políticas y crea una pista de auditoría verificable, sin sobrecarga de flujos de trabajo ni cambios en la forma de trabajar de los usuarios.
Reserve un recorrido arquitectónico de 30 minutosLos sistemas de confianza actuales hacen que las organizaciones dependan de autoridades centrales para las verificaciones de identidad y el intercambio de datos entre ellas. La arquitectura de Vereign permite que cada organización controle su propia identidad criptográfica, de modo que las contrapartes que verifican contra su Key Event Log no necesitan ninguna autoridad central para comprobarla. Así funciona en la práctica, desde la gestión de claves hasta el intercambio de datos.
Qué ocurre cuando envía un mensaje
La secuencia de 7 pasos siguiente es el camino que recorre cada mensaje habilitado por Verimesh, desde el momento en que su cliente DNS realiza una consulta hasta que los datos llegan verificados y auditados a su destino.
Paso 1: El proxy DNS intercepta la consulta
Cuando su aplicación resuelve el dominio de una contraparte (p. ej., hospital-b.ch), el proxy DNS de Verimesh intercepta la consulta antes de que alcance su resolver upstream. Este es el punto de entrada: no se requieren cambios en el código de la aplicación. El proxy opera de forma transparente a nivel de red.
Paso 2: El agente de identidad verifica el estado de la contraparte
El agente de identidad consulta el registro de identidad publicado por la contraparte a través de Verimesh. Dos resultados: la contraparte está habilitada para Verimesh (verificación criptográfica completa) o no (entrega estándar, mensaje marcado como no verificado). Así es como Verimesh logra la compatibilidad retroactiva: nunca bloquea mensajes a contrapartes no habilitadas.
Paso 3: Túnel WireGuard establecido con claves derivadas de DKMS
Si la contraparte está habilitada para Verimesh, se establece un túnel VPN WireGuard con claves derivadas de los registros de identidad DKMS de ambas organizaciones. Estas claves no las emite una autoridad de certificación central: se derivan del registro de eventos de claves KERI de cada organización. El túnel es bilateral: cada parte se autentica ante la otra de forma independiente.
Paso 4: El motor de políticas evalúa el consentimiento
Antes de que se muevan datos, el motor de políticas de Verimesh (Open Policy Agent, OPA) evalúa si este intercambio de datos está autorizado según las políticas de ambas partes. Para datos sanitarios, el FHIR Resolver verifica el consentimiento a nivel de recurso: consentimientos de pacientes, autorizaciones organizativas y normativas sectoriales (EHDS, LPD suiza) se evalúan en tiempo real. Los datos no autorizados por las políticas no se transfieren. La misma comprobación de políticas cubre el alcance delegado: la parte receptora puede confirmar que una persona, un rol o un agente actúa dentro de los permisos que su organización le concedió, verificado frente a la cadena de credenciales propia de esa organización en lugar de un registro central.
FHIR-over-Verimesh es arquitectónico. El despliegue en producción depende del onboarding de los hospitales; fecha más temprana plausible: finales de 2026.
Leer por qué esta arquitectura es necesaria, no solo mejor →
Paso 5: Token traducido localmente
Sus tokens OAuth y certificados X.509 existentes siguen siendo válidos. El puente de compatibilidad de Verimesh traduce las credenciales ancladas en KERI a formato JWT o X.509 en el extremo receptor, localmente, sin contactar con ninguna autoridad externa. Su infraestructura de identidad no cambia. Verimesh la amplía para operar a través de las fronteras organizativas.
Paso 6: Intercambio de datos a través de la malla cifrada
Con el consentimiento de políticas confirmado y el túnel WireGuard cifrado establecido, se procede al intercambio de datos. SEAL (Secure Edge Application Layer) envuelve cada mensaje con una capa de autenticidad verificable: la organización receptora puede demostrar quién envió los datos, cuándo y que no han sido modificados en tránsito. Esto sustituye la dependencia de S/MIME de autoridades de certificación de terceros por verificación bilateral derivada de DKMS.
Paso 7: Pista de auditoría registrada en KEL/TEL
Cada intercambio crea una entrada en el Key Event Log (KEL) y el Transaction Event Log (TEL) de KERI. Estos registros evidencian cualquier manipulación y son verificables de forma independiente por cualquier parte, no solo por un servidor de registros central. Para sectores regulados, esto significa pistas de auditoría interorganizativas criptográficamente sólidas, disponibles sin infraestructura centralizada.
Cinco capas de infraestructura de confianza
La pila de confianza de Verimesh está diseñada por capas. Cada capa hace una cosa bien y la pasa limpiamente a la siguiente. La infraestructura existente se conecta a la capa de compatibilidad: nada se arranca.
Zero Trust entre organizaciones
NIST SP 800-207 afirma que en Zero Trust «la confianza nunca se concede de forma implícita, sino que debe evaluarse de manera continua» (§2). Para la colaboración a través de los límites empresariales (§4.4), señala que inscribir a ambas organizaciones en un sistema de identidad federada haría más rápido establecer esas relaciones: una comodidad, no un requisito de Zero Trust. En DKMS, las contrapartes que verifican contra Key Event Logs comprueban los identificadores de las demás sin un intermediario. El controlador de un identificador se compromete de antemano con sus siguientes claves, y cualquier verificador lee el estado actual de las claves en el registro. Cuando una contraparte valida únicamente X.509, como ocurre hoy en HIN, una autoridad de certificación puente conecta ambos.
Qué se mantiene. Qué cambia.
Verimesh es una extensión de la infraestructura que ya opera. La tabla siguiente muestra qué conserva y qué añade Verimesh.
443 violaciones del RGPD notificadas diariamente en Europa, con multas acumuladas superiores a 1.200 millones de EUR (DLA Piper GDPR Fines and Data Breach Survey)
Qué se mantiene
- ✓OAuth 2.0 / OIDC: sigue gestionando la autenticación interna y la emisión local de tokens. Sin cambios necesarios.
- ✓Certificados X.509: siguen siendo válidos. El puente KERI-a-X.509 traduce en la frontera sin tocar su PKI.
- ✓JWT: su formato de token no cambia. Verimesh produce credenciales verificables ancladas en KERI que se traducen a JWT en el extremo receptor.
- ✓SMTP / DKIM / DMARC: el enrutamiento de correo y la infraestructura anti-spam se mantienen. SEAL añade una capa de autenticidad verificable sobre DKIM, no en su lugar.
- ✓Flujos de trabajo existentes: los usuarios finales envían correos como antes. La verificación de confianza es invisible para ellos.
Qué cambia
- →Dependencia exclusiva de una autoridad de certificación central: para las contrapartes que verifican contra el Key Event Log, la confianza descansa en claves ancladas en DKMS. El controlador de un identificador organizativo no delegado rota o revoca sus claves mediante pre-rotación, y el verificador comprueba el resultado en el registro. Cuando una contraparte valida únicamente X.509, como ocurre hoy en HIN, una autoridad de certificación puente conecta ambos.
- →Correo con confianza al primer uso: los intercambios entre organizaciones que se verifican mutuamente contra Key Event Logs llevan la identidad verificada de la organización remitente, de modo que suplantarla exige sus claves o las de su delegante, no una dirección de aspecto similar.
- →Flujos de consentimiento manuales: serían sustituidos por consentimiento evaluado por el motor de políticas (OPA). Los acuerdos de intercambio de datos serían legibles por máquina y se aplicarían a nivel de infraestructura.
- →Pistas de auditoría fragmentadas: serían sustituidas por registros KEL/TEL enlazados criptográficamente, verificables de forma independiente a través de las fronteras organizativas.
Otros intentaron la identidad descentralizada. ¿Qué hace diferente a esto?
Es la pregunta correcta. Tres proyectos bien financiados no lograron entregar identidad descentralizada a gran escala:
- Sovrin: La Fundación Sovrin se quedó sin capital operativo en 2023. Su blockchain Hyperledger Indy requería coordinación continua de nodos validadores y una fundación financiada. El fallo no fue técnico, fue de gobernanza y económico.
- uPort: El proyecto de identidad de ConsenSys fue rebautizado como Serto y luego abandonó el campo de la identidad. uPort se basaba en Ethereum, lo que significaba tarifas de gas y latencia de transacciones on-chain para cada operación. La gestión de identidad a escala de producción no es económicamente viable en una blockchain pública.
- Jolocom: Pivotó alejándose de la infraestructura de identidad tras no lograr adopción en producción. El patrón de fallo común: dependencia de infraestructura blockchain que no puede escalar económicamente.
KERI es estructuralmente diferente. No tiene dependencia de blockchain. Los eventos de claves se anclan en registros de solo adición que cada controlador mantiene de forma independiente: sin libro mayor compartido, sin tarifas de gas, sin gobernanza de fundación necesaria.
La validación institucional: GLEIF (la Global Legal Entity Identifier Foundation) opera el sistema LEI global para instituciones financieras en 180 países. GLEIF eligió KERI para el sistema vLEI: infraestructura de producción que verifica la identidad de instituciones financieras en todo el mundo. Verimesh se construye sobre la misma base KERI validada por GLEIF a escala institucional.
¿Quiere entender cómo encaja esto en su organización?
Vea cómo la infraestructura de confianza verificada se aplica a sus requisitos específicos y su entorno regulatorio.