分层架构¶

生态系统由五层构成。下层为上层服务；上层不了解下层的内部结构，只通过下层的契约（contract）与之交互。

第 4 层 — 垂直产品 (vertical)
    ring.dgov.mn          Ring System — 流程再造
    hurdan.dgov.mn        「Khurdan」平台 — 服务交付与监管
    developer.gerege.mn   Developer Portal（另有 dgov 版本）
    wallet.gerege.mn      Gerege Wallet — 公民数字钱包

第 3 层 — 平台底座
  -- 第二代：Nexus — 模块化单体，应用商店
    nexus.gerege.mn       Gerege Nexus — upstream，8 个模块
    eduge.mn              Eduge.mn — 行业品牌分叉
    （域名待定）          Gerege SSO — 聚焦登录的分叉
  -- 第一代：Template — 每个仓库一个分叉
    template.gerege.mn    Gerege Template Platform
    template.dgov.mn      Government Template Platform V3.0（+ Node.js 移植版）
    gerege.mn             Gerege Platform（自身即 SSO 提供方）
    → Clean Architecture Go + Next.js BFF + Gemini AI 流水线

第 2 层 — 认证 / SSO (OIDC provider)
    sso.gerege.mn   Gerege SSO          sso.dgov.mn      Government SSO
    dan.gerege.mn   DAN Gateway         gsign.gerege.mn  G-Sign
    → 自研 Go OAuth2/OIDC 代码（已完全替代 Hydra），单一数据库
    → eID 代理：仅把获授权的 eID 服务转发给已注册的应用

第 1 层 — 身份 / PKI 内核
    eID Mongolia (eid-platform-mn)
    server (Go) · web · admin · iOS SDK · Android SDK · macOS/Windows
    2-of-2 门限 ECDSA · 双密钥 / 双证书（PIN1 登录 / PIN2 签名）
    CA · OCSP · CRL · TSA

第 0 层 — 数据交换
    X-Road 实例 MN — central server、各 security server
    周边服务：xyp.gerege.mn（法人主体查询）

第 0 层 — 数据交换¶

是什么：机构之间标准化的数据交换通道——X-Road （实例 MN）。

职责：成员机构以经过认证、带签名、带时间戳的方式互相调用服务。每台 security server 代表其所属成员，central server 则对信任清单（globalconf）签名并分发。

特别关联：eID Mongolia 为 X-Road 承担 CA（证书颁发机构）职责—— 也就是说，第 1 层为第 0 层提供了信任根。

状态：部分完成 central server 与首批 security server 已上线运行，拓扑已确定；大规模推广仍在进行。

第 1 层 — 身份 / PKI 内核¶

是什么：eID Mongolia——国家级 eID 平台（Smart-ID / eIDAS 风格）。

职责：识别公民与机构、完成登录，并让其能够作出具法律效力的签名。同时覆盖证书的完整生命周期：签发（CA）、有效性校验（OCSP/CRL）、时间戳（TSA）。

关键设计：

2-of-2 门限 ECDSA——签名私钥在任何一方都不完整存在。
双密钥 / 双证书——PIN1 → 登录，PIN2 → 签名。
标识符为 civil_id；ETSI ID 对自然人为 PNOMN-<civil_id>，对机构为 NTRMN-<...>。
KYC——通过 DAN 完成，并以人脸识别做活体检测。

谁在用：第 2 层（SSO）直接使用；第 3–4 层经由 SSO 使用。

状态：Production

第 2 层 — 认证 / SSO¶

是什么：OAuth2/OIDC 提供方——Gerege SSO （sso.gerege.mn）与 Government SSO（sso.dgov.mn），以及周边服务 DAN Gateway 和 G-Sign。

三项职责：

