Architecture
The IDToken Auth Server is the central orchestrator of the X.1280 passwordless authentication protocol. It connects browsers, mobile apps, and relying parties through a trust chain anchored in government-issued documents.
End-to-End Overview
Section titled “End-to-End Overview”Issuance (left) happens once: a government document is read, the holder’s face is verified, and a cryptographically signed VDS credential is stored on their mobile device. Authentication (center) happens on every login: the browser displays a server-generated OTP, the Auth Server pushes it to the mobile app, and the user confirms by matching the code and completing a biometric check. The app then signs the response and POST /verify returns a JWT. Trust Infrastructure (right) underpins both: the Auth Server walks the PKI chain — from the VDSIC Governance List down to the signing certificate — to verify every VDS credential it encounters.
Network Topology
Section titled “Network Topology”System Components
Section titled “System Components”| Component | Role |
|---|---|
| IDToken Auth Service | Central orchestrator — implements the X.1280 passwordless protocol. Manages enrollment, OTP generation, push delivery, session state, VDS verification, and JWT issuance. Exposes REST + WebSocket APIs and can act as a SAML 2.0 IdP. |
| IDToken Mobile App | Receives push notifications, displays the OTP for user comparison, performs face-match liveness verification, signs the auth response with the device ECDSA key, and stores the user’s VDS credential. |
| Web Browser | Initiates the auth session, displays the server-generated OTP, and receives real-time status updates (approved/rejected) over WebSocket. |
| BioSeal Issuance Service | Reads official documents (MRZ + NFC), performs face liveness and 1:1 match, and produces the cryptographically signed VDS credential stored on the mobile device. |
| Push Service (FCM) | Delivers push notifications from the Auth Service to the mobile app over an out-of-band channel. |
| PostgreSQL | Stores enrollments, registered services, and the immutable audit log. |
| Redis | Manages active sessions, caching, and pub/sub for real-time WebSocket event delivery across multiple server instances. |
| Trust Infrastructure | The PKI chain (VDSIC Governance List → Scheme Operator → TSL → CA → Signing Certificate) that the Auth Service walks to verify every VDS credential. |
Trust Chain
Section titled “Trust Chain”The Auth Server walks this chain top-down for every VDS credential it encounters. Starting from the VDSIC Governance Board — the global root of trust — each level is cryptographically linked to the next: the Governance List references recognized Scheme Operators, Otentik’s Scheme List defines the IDToken Manifest and its authorized Trust Service Lists, each TSL catalogs the Certificate Authorities under that scheme, and the CA issues the signing certificate whose UsageList OID must match the manifest. At the bottom, the actual ECDSA signature is verified against the certificate’s public key using a double SHA-256 hash of the VDS header and payload. All trust artifacts are cached in Redis with a configurable TTL for offline verification.
See Trust Architecture for the full verification process.
Design Principles
Section titled “Design Principles”| Principle | Description |
|---|---|
| No user database | Enrollments link a VDS token identifier to a mobile device public key. Identity comes from the VDS itself — the server stores no personal data. |
| Server-generated OTP | The one-time password is derived from a server-side master secret and session context, not a shared TOTP/HOTP seed. |
| Out-of-band delivery | The OTP reaches the mobile app via push notification (a separate channel from the browser), preventing man-in-the-middle interception. |
| Real-time browser updates | WebSocket connections deliver session state changes (OTP ready, approved, rejected) instantly to the browser, backed by pub/sub for multi-instance deployments. |
| Immutable audit trail | All security-relevant events are logged to an append-only store. Updates and deletions are blocked at the database level. |
Go Deeper
Section titled “Go Deeper”- Authentication Flow — Protocol-level detail of the X.1280 phases with API formats
- Trust Architecture — Full PKI governance chain verification process
- Security Model — Cryptographic algorithms, OTP derivation, and threat model
- Security & Deployment — Deployment topology, key management, and monitoring