Los sistemas de identidad tradicionales se detienen en las fronteras organizativas. Esto es lo que las cruza.

Las herramientas de identidad estándar se construyeron para organizaciones individuales. La confianza interinstitucional a gran escala requiere una base diferente — la elección de la sanidad suiza.

Hablemos de esta arquitectura para su organización — sin compromiso

Cuatro limitaciones estructurales de las herramientas de identidad estándar

OAuth (Open Authorization) y la infraestructura de clave pública (PKI) son herramientas excelentes — dentro de los límites de una sola organización. No son fallos. Son restricciones arquitectónicas que se hacen visibles cuando la confianza necesita abarcar varias organizaciones.

Confianza de token

Restricción de OAuth / PKI

Los tokens OAuth se confían dentro de los límites de su emisor. Entre organizaciones, este 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 de acceso

Restricción de OAuth / PKI

Los alcances OAuth son generales — diseñados para permisos a nivel de aplicación. El consentimiento a nivel de grafo de recursos entre fronteras organizativas 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 las fronteras de confianza organizativas.

Auditabilidad

Restricción de OAuth / PKI

Los registros OAuth son organizativos. Las pistas de auditoría interorganizativas — quién accedió a qué, cuándo, autorizado por quién — requieren encadenamiento criptográfico que OAuth no fue diseñado para proporcionar.

Solución DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) proporciona pistas de auditoría a prueba de manipulaciones. Cada evento de identidad está criptográficamente vinculado y es verificable de forma independiente, creando auditabilidad interorganizativa.

Arquitectura de confianza

Restricción de OAuth / PKI

OAuth asume 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 sola autoridad.

Solución DKMS / Verimesh

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

OAuth para tokens locales, DKMS para confianza institucional escalable

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

Se trata de una evolución, no de una sustitución. OAuth (Open Authorization) es la herramienta adecuada para la autenticación local dentro de los límites de una sola organización. DKMS (Decentralized Key Management System) es la herramienta adecuada para la confianza institucional a gran escala — entre organizaciones soberanas sin un proveedor de identidad compartido. Verimesh combina ambos, desplegando cada uno donde es la herramienta adecuada.

Complementario a los programas nacionales de identidad electrónica

Swiyu es el programa nacional suizo de identidad electrónica. Hoy ejecuta un piloto activo en todos los cantones, el permiso de aprendizaje de conducción electrónico, mientras que se espera que la infraestructura de confianza de la propia e-ID entre en funcionamiento en el primer semestre de 2027. La introducción de la e-ID se ha aplazado, sin que se haya anunciado una nueva fecha, por lo que la cartera nacional aún no está en producción. Las credenciales de swiyu se emiten en formato SD-JWT VC, con identificadores y declaraciones de confianza publicados en registros federales. Para la propia e-ID el emisor es el Estado, por mandato de la ley de e-ID de 2025, y la credencial se guarda en el dispositivo del ciudadano. Otras credenciales sobre la misma infraestructura las emiten cantones, universidades y empleadores.

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 que preparó la decisión tecnológica de 2024.

La Unión Europea ejecuta el programa paralelo. El Marco de Arquitectura y Referencia del EUDI prevé una cartera ciudadana en cada Estado miembro, y para la credencial de identidad fundamental de la persona el emisor es igualmente el Estado. Responde a la misma pregunta, cómo una persona demuestra quién es ante una institución, y alcanza el mismo límite: no vincula a dos instituciones de jurisdicciones distintas. Verimesh está diseñado para complementar ambos, no para competir con ellos.

Para las organizaciones que despliegan Verimesh, ambos son complementarios más que competidores. Una cartera nacional responde a cómo una persona demuestra quién es ante una institución. No responde a cómo dos instituciones de jurisdicciones distintas se verifican entre sí, ni a qué ocurre con una decisión de consentimiento después de que los datos ya se han compartido. Verimesh conserva su propia capa de confianza y está diseñado para hablar los protocolos de las carteras en el borde, de modo que un cliente de Verimesh pueda aceptar una e-ID estatal en la incorporación y emitir sus propias credenciales en esa misma cartera, una vez que esos sistemas estén en producción.

Verimesh implementa esta arquitectura

