Documents, signing, files¶
Everything that happens at the counter has to leave a trace that cannot be denied. This section covers legally valid signing, the personal assets used in it, and file storage and integrations.
Digital signing (PAdES)¶
Server-side PDF signing runs through the eID Mongolia /v3 API. There are
two shapes:
| Shape | Endpoints | Used for |
|---|---|---|
| Detached (digest) | POST /api/v1/sign/initiate → GET /api/v1/sign/status/{sid} |
Signing a SHA-256 digest only — transfers and transactions |
| PDF (PAdES) | POST /api/v1/sign/init → GET /api/v1/sign/{id} → GET /api/v1/sign/{id}/download |
Contracts, consents, official documents |
All of them require a signed-in citizen. The flow is asynchronous: init
opens a session, polling returns a pending state until the citizen approves in
their eID app, and download then returns the signed PDF.
UI: /me/eid/sign.
Sign relay — third-party RPs¶
eID Mongolia's /v3 rejects credential-less calls with 401. So a platform
that does hold credentials stands in front as a reverse proxy:
Third-party app ──► https://sso.gerege.mn/rp/sign/v3/* ──► eidmongolia /v3/*
(RP credentials added here)
Third-party apps can therefore obtain signatures without ever holding eID RP
credentials themselves. Access is controlled by the svc:eid-sign grant —
see API Gateway.
Port
In this repository's compose stack the api is exposed on loopback at
127.0.0.1:8091 so that nginx can proxy /rp/sign to it. All other app
traffic goes through the web BFF.
Personal assets¶
The image, name and stamp used in signatures are managed by the user
(/api/v1/me/*; writes carry the govWrite limiter):
| Method | Path | What |
|---|---|---|
GET PUT DELETE |
/api/v1/me/signature |
Signature image |
PUT |
/api/v1/me/latin-name |
Latin name (for international documents) |
PUT |
/api/v1/me/org-name-latin/{regNo} |
Organisation's Latin name |
GET PUT DELETE |
/api/v1/me/orgstamp/{regNo} |
Organisation stamp |
The Latin name is preferred in non-Cyrillic UI languages (en, zh); Russian
is Cyrillic, so the Mongolian-script name stays.
UI: /me/profile.
Gerege Space — the platform's own storage¶
Storage backed by the platform's own SFTP server. Each user gets a quota and
files are kept under BASE_PATH/users/<userID>/.
| Method | Path | What |
|---|---|---|
GET |
/api/v1/gspace |
File list + usage/quota |
POST |
/api/v1/gspace/upload |
Upload (rejected when over quota) |
GET |
/api/v1/gspace/download |
Download |
DELETE |
/api/v1/gspace |
Delete |
- Default quota 2 MB (
GSPACE_QUOTA_BYTES). - With
GSPACE_HOSTempty the capability is off and the UI card handles it.
Host key is mandatory
GSPACE_HOST_KEY is the SFTP host's public key. Required in
production — without it the SFTP connection fails closed. In development
an empty value is allowed without verification (MITM risk; local only).
Third-party integrations¶
Users link their own accounts to third-party services. OAuth tokens are stored AES-256-GCM encrypted at the storage layer; the domain layer only carries values.
| Provider | What it enables |
|---|---|
google-drive |
List, preview and upload files |
dropbox |
List, preview and upload files |
google-meet |
Create a meeting space |
google-login |
Account linking (part of authentication) |
Core endpoints:
| Method | Path | What |
|---|---|---|
GET |
/api/v1/integrations |
Connected providers |
POST |
/api/v1/integrations |
Connect (after the OAuth callback) |
GET |
/api/v1/integrations/{provider}/token |
Provider token (server side) |
DELETE |
/api/v1/integrations/{provider} |
Disconnect |
The BFF adds per-provider working endpoints on top —
/api/integrations/google-drive/files, /api/integrations/dropbox/upload,
/api/integrations/google-meet/create-space, and so on.
INTEGRATION_ENC_KEY
The key that encrypts those tokens. Never rotate it — the superadmin MFA TOTP secret and every integration token are encrypted with it; changing it breaks all of them.
UI: /me/integrations.