Una identidad verificable para toda su organización.

No solo la empresa: cada departamento, dispositivo, servicio y agente, verificable por las instituciones con las que trabaja, sin ningún proveedor compartido en medio.

Hablemos de esta arquitectura para su organización

Cuatro limitaciones estructurales de las herramientas de identidad estándar

OpenID Connect, OAuth y la infraestructura de clave pública (PKI) son herramientas excelentes dentro del límite de una sola organización. La federación no elimina ese límite, lo desplaza: o hacia acuerdos negociados de antemano entre cada par de organizaciones, o hacia un intermediario central que ninguna de ellas controla. No son fallos. Son restricciones arquitectónicas que se hacen visibles en el momento en que la confianza tiene que abarcar varias organizaciones.

Confianza en los tokens

Donde se detienen las herramientas estándar

Los tokens de acceso son fiables dentro del límite de quien los emitió. Entre organizaciones ese límite se rompe: la organización receptora no tiene forma de verificar la autoridad de la organización emisora.

Solución DKMS / Verimesh

DKMS establece una identidad criptográfica autocertificante: la identidad de cada organización es verificable por cualquier otra organización, sin depender de una autoridad de certificación compartida.

Granularidad del acceso

Donde se detienen las herramientas estándar

Los scopes son de grano grueso: están diseñados para permisos a nivel de aplicación. El consentimiento a nivel de grafo de recursos entre organizaciones requiere un modelo diferente.

Solución DKMS / Verimesh

El motor de políticas de Verimesh (Open Policy Agent, OPA) permite un control de acceso programable y granular que opera a través de los límites de confianza organizativos.

Auditabilidad

Donde se detienen las herramientas estándar

Los registros de autenticación se detienen en la organización que los escribió. Las pistas de auditoría interorganizativas (quién accedió a qué, cuándo y autorizado por quién) requieren un encadenamiento criptográfico que la autenticación local nunca fue diseñada para ofrecer.

Solución DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) proporciona pistas de auditoría que evidencian cualquier manipulación. Cada evento de identidad está encadenado criptográficamente y es verificable de forma independiente, lo que crea auditabilidad interorganizativa.

Arquitectura de confianza

Donde se detienen las herramientas estándar

Estos modelos presuponen una autoridad central: un proveedor de identidad en el que todos confían. La confianza institucional distribuida entre organizaciones soberanas no puede depender de una única autoridad.

Solución DKMS / Verimesh

DKMS permite la gestión soberana de la identidad: cada organización controla sus propias raíces criptográficas. La confianza se establece bilateralmente, no se delega en un coordinador central.

Conserve su proveedor de identidad. Añada confianza entre instituciones.

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
Infraestructura de identidad KERI: identificadores autocertificantes, recibos de eventos de clave y confianza bilateral sin autoridad central

Se trata de una capacidad nueva. Su proveedor de identidad, y los protocolos que lo sustentan (OpenID Connect, OAuth, SAML), están probados para la autenticación dentro de una sola organización, y se quedan donde están. DKMS (Decentralized Key Management System) hace lo que ellos nunca fueron diseñados para hacer: da a cada organización una identidad autocertificante que cualquier otra institución puede verificar directamente, sin un proveedor compartido entre ambas. Verimesh aporta DKMS y se comunica con los sistemas que ya utiliza, de modo que amplía lo que ya tiene en lugar de sustituirlo.

Construir sobre los programas nacionales de identidad electrónica

El programa swiyu es la infraestructura federal suiza de identidad electrónica. Su primera credencial, el permiso de aprendizaje de conducción electrónico, está activa en todos los cantones desde diciembre de 2025, con unas 27.000 emitidas. La puesta en servicio de la infraestructura de confianza de la e-ID está prevista para el primer semestre de 2027, mientras que la introducción de la propia e-ID se ha aplazado sin que se haya anunciado una nueva fecha. Los identificadores de los emisores y las declaraciones de confianza se publican en registros federales centrales, y la credencial se guarda en el dispositivo del propio ciudadano. Se espera que la misma infraestructura transporte credenciales de cantones, universidades y empleadores cuando se abra a emisores generales.

Vereign ha participado en el proceso suizo de e-ID desde el principio, a través de reuniones de participación e intercambios bilaterales, y Georg Greve fue miembro del Technical Advisory Circle. Convocado por fedpol, ese grupo asesor contribuyó a la decisión tecnológica de enero de 2024.

La Unión Europea sigue el mismo camino. El Reglamento (UE) 2024/1183 obliga a cada Estado miembro a ofrecer al menos una cartera de Identidad Digital Europea (EUDI), y la credencial fundamental de la persona proviene de proveedores designados por el Estado. Ambos programas responden a la misma pregunta, y la responden bien: cómo una persona demuestra ante una institución quién es. Ninguno de los dos especifica la identidad de los departamentos, dispositivos, servicios y agentes que una organización realmente opera, y ambos anclan la confianza en registros centrales, razón por la cual ninguno mantiene un registro de las partes usuarias que verifican las credenciales: a escala de la Unión habría demasiadas para enumerarlas.