Verimesh (anteriormente el proyecto Stargate) es la implementación en producción de la arquitectura de confianza basada en DKMS descrita anteriormente. Combina OAuth para autenticación local con DKMS anclado en KERI para confianza interorganizativa, un motor de políticas programable basado en OPA, interoperabilidad semántica mediante Overlays Capture Architecture (OCA) y comunicación verificable mediante SEAL.

SEAL, el componente de comunicación verificable de Verimesh, ya procesa más de 800.000 mensajes verificados al mes en la sanidad suiza. El despliegue completo de Verimesh se está llevando a cabo a lo largo de 2026, elegido por la sanidad suiza como futura infraestructura de confianza.

Descubra Verimesh

Una sola raíz, desde la aplicación hasta el cable

La malla de Verimesh funciona sobre WireGuard, y la clave del túnel comparte la misma raíz que la identidad de la aplicación. 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-rotación 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 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 — el mismo protocolo que recomiendan proveedores de seguridad como Palo Alto Networks. 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 se convierte en una rotación de claves rutinaria sobre el Key Event Log existente — y no en una reemisión masiva de todas las claves 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 invariantes que exige el artículo 71 del EHDS: identificadores vinculados a la persona que sobreviven a una nueva inscripción; registros de retiro verificables y con marca de tiempo, anclados en el Key Event Log; reversibilidad sin re-identificación; propagación entre controladores sin acuerdos bilaterales entre cada par de instituciones; e imposibilidad de vincular el registro del consentimiento con los datos que cubre.

Después de que los datos han sido divulgados — compartidos en una red hospitalaria, un consorcio de investigación o una cadena de pagadores — una revocación posterior del consentimiento debe igualmente alcanzar 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 atestiguado, de modo que una revocación añadida en el edge 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 despliegue a escala nacional

HIN — Health Info Net — es la red suiza de información sanitaria, que conecta hospitales, consultas de medicina general y especialistas a través de los límites cantonales. SEAL, el componente de comunicación verificable construido sobre esta arquitectura de confianza, ya procesa más de 800.000 mensajes verificados al mes. El despliegue completo de Verimesh con intercambio de datos estructurados se está llevando a cabo a lo largo de 2026.

HIN — Health Info Net

800.000+

mensajes verificados al mes

850+

pasarelas en la sanidad suiza

30.000+

consultas médicas e instituciones sanitarias

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 co-fundó 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 — el compromiso de una sola CA afecta a cada sujeto 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 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. Ambos son complementarios — OAuth para tokens locales, DKMS para confianza institucional escalable.
¿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 esquemas post-cuánticos — sin romper las relaciones de confianza existentes.
¿Quién mantiene DKMS?
DKMS es una especificación abierta. La DKMS Alliance — co-fundada por Vereign — coordina la especificación. La implementación de referencia de KERI (el protocolo subyacente a DKMS) se mantiene como open source por la comunidad KERI más amplia. Verimesh y SEAL de Vereign son implementaciones AGPLv3+ de la capa DKMS, desplegadas en producción en la sanidad suiza.
¿DKMS requiere una blockchain?
No. DKMS utiliza Key Event Logs (KELs) encadenados por hash para 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í. Vereign es la capa de confianza institucional que complementa los wallets nacionales de e-ID, no un competidor. Un wallet nacional (swiyu, EUDI) demuestra quién es una persona ante una institución. Verimesh responde al límite que esos wallets no cubren: cómo dos instituciones se verifican directamente, entre jurisdicciones, incluidas las personas, roles y agentes que actúan en ellas, y qué ocurre con una decisión de consentimiento una vez compartidos los datos.
¿Es Vereign un competidor de los wallets nacionales?
No. Verimesh está diseñado para complementar swiyu y EUDI, no para competir con ellos. Un wallet nacional responde a cómo una persona demuestra quién es ante una institución; no responde a cómo dos instituciones en jurisdicciones distintas se verifican mutuamente, ni a qué ocurre con una decisión de consentimiento tras compartir los datos. 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. El propio Verimesh está en producción en la sanidad suiza: la pasarela y la CA central en HIN funcionan en producción, los primeros clientes están migrados y las utilizan, y la migración en la red HIN está prevista para completarse antes de finales de 2026.

Reserve una revisión arquitectónica — cartografíe sus límites de confianza.

Esta arquitectura está desplegada en la sanidad suiza a escala nacional. Ya sea que esté evaluando alternativas a la identidad centralizada o planificando el intercambio de datos interorganizativo, lo cartografiaremos para 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