Arquitectura por capas

El ecosistema se compone de cinco capas. La capa inferior sirve a la superior; la superior desconoce la estructura interna de la inferior y solo dialoga con ella a través de su contrato.

CAPA 4 — PRODUCTOS VERTICALES (vertical)
    ring.dgov.mn          Ring System — reingeniería de procesos
    hurdan.dgov.mn        Plataforma «Khurdan» — prestación y control de servicios
    developer.gerege.mn   Developer Portal (también versión dgov)
    wallet.gerege.mn      Gerege Wallet — cartera digital del ciudadano

CAPA 3 — BASE DE PLATAFORMA
  -- 2.ª generación: Nexus — monolito modular, tienda de aplicaciones
    nexus.gerege.mn       Gerege Nexus — upstream, 8 módulos
    eduge.mn              Eduge.mn — fork de marca sectorial
    (dominio pendiente)   Gerege SSO — fork centrado en el inicio de sesión
  -- 1.ª generación: Template — un fork por repositorio
    template.gerege.mn    Gerege Template Platform
    template.dgov.mn      Government Template Platform V3.0 (+ port a Node.js)
    gerege.mn             Gerege Platform (proveedor SSO por sí mismo)
    → Clean Architecture Go + Next.js BFF + pipeline Gemini AI

CAPA 2 — AUTENTICACIÓN / SSO (proveedor OIDC)
    sso.gerege.mn   Gerege SSO          sso.dgov.mn      Government SSO
    dan.gerege.mn   DAN Gateway         gsign.gerege.mn  G-Sign
    → código OAuth2/OIDC propio en Go (Hydra sustituido por completo), una sola BD
    → proxy eID: servicios eID autorizados solo a aplicaciones registradas

CAPA 1 — NÚCLEO IDENTIDAD / PKI
    eID Mongolia (eid-platform-mn)
    server (Go) · web · admin · SDK iOS · SDK Android · macOS/Windows
    ECDSA de umbral 2-of-2 · doble clave / doble certificado (PIN1 acceso / PIN2 firma)
    CA · OCSP · CRL · TSA

CAPA 0 — INTERCAMBIO DE DATOS
    X-Road instancia MN — central server, security servers
    Servicio adyacente: xyp.gerege.mn (consultas sobre personas jurídicas)

Capa 0 — Intercambio de datos

Qué es: un canal normalizado de intercambio de datos entre organizaciones — X-Road (instancia MN).

Función: las organizaciones miembro invocan los servicios de las demás de forma autenticada, firmada y con sello de tiempo. Cada security server representa a su miembro, y el central server firma y distribuye la lista de confianza (globalconf).

Vínculo particular: eID Mongolia ejerce para X-Road el papel de autoridad de certificación (CA) — es decir, la capa 1 aporta a la capa 0 su raíz de confianza.

Estado: Parcial El central server y los primeros security servers están en marcha y la topología está definida; el despliegue a gran escala continúa.

Capa 1 — Núcleo identidad / PKI

Qué es: eID Mongolia — la plataforma nacional de eID (al estilo Smart-ID / eIDAS).

Función: identificar a ciudadanos y organizaciones, darles acceso y permitir estampar una firma con validez jurídica. Además, todo el ciclo de vida del certificado: emisión (CA), comprobación de validez (OCSP/CRL) y sello de tiempo (TSA).

Decisiones clave:

• ECDSA de umbral 2-of-2 — la clave privada de firma no existe completa en ninguna de las partes.
• Doble clave / doble certificado — PIN1 → acceso, PIN2 → firma.
• El identificador es civil_id; el ETSI ID es PNOMN-<civil_id> para personas físicas y NTRMN-<...> para organizaciones.
• KYC — mediante DAN, con prueba de vida por reconocimiento facial.

Quién lo usa: la capa 2 (SSO) directamente; las capas 3–4 a través del SSO.

Estado: Production

Capa 2 — Autenticación / SSO

Qué es: los proveedores OAuth2/OIDC — Gerege SSO (sso.gerege.mn) y Government SSO (sso.dgov.mn), junto con los servicios adyacentes DAN Gateway y G-Sign.

Función — tres cosas:

1. Proveedor de identidad — los RP pueden ofrecer Sign in with Gerege. Authorization code + PKCE (S256), refresh token rotatorio (con detección de reutilización), client_credentials.
2. Proxy de eID — los servicios eID autorizados se entregan solo a aplicaciones registradas. La aplicación nunca accede al eID directamente.
3. Único lugar de registro de aplicaciones — el cliente OAuth y su secreto se crean y residen únicamente aquí.