Para las organizaciones que despliegan Verimesh, swiyu y EUDI se convierten en puntos de partida sobre los que construir. Hoy el puente está diseñado, no entregado: una vez que esos sistemas lleguen a producción, aceptará una e-ID estatal en la incorporación, la utilizará como raíz de confianza y dejará que Verimesh traslade esa confianza a las instituciones, jurisdicciones y sistemas que toca un flujo de trabajo real, emitiendo sus propias credenciales de vuelta en esa misma cartera.

Verimesh implementa esta arquitectura

Verimesh (antes el proyecto Stargate) es la implementación en producción de la arquitectura de confianza descrita arriba. Funciona con la autenticación que ya tiene en marcha y añade aquello para lo que esa capa nunca se diseñó: identidad organizativa arraigada en DKMS para la confianza entre instituciones, un motor de políticas programable (Open Policy Agent), significado compartido de los datos mediante Overlays Capture Architecture (OCA) y entrega de mensajes con evidencia de manipulación mediante SEAL.

Verimesh está en producción en la sanidad suiza: la pasarela y la CA central en HIN funcionan en producción, las primeras instituciones ya están migradas y las utilizan, y la migración en toda la red de HIN está prevista para completarse antes de finales de 2026.

Descubra Verimesh

Una sola identidad organizativa, hasta la capa de red.

Verimesh transporta su tráfico sobre WireGuard, y la clave del túnel está anclada en la misma identidad organizativa que las aplicaciones que corren por encima. Las claves de túnel Curve25519 de cada organización se derivan de su propio material de Decentralized Key Management (DKMS): ninguna autoridad central las emite, y no hay brecha alguna entre la identidad de la capa de red y la de la capa de aplicación. La rotación de claves se coordina con DKMS (la pre-rotation se basa en KERI), y cada establecimiento de túnel es auditable frente al Key Event Log. Ningún intermediario es dueño del flujo de datos.

Silencioso por diseño

Los paquetes no autenticados no reciben respuesta. La malla es invisible ante un escaneo de puertos: no hay superficie de ataque pública que sondear.

Unas 4.000 líneas que puede leer

WireGuard tiene aproximadamente 4.000 líneas de código, frente a unas 100.000 de OpenVPN y 400.000 de IPsec. La auditabilidad es, en sí misma, una propiedad de seguridad.

Sin negociación, sin degradación

Primitivas modernas fijas: Curve25519, ChaCha20-Poly1305, BLAKE2s, el handshake Noise_IKpsk2. La perfect forward secrecy con renovación de claves cada unos dos minutos y el ocultamiento de la identidad vienen integrados, no configurados.

Soberano hasta el cable

Open Source de extremo a extremo, self-hosted, sin ningún plano de control SaaS en la ruta. La soberanía se extiende desde la aplicación hasta el propio transporte.

Infraestructura probada y sin sorpresas

En el núcleo principal de Linux desde 2020. Aquí no hay criptografía novedosa, y hoy sostiene el despliegue de Verimesh con HIN.

Preparado para la migración cuántica

La capa de clave precompartida de WireGuard ya protege el tráfico de hoy frente a los ataques de «almacenar ahora, descifrar después». Y como las claves de túnel se derivan de DKMS, el paso a algoritmos post-cuánticos es una rotación de claves rutinaria sobre el Key Event Log existente, no una reemisión masiva de una sola vez.

Vea el ciclo de vida completo de la conexión

La aplicación del consentimiento es el propósito central de DKMS

El artículo 71(8) del EHDS crea una restricción estructural que ninguna autoridad central puede satisfacer: cuando una persona retira su consentimiento al uso secundario, ese retiro debe propagarse a cada institución que posee o ha derivado datos de la fuente original. Ninguna CA puede co-firmar el retiro; ningún proveedor de identidad puede cascadear la revocación. Esta restricción es arquitectónicamente incompatible con la identidad centralizada.

DKMS satisface cinco requisitos que exige el artículo 71 del EHDS: identificadores vinculados a la persona que sobreviven a una nueva inscripción; registros de opt-out verificables y con marca de tiempo, anclados en el Key Event Log; reversibilidad sin re-identificación; propagación entre responsables del tratamiento sin acuerdos bilaterales entre cada par de instituciones; e imposibilidad de vincular el registro de consentimiento con los datos que cubre.

Una vez divulgados los datos (compartidos en una red hospitalaria, un consorcio de investigación o una cadena de pagadores), una exclusión posterior debe seguir alcanzando a cada responsable del tratamiento aguas abajo. Los Key Event Logs de DKMS propagan la revocación criptográficamente: el KEL de cada responsable es append-only y está atestiguado, de modo que una revocación añadida en el borde de la persona se vuelve verificable en cada institución que posee un registro derivado.

Leer la tesis sobre arquitectura del consentimiento

Probado en la sanidad suiza, elegido para un despliegue a escala nacional

HIN (Health Info Net) es la red suiza de información sanitaria, que conecta hospitales, consultas de medicina general y proveedores especializados a través de los límites cantonales. SEAL, el producto de entrada sobre esta capa de confianza, ya transporta más de 800.000 entregas verificadas al mes. Verimesh está en producción en la sanidad suiza: la pasarela y la CA central en HIN funcionan en producción, las primeras instituciones ya están migradas y las utilizan, y la migración en toda la red de HIN está prevista para completarse antes de finales de 2026.

