De la consulta DNS al intercambio de datos verificado — en milisegundos.

Stargate 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 minutos

Los sistemas de confianza actuales obligan a las organizaciones a depender de autoridades centrales para cada verificación de identidad y cada intercambio de datos. La arquitectura de Vereign elimina estas dependencias permitiendo a cada organización controlar su propia identidad criptográfica y verificar a las demás directamente. Así funciona en la práctica, desde la gestión de claves hasta el intercambio de datos verificado.

Qué ocurre cuando envía un mensaje

La secuencia de 7 pasos siguiente es el camino que recorre cada mensaje habilitado por Stargate — desde el momento en que su cliente DNS realiza una consulta hasta que los datos llegan verificados y auditados a su destino.

1

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 Stargate 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.

2

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 Stargate. Dos resultados: la contraparte está habilitada para Stargate (verificación criptográfica completa) o no (entrega estándar, mensaje marcado como no verificado). Así es como Stargate logra la compatibilidad retroactiva — nunca bloquea mensajes a contrapartes no habilitadas.

3

Paso 3: Túnel WireGuard establecido con claves derivadas de DKMS

Si la contraparte está habilitada para Stargate, 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.

4

Paso 4: El motor de políticas evalúa el consentimiento

Antes de que se muevan datos, el motor de políticas de Stargate (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.

5

Paso 5: Token traducido localmente

Sus tokens OAuth y certificados X.509 existentes siguen siendo válidos. El puente de compatibilidad de Stargate 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. Stargate la amplía para operar a través de las fronteras organizativas.

6

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.

7

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 son a prueba de manipulación y 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 Stargate 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.

La arquitectura de confianza de cinco capas de Stargate — identidad anclada en el borde, política en el centro, compatibilidad en la superficie
Stargate Five-Layer Trust Architecture Stargate Five-Layer Trust Architecture Each layer handles one concern — trust flows upward from identity to audit 5 Audit KEL · TEL Tamper-evident Key Event & Transaction Event Logs Independently verifiable audit trails — no central log server 4 Compatibility JWT · X.509 · OAuth Translates KERI credentials to formats existing systems understand Stargate extends your token infrastructure — does not replace it 3 Authorization OPA · ACDC · FHIR Policy engine evaluates consent before any data moves Machine-readable data sharing agreements at infrastructure layer 2 Transport WireGuard Encrypted bilateral tunnel — keys derived from DKMS, not issued by CA No third party can intercept or revoke — each org controls its own keys 1 Identity DKMS · KERI Cryptographic root — each organization controls its own key event log PKI at the edge — no central authority, bilateral trust establishment trust flows up Foundation (sovereign) Policy centre Compatibility Audit surface

Qué se mantiene. Qué cambia.

Stargate no es un proyecto de sustitución. Es una extensión de la infraestructura que ya opera. La tabla siguiente muestra qué conserva y qué añade Stargate.

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. Stargate 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 de autoridad de certificación centralizada — sustituida por derivación de claves bilateral anclada en DKMS. Ningún tercero puede revocar la capacidad de comunicación de su organización.
  • Correo con confianza al primer uso — sustituido por identidad organizativa verificada criptográficamente en cada intercambio. Los ataques de phishing y suplantación de identidad organizativa se previenen estructuralmente.
  • Flujos de consentimiento manuales — sustituidos por consentimiento evaluado por el motor de políticas (OPA). Los acuerdos de intercambio de datos son legibles por máquina y se aplican a nivel de infraestructura.
  • Pistas de auditoría fragmentadas — 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. No es una prueba de concepto. Es infraestructura de producción que verifica la identidad de instituciones financieras en todo el mundo. Stargate 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.

Protección de datos suiza Conforme con el RGPD Open Source AGPLv3+ Alojamiento suizo