Security & Deployment
This page describes the IDToken Seal security model — how it protects users, services, and identity data. For a higher-level overview of why IDToken Seal is trustworthy, see the Introduction.
Security Model
Section titled “Security Model”Defense in Depth
Section titled “Defense in Depth”IDToken Seal applies multiple independent security layers. Compromising one layer does not compromise the system:
| Layer | What it protects | How |
|---|---|---|
| Transport encryption | Data in transit | TLS 1.3 for all connections (HTTPS and WebSocket Secure) |
| Mutual authentication | Against phishing and impersonation | Out-of-band OTP verification — both the service and the user prove their identity to each other (X.1280) |
| Document-anchored identity | Against fake accounts | Identity is derived from a trusted document (passport, national ID, organizational credential), not self-declared |
| Biometric verification | Against device theft | Every authentication requires a live face match against the credential photo |
| Hardware-bound keys | Against key extraction | The mobile app’s private key is stored in the device’s secure element and cannot be exported |
| Cryptographic signatures | Against tampering | All tokens, assertions, and credentials are signed with ECDSA and verified by relying parties |
| Selective disclosure | Against over-sharing | Users approve each data scope individually; consent is cryptographically bound to the authentication |
Threat Mitigations
Section titled “Threat Mitigations”| Threat | Mitigation |
|---|---|
| Brute-force attacks | OTP attempts are strictly limited per session; rate limiting is enforced on all authentication endpoints |
| Replay attacks | Sessions are single-use and short-lived; each is deleted after the first verification attempt resolves |
| Man-in-the-middle | OTP is delivered out-of-band (push notification), not through the browser session; response integrity is verified via cryptographic hash |
| Phishing | Mutual authentication — the user verifies the service by matching the displayed code. A fake site cannot produce a valid code without the server’s key material. Additionally, Service VDS registration prevents users from trusting unverified services. |
| Timing attacks | Constant-time comparison is used for all security-sensitive token and code verification |
| Data breaches | No password database exists to steal. The server stores only public key bindings, not identity data. Identity claims are derived from the VDS at authentication time. |
| Credential theft | No passwords, no session cookies to hijack. The private key never leaves the device’s secure element. |
| Unauthorized data access | Services declare allowed scopes at registration; the server rejects scope overreach before the authentication flow starts |
Cryptographic Standards
Section titled “Cryptographic Standards”All cryptographic operations use well-established, standards-compliant algorithms:
| Purpose | Standard |
|---|---|
| Identity credential signatures | ECDSA with P-256 curve (ISO 22376) |
| Token and assertion signing | ECDSA with P-256 (ES256) |
| OTP derivation | HMAC-based key derivation (HKDF-SHA256) |
| Response integrity | HMAC-SHA256 |
| SAML assertion signing | ECDSA or RSA with SHA-256 |
Private keys are generated with cryptographically secure randomness, stored with restricted access, and rotated according to the operator’s key management policy.
Audit Trail
Section titled “Audit Trail”All security-relevant events are recorded in an immutable, append-only audit log:
- Authentication attempts (success, failure, timeout)
- Enrollment and revocation events
- Consent decisions (what was requested, what was granted, what was denied)
- Administrative actions (operator login, configuration changes)
The audit log cannot be modified or deleted after the fact. OTP values are never stored in plaintext. See Admin Console for audit log access.
Deployment Overview
Section titled “Deployment Overview”IDToken Seal is designed for high-availability production deployment:
- Horizontally scalable — multiple server instances behind a load balancer, with no sticky sessions required
- Real-time event delivery — WebSocket notifications are correctly routed regardless of which instance the client is connected to
- Edge-protected — designed to run behind a reverse proxy that handles TLS termination, DDoS protection, and WebSocket proxying
- Health monitoring — a health check endpoint reports the status of all dependencies for use with load balancer probes and container orchestration
Database Migrations
Section titled “Database Migrations”Schema migrations run automatically on server startup and are idempotent — safe to run multiple times without side effects. The migration sequence covers enrollment storage, session management, the immutable audit log, operator management, service provider registration, and consent tracking.
Compliance
Section titled “Compliance”| Requirement | How IDToken Seal addresses it |
|---|---|
| GDPR data minimization | Selective disclosure ensures services receive only the claims they need and the user approves |
| GDPR right of access | The immutable audit log provides a complete record of what data was shared, with whom, and when |
| eIDAS assurance levels | Trust levels map to eIDAS Low, Substantial, and High based on the credential issuance method |
| No user database | The server stores no personal identity data — only public key bindings. Identity claims are derived from the cryptographically signed VDS at authentication time. |