Sin Hydra

Antes se usaba Ory Hydra; los mecanismos necesarios se reescribieron en código Go propio. La base de datos separada de Hydra se fusionó con la principal. Bajaron tres cosas a la vez: dependencias externas, complejidad de las migraciones y coste de operación.

Estado: Production

Capa 3 — Base de plataforma

Esta capa tiene ahora dos generaciones. Ambas están en producción y la transición entre ellas está en marcha.

2.ª generación — Gerege Nexus Production

Qué es: una plataforma monolito modular — los módulos de negocio implementan el contrato Go Module y se compilan en un solo binario; qué aplicaciones están activas para un inquilino lo decide la tienda de aplicaciones (app_installations) en PostgreSQL.

Qué cambia: en la 1.ª generación, un producto nuevo significaba un fork de la plantilla. En Nexus, un producto nuevo suele ser un módulo nuevo o, para una marca, un fork del upstream que se actualiza fusionando desde él.

	1.ª generación (Template)	2.ª generación (Nexus)
Producto nuevo	Forkear la plantilla	Escribir un módulo, o forkear para una marca
Distribución	Un despliegue por repositorio	Por inquilino, mediante la tienda de aplicaciones
Cómo viaja el código	Paquetes open-gerege-core · @gerege/ui-core	Upstream → los forks fusionan desde él
Llamadas entre módulos	HTTP	Llamadas Go dentro del proceso

Forks actuales: nexus.gerege.mn (upstream, despliegue de referencia) · eduge.mn (sector educativo) · Gerege SSO (centrado en la capa de inicio de sesión, aún sin dominio).

Los ocho módulos incluidos: Contacts · Products · Inventory · Billing & e-Barimt · Digital Documents · Developer Portal · firma electrónica de PDF (eID PIN2) · servicios públicos (flujo configurable, jerarquía, SLA).

Nexus no sustituye a la capa 2

Nexus lleva su propio proveedor OAuth2/OIDC, pero sirve a los inquilinos y clientes de terceros de ese despliegue. A escala del ecosistema, la única vía para identificar a un ciudadano sigue siendo la capa 2: Nexus tampoco llega nunca a eID de forma directa.

1.ª generación — Template Platform Production

Qué es: la Template Platform — una base lista para producción con la que construir servicios digitales; y Gerege Platform, su variante ampliada capaz de ser ella misma proveedor de SSO.

Función: al arrancar un servicio nuevo, lo siguiente viene listo desde el primer día:

• autenticación con eID y Google, sesiones (JWT access + rotación de refresh),
• organizaciones y membresías, protegidas mediante RLS,
• RBAC (superadmin → admin → manager → user), registro de auditoría,
• pasarela de API (services / routes / consumers / API key / policy + telemetría),
• pipeline de IA (Gemini) — chat, STT/TTS, traducción, base de conocimiento,
• base de seguridad estricta (CSP/HSTS, allow-list de CORS, rate limit, RLS),
• observabilidad (OpenTelemetry + Prometheus + logs estructurados).

Estado: Production

Capa 4 — Productos verticales

Qué es: los productos reales derivados del Template.

Producto	Propósito	Estado
Developer Portal	Catálogo de API, puerta de entrada al registro de aplicaciones	Production
Gerege Wallet	Cartera digital del ciudadano	Parcial
Ring System	Reingeniería de procesos de servicios públicos	Parcial
Plataforma «Khurdan»	Prestación de servicios y su supervisión	Production

Ring y Khurdan funcionan sobre la línea gubernamental.

Regla de dependencias

Todo el código del ecosistema respeta el siguiente sentido de dependencia:

graph TD
    L4["Capa 4 — Productos verticales"] --> L3["Capa 3 — Base de plataforma"]
    L3 --> L2["Capa 2 — SSO / OIDC"]
    L2 --> L1["Capa 1 — eID / PKI"]
    L2 -.->|"consultas"| L0["Capa 0 — X-Road"]
    L1 -.->|"papel de CA"| L0

Regla: no se salta ninguna capa. Una aplicación de la capa 4 nunca accede directamente al eID: pasa obligatoriamente por el SSO. Esto mantiene las credenciales en un único lugar y no rompe la cadena de auditoría.

El único enlace «hacia abajo» permitido es el papel de CA del eID para X-Road; constituye la raíz de confianza y por eso queda exento de la regla de capas.