Qué es el ecosistema¶
En una frase¶
El ecosistema Gerege es un ecosistema de servicios digitales asentado sobre un
núcleo nacional de eID/PKI, cosido por una capa de SSO y derivado de una única
plantilla, que se construye en paralelo sobre dos líneas espejo: la pública
(*.dgov.mn) y la privada (*.gerege.mn).
¿Por qué construirlo así?¶
Tradicionalmente, cada servicio digital se levanta por separado: con su propio acceso, su propio modelo de permisos y su propio nivel de seguridad. El resultado:
- el ciudadano entra de forma distinta en cada servicio,
- cada organización reinventa la PKI,
- el nivel de seguridad varía de un servicio a otro,
- una misma corrección hay que repetirla en muchos sistemas.
El ecosistema Gerege empieza por el extremo contrario: la identidad, la seguridad, la IA y el soporte de servicio se resuelven una sola vez, y encima solo se añade el valor propio de cada sector. El desarrollador escribe producto, no infraestructura.
Es la expresión en código de la misión de Gerege Systems ХХК: «llevar a la ciudadanía los servicios públicos y privados de forma sencilla». Sobre una única base se levantan tanto los servicios de un organismo público como los productos del sector privado — banca, seguros, fintech, salud, educación — con el mismo nivel de verificación de identidad y la misma seguridad.
Tres ideas de fondo¶
1. La identidad es infraestructura, no problema de cada aplicación¶
Acceso, firma y certificados están resueltos de una vez en eID Mongolia. Las aplicaciones no guardan contraseñas ni escriben código de PKI: solo se conectan como relying party (RP).
- La clave privada de firma no existe completa en ningún sitio — ECDSA de umbral 2-of-2 (una parte en el teléfono, otra en el servidor).
- Cada ciudadano tiene dos certificados: Authentication (PIN1, acceso) y Signing (PIN2, firma con validez jurídica).
2. El SSO es el único camino de la identidad hacia la aplicación¶
Las aplicaciones no acceden al eID directamente. En medio está la capa de SSO, un proveedor OAuth2/OIDC estándar. Esa capa:
- centraliza el acceso y ofrece a todos los RP el mismo flujo,
- actúa como proxy de eID: entrega los servicios eID autorizados solo a aplicaciones registradas,
- mantiene las credenciales en un único lugar, de modo que dos sistemas no pueden divergir.
3. La plataforma es en sí misma un producto¶
La Template Platform no es código de ejemplo: es una base lista para producción. Backend Go con Clean Architecture + frontend Next.js BFF + pipeline de Gemini AI, endurecida en seguridad y con pruebas. Ring, Khurdan, Wallet y el Developer Portal han salido de ella.
Dos líneas espejo¶
| Capa | Público (dgov.mn) |
Privado (gerege.mn) |
|---|---|---|
| Identidad | eID Mongolia (común) | eID Mongolia (común) |
| SSO | sso.dgov.mn |
sso.gerege.mn |
| Template | template.dgov.mn |
open.gerege.mn |
| Developer | developer.dgov.mn |
developer.gerege.mn |
| Verticales | Ring · Khurdan | Gerege Platform · Wallet |
Ambas líneas comparten el mismo linaje de código: misma arquitectura, mismas convenciones, mismo nivel base de seguridad. Las diferencias están solo en la marca, el marco legal y el alcance de las integraciones.
¿Por qué dos líneas?
Los servicios públicos y privados difieren en requisitos legales, gobierno del dato y régimen de auditoría. Atender ambos desde un único despliegue difuminaría la frontera. Por eso: un código, dos despliegues.
Cuatro grandes giros¶
1. Fragmentación → consolidación. Los repositorios de eID, antes separados,
se unieron en el monorepo eid-platform-mn, con una sola rama y una sola marca;
las distintas marcas se atienden mediante variantes de la aplicación.
2. Salida de la dependencia de terceros. Ory Hydra se eliminó de todos los proyectos de SSO y los mecanismos necesarios se reescribieron en código Go propio; la base de datos separada de Hydra se fusionó con la principal. La tendencia general es reducir dependencias externas.
3. Plataforma → ecosistema. El Template pasó a ser un producto por derecho propio; por encima aparecieron plataformas reales de organismos públicos y, por debajo, la capa de intercambio de datos X-Road.
4. Fork → upstream (2026-08). En la capa 3 apareció Gerege Nexus: una base nueva construida como monolito modular con tienda de aplicaciones. Donde antes un producto nuevo significaba un fork de la plantilla, ahora significa escribir un módulo o, para una marca, forkear el upstream y actualizarse fusionando. Los dos primeros forks son Gerege SSO y Eduge.mn. Como la transición está en curso, las plataformas de 1.ª generación siguen en producción.