身份提供方——RP 可以提供 Sign in with Gerege。支持 Authorization code
PKCE (S256)、轮换式 refresh token（带重用检测）、client_credentials。
eID 代理——获授权的 eID 服务只转发给已注册的应用。应用不会直接访问 eID。
应用注册的唯一场所——OAuth client 与 client secret 只在此创建、只在此存放。

不再依赖 Hydra

此前使用 Ory Hydra，现已把必需的机制改写为自研 Go 代码。原本独立的 Hydra 数据库已并入主库。由此同时降低了三项成本：外部依赖、迁移复杂度、运维开销。

状态：Production

第 3 层 — 平台底座¶

这一层如今有两代。两代都在 production 运行，两者之间的迁移正在进行。

第二代 — Gerege Nexus Production¶

是什么：一个模块化单体平台——业务模块实现 Go 的 Module 契约并编译进 同一个二进制；某个租户启用了哪些应用，由 PostgreSQL 中的应用商店 （app_installations）决定。

变了什么：在第一代里，新产品意味着分叉模板。在 Nexus 上，新产品通常是 一个新模块——若是新品牌，则是从 upstream 分叉，并通过合并保持更新。

	第一代（Template）	第二代（Nexus）
新产品	分叉模板	编写模块，或为品牌分叉
分发	每个仓库一套部署	按租户，通过应用商店
代码如何流动	`open-gerege-core` · `@gerege/ui-core` 包	Upstream → 分叉从中合并
模块间调用	HTTP	进程内 Go 调用

现有分叉：nexus.gerege.mn（upstream，参考部署）· eduge.mn（教育行业）· Gerege SSO（聚焦登录层，尚无域名）。

随平台提供的八个模块：Contacts · Products · Inventory · Billing & e-Barimt · Digital Documents · Developer Portal · PDF E-Sign（eID PIN2）· 政务服务（可配置流程、层级、SLA）。

Nexus 并不取代第 2 层

Nexus 自带 OAuth2/OIDC 提供方，但它服务的是该部署自己的租户与第三方客户端。在整个生态系统范围内，识别公民的唯一途径仍然是第 2 层——Nexus 同样从不直接触及 eID。

第一代 — Template Platform Production¶

是什么：Template Platform——用于构建数字服务、可直接投产的底座；以及 Gerege Platform，即能够自身充当 SSO 提供方的增强版本。

职责：启动一项新服务时，以下能力从第一天起即可用：

eID 与 Google 认证、会话（JWT access + refresh 轮换）；
组织与成员关系，并由 RLS 保护；
RBAC（superadmin → admin → manager → user）、审计日志；
API 网关（services / routes / consumers / API key / policy + 遥测）；
AI 流水线（Gemini）——聊天、STT/TTS、翻译、知识库；
严格的安全基线（CSP/HSTS、CORS 白名单、限流、RLS）；
可观测性（OpenTelemetry + Prometheus + 结构化日志）。

状态：Production

第 4 层 — 垂直产品¶

是什么：由 Template 分支出来的实际产品。

产品	用途	状态
Developer Portal	API 目录、应用注册的入口	Production
Gerege Wallet	公民数字钱包	部分完成
Ring System	政务服务流程再造	部分完成
「Khurdan」平台	服务交付与监管	Production

Ring 与 Khurdan 运行在政务线上。

依赖规则¶

生态系统的全部代码都遵循以下依赖方向：

graph TD
    L4["第 4 层 — 垂直产品"] --> L3["第 3 层 — 平台底座"]
    L3 --> L2["第 2 层 — SSO / OIDC"]
    L2 --> L1["第 1 层 — eID / PKI"]
    L2 -.->|"查询"| L0["第 0 层 — X-Road"]
    L1 -.->|"CA 职责"| L0

规则：不得跨层直接访问。例如第 4 层的应用不会直接访问 eID——必须经由 SSO。这样既把凭据集中在一处，也保证审计链路不被打断。

唯一被允许的「向下」连接是 eID 为 X-Road 承担 CA 职责；它构成信任根，因此不受分层规则约束。