eID Mongolia¶
Production · Couche 1 — Noyau identité / PKI ·
Dépôt : eid-platform-mn · eidmongolia.mn
La plateforme eID nationale de Mongolie (dans l'esprit Smart-ID / eIDAS). Toute authentification et toute signature de l'écosystème reposent en dernier ressort sur elle. Une seule base de code sert les deux marques — eID Mongolia et Gerege — via des variantes d'application.
Ce qu'elle fait¶
- Identifie et authentifie les citoyens — par QR code, deep link mobile, ou notification push envoyée au titulaire d'un numéro d'état civil donné.
- Signature juridiquement valable — signature PAdES sur PDF, avec horodatage RFC 3161.
- Tout le cycle de vie du certificat — émission (CA), vérification de validité (OCSP/CRL), révocation.
- KYC — vérification via DAN, avec contrôle de vivacité par reconnaissance faciale.
Choix cryptographiques centraux¶
ECDSA à seuil 2-of-2¶
La clé privée de signature n'existe entièrement nulle part. Elle est scindée en deux parts : l'une sur le téléphone de l'utilisateur, l'autre sur le serveur. Produire une signature exige la participation des deux parties (variante à trois tours du protocole de Lindell).
Ce que cela implique : un téléphone volé ne permet pas de signer, un serveur compromis non plus. Aucune des deux parties ne peut signer seule au nom de l'utilisateur.
Double clé, double certificat¶
Chaque citoyen détient deux certificats :
| Certificat | PIN | Objet |
|---|---|---|
| Authentication | PIN1 | Se connecter à un système |
| Signing | PIN2 | Signature juridiquement valable |
Cette séparation est essentielle : se connecter ne veut jamais dire que l'utilisateur a donné son accord à quelque chose. Une signature exige un PIN distinct, une clé distincte et un consentement distinct — c'est le fondement de la non-répudiation.
Identifiants¶
| Type | Format | Base |
|---|---|---|
| Personne physique | PNOMN-<civil_id> |
Standard ETSI ID |
| Organisation | NTRMN-<registration> |
Standard ETSI ID |
L'identifiant interne est civil_id (le numéro d'état civil). Pour les
règles de casse des identifiants, voir
Conventions communes.
Structure¶
| Composant | Technologie | Rôle |
|---|---|---|
server/ |
Go (chi + pgx) | Backend RP-API : enrôlement, signature à seuil, CA/OCSP/CRL, admin, KYC |
web/ |
Next.js | Démo RP navigateur — connexion et signature par QR / push |
admin/ |
Next.js | Console d'administration — RP / utilisateurs / certificats / sessions |
ios/ |
Swift | SDK SPM GeregeSmartID + application eID Mongolia |
android/ |
Kotlin / Compose | SDK mn.eidmongolia.smartid + application d'exemple |
desktop/ |
Swift + .NET | Client RP macOS / Windows + kit de jeton USB |
sdk/ |
TypeScript | SDK web côté RP |
Services PKI¶
| Service | Adresse | Description |
|---|---|---|
| CA | eidmongolia.mn |
Autorité de certification |
| OCSP | ocsp.eidmongolia.mn |
Vérification de validité des certificats en temps réel |
| CRL | publiée par la CA | Liste des certificats révoqués |
| TSA | tsa.timeserver.mn |
Horodatage RFC 3161 |
Protection des clés : des HSM sont utilisés — un appareil sur site et un HSM cloud configurés en bascule mutuelle.
Le rôle de CA pour X-Road
eID Mongolia assure également le service de confiance (CA, OCSP) de X-Road Mongolia. La couche 1 fournit donc à la couche 0 sa racine de confiance — la seule dépendance « vers le bas » que l'écosystème autorise.
Voies d'intégration (en tant que RP)¶
Un tiers se raccorde à l'eID de deux manières.
1. Par le SSO (recommandé). L'application se connecte à Gerege SSO en tant que RP OIDC, et l'authentification eID a lieu au niveau du SSO. Dans la plupart des cas, c'est le bon choix : vous n'écrivez aucun code PKI, seulement de l'OIDC standard.
2. Devenir RP direct. Lorsqu'une intégration profonde est nécessaire — par exemple intégrer le parcours eID dans votre propre application mobile — vous vous enregistrez comme RP directement auprès de l'eID. Vous utilisez alors les SDK iOS / Android / TypeScript.
La règle RP ↔ rp_app
Seul le RP est enregistré auprès de l'eID. Si un même RP couvre
plusieurs applications ou sous-systèmes, transmettez-les via les champs
rp_app / rp_app_url : les journaux et l'écran de l'utilisateur
montreront alors quelle application a émis la demande. Inutile d'enregistrer
un RP distinct par application.
Compatibilité au niveau du protocole¶
Le serveur Go, le SDK iOS et le SDK Android parlent un protocole fixe unique. La sérialisation cryptographique doit être identique octet par octet de tous les côtés. Ce contrat est verrouillé par des golden vectors gelés — voir Stack technique pour le détail.
Documentation détaillée¶
La documentation technique complète de la plateforme (étapes d'intégration
RP, référence des SDK, onboarding PKI/CA, guide de la console
d'administration) se trouve sur son propre site de documentation, dans le dépôt
eid-platform-mn. Chapitres principaux :
- Concepts — l'eID à deux certificats · Identifiants · PKI personnelle
- Intégration (RP) — intégration RP · intégration Gerege · sous-systèmes RP · SDK TypeScript · démo Web RP · intégration des organisations
- SDK clients / applications — iOS · Android · clés biométriques · macOS · Windows · kit de jeton USB
- Exploitants — console d'administration · multilinguisme
- PKI / CA — onboarding CA · authentification passive du passeport · reconnaissance faciale