HIN (Health Info Net)

800.000+

entregas verificadas al mes

Arquitectura de confianza: preguntas frecuentes

¿Qué es DKMS?
DKMS (Decentralised Key Management) es la categoría de infraestructura de identidad en la que la confianza criptográfica se ancla en el borde organizativo, no en una autoridad de certificación central. Cada organización controla su propio material criptográfico y su propio Key Event Log (KEL) append-only. Vereign cofundó la DKMS Alliance para formalizar DKMS como categoría junto a PKI y OAuth.
¿En qué se diferencia DKMS de PKI?
PKI ancla la confianza en Autoridades de Certificación centrales, de modo que la vulneración de una sola CA afecta a todos los sujetos que esa CA ha firmado. DKMS ancla la confianza en el Key Event Log propio de cada organización: un fallo queda limitado a un único controlador, la rotación de claves es nativa y atómica mediante compromisos de pre-rotation, y la confianza interjurisdiccional no requiere tratados de reconocimiento entre CAs. DKMS es PKI en el borde, sin el punto único de fallo.
¿DKMS reemplaza a OAuth?
No. OAuth es adecuado para los flujos de token locales dentro de una sola organización y debe seguir utilizándose ahí. DKMS resuelve un problema para el que OAuth nunca fue diseñado: establecer confianza verificable entre organizaciones sin un intermediario compartido. Conserve su proveedor de identidad y añada DKMS para la confianza entre instituciones.
¿DKMS está preparado para post-cuántico?
Sí. DKMS trata la rotación de claves como una operación de primera clase. Cuando se requieren algoritmos post-cuánticos, la migración se convierte en una rotación de claves rutinaria sobre el Key Event Log existente, en lugar de una reemisión masiva de certificados. La propiedad de pre-rotation de KERI significa que la siguiente clave puede ser cualquier algoritmo que el controlador se comprometa a usar (incluidos los esquemas post-cuánticos), sin romper las relaciones de confianza existentes.
¿Quién mantiene DKMS?
DKMS es una especificación abierta. La DKMS Alliance, cofundada por Vereign, coordina la especificación. La implementación de referencia de KERI (el protocolo que sustenta DKMS) la mantiene como Open Source la comunidad KERI más amplia. Verimesh, de Vereign, es una implementación AGPLv3+ de la capa DKMS: su pasarela y su CA central están en producción en HIN, con los primeros clientes migrados. SEAL es el sistema de entrega cifrada por enjambre AGPLv3+ de Vereign y es arquitectónicamente independiente de DKMS.
¿DKMS requiere una blockchain?
No. DKMS utiliza Key Event Logs (KELs) encadenados por hash para lograr integridad append-only, pero no hay capa de consenso, ni token, ni ledger distribuido. La decisión de evitar la blockchain es deliberada: la infraestructura regulada necesita verificación determinista, no finalidad probabilística.
¿Puede Vereign ayudarme a integrar el wallet swiyu o EUDI?
Sí por diseño, aunque todavía no en producción: hoy los componentes del puente son arquitectónicos, no entregados. Cuando esos sistemas estén operativos, aceptará una e-ID estatal (swiyu, EUDI) en la incorporación y la utilizará como raíz de confianza; después dejará que Verimesh traslade esa confianza más allá: a las instituciones, jurisdicciones y sistemas que toca un flujo de trabajo real, incluidas las personas, los roles y los agentes que actúan en ellos, y a lo que ocurre con una decisión de consentimiento una vez que los datos ya se han compartido.
¿Es Vereign un competidor de los wallets nacionales?
No. Un wallet nacional da a una persona una identidad verificable. Verimesh se la da a una organización, y abarca los departamentos, dispositivos, servicios y agentes que esta opera, de modo que ambos actúan en capas distintas y se componen en lugar de solaparse. Verimesh conserva su propia capa de confianza y está diseñado para hablar los protocolos de los wallets en el borde.
¿Está en producción el puente de Verimesh hacia swiyu o EUDI?
No. Los componentes del puente (un proveedor OID4VCI/VP, la exportación de credenciales, el mapeo de identificadores) son arquitectónicos, demostrados a nivel de diseño, no entregados. Verimesh en sí está en producción en la sanidad suiza: la pasarela y la CA central en HIN funcionan en producción, las primeras instituciones ya están migradas y las utilizan, y la migración en toda la red de HIN está prevista para completarse antes de finales de 2026.

Reserve una revisión de arquitectura. La proyectamos sobre sus límites de confianza.

Esta arquitectura está desplegada en la sanidad suiza a escala nacional. Tanto si está evaluando alternativas a la identidad centralizada como si planifica el intercambio de datos interorganizativo, la proyectaremos sobre su entorno en una llamada de 30 minutos.

Reserve una revisión arquitectónica
Protección de datos suiza Conforme con el RGPD Open Source AGPLv3+ Alojamiento suizo
Vea cómo funciona la arquitectura paso a paso