Solution Features

Passwordless Authentication

IDToken Seal eliminates passwords entirely. Authentication is based on a cryptographic identity credential derived from a trusted identity document — a government passport, national ID card, or organizational credential (such as a company badge) — confirmed through id3 face verification on the user’s smartphone.

• No passwords, no password resets — users never create, remember, or type a password. Recovery requires only re-presenting the original identity document.
• No user database — identity is self-contained in the cryptographically signed credential. The system stores only a link between the credential and the user’s device.
• Works on any device — PC, tablet, kiosk, smart TV, or any device with a browser. The user’s smartphone handles all face verification regardless of the target device.
• Seconds, not minutes — a typical authentication takes under 10 seconds from code display to access granted.

Mutual Authentication (ITU-T X.1280)

IDToken Seal implements the ITU-T X.1280 mutual out-of-band authentication protocol. Both the service and the user verify each other — not just one side.

• Service proves itself to the user — the service displays a unique one-time code (AutoPassword) that only the legitimate server can generate. A fake or phishing site cannot produce a valid code, making phishing attacks ineffective.
• User proves identity to the service — the user confirms the code on their phone and authenticates with id3 face verification technology (liveness detection + 1:1 face matching against the credential photo). The confirmation is cryptographically signed with a device-bound private key.
• Anti-forgery verification — the server signs its response with a shared secret and includes a random nonce, allowing the relying party to detect both response tampering and replay attacks.
• Real-time session updates — the browser receives live status updates (code ready, approved, rejected, expired) via WebSocket, providing instant feedback to the user.

Cryptographic Digital Identity (ISO 22376 — VDS)

Identity credentials are Visible Digital Seals — compact, cryptographically signed data structures defined by ISO 22376, derived from trusted identity documents.

• Document-anchored identity — the credential is created by reading the identity document’s NFC chip (ICAO 9303 for passports/ID cards, or the document’s own data carrier for organizational credentials), extracting identity data and the holder’s biometric photo.
• Biometric binding at issuance — a live face capture is matched against the document photo using the id3 Face SDK (passive + active liveness detection, 1:1 matching). The credential is only issued if the person present is the document holder.
• Cryptographically signed — each credential is signed with ECDSA P-256 by a certified issuer. Any modification to the credential data is instantly detectable.
• Compact and portable — the credential fits in a QR code (MessagePack-encoded payload, ~900 bytes including a compressed face photo). It can be scanned, stored, and verified without proprietary infrastructure.
• Offline verification — credentials can be verified without network access using cached trust information, ensuring resilience in disconnected environments.
• Configurable trust levels — credentials carry a trust level reflecting the issuance method: self-issued (Level 1), operator-verified with NFC (Level 2), or NFC with Active Authentication and biometric match (Level 3, eIDAS High equivalent).

International Trust Infrastructure (ISO 22385 — ESEDS)

Identity trust is anchored in an international governance framework, not in a proprietary system. The PKI trust chain is managed by a Trust Service Operator (TSO) — typically Otentik — under the governance of the VDSIC.

• Hierarchical PKI trust chain — VDSIC Governance Board → Trust Service Operator (e.g., Otentik) → Trust Service List → Certificate Authority → VDS Signing Certificate → Credential. Each level is cryptographically linked to the one above. The IDToken Seal model supports multiple TSOs.
• Governed by international standards — the trust framework follows ISO 22385 (ESEDS) with formally defined roles: governance board, scheme operators, certificate authorities, and credential issuers.
• Certificate-based authorization — signing certificates carry a UsageList extension specifying exactly which credential types they are authorized to issue. A certificate authorized for IDToken Seal cannot be used to issue other credential types.
• Revocation support — credentials can be revoked via VDS Revocation Lists (VRL) distributed through the trust infrastructure.
• Test certificate isolation — test certificates are identifiable by a dedicated OID extension and are automatically rejected in production environments.

Service Trust Establishment

Before a user can authenticate with a service, a one-time trust establishment step is required. The user scans a Service VDS — a cryptographically signed QR code displayed by the website — using the IDToken Seal app. This registers the service as trusted on the user’s device.

A Service VDS is used instead of a simple QR code because a plain QR code is merely a data carrier — anyone can generate one, and the scanning app has no way to verify who created it or whether the content is authentic. The Service VDS is a cryptographically signed credential (ISO 22376) verified by the app against the IDToken Seal server’s public key before displaying the registration screen. This prevents phishing (a fake site cannot forge a valid signature), detects tampering (any modification invalidates the ECDSA signature), and embeds verified service metadata (name, URL, scopes) directly in the signed payload — no additional network requests to potentially spoofed endpoints.

• Explicit user opt-in — the user physically scans the service’s QR code on the website, making the trust decision deliberate and visible. No service can send authentication requests to a user without the user having first chosen to trust it.
• Cryptographic service identity — the Service VDS is a Visible Digital Seal (ISO 22376) signed by the IDToken Seal server’s ECDSA key. It contains the service’s name, URL, description, and the scopes it is authorized to request. A fake website cannot forge a valid Service VDS without the server’s private key.
• One-time registration — scanning is done once per service. After registration, future authentications use the standard push-based flow (enter token ID, receive OTP, confirm with face verification). No repeated scanning needed.
• Informed consent at registration — the app shows the service’s full scope ceiling (the maximum data it can ever request) before the user approves. The user knows upfront what a service can ask for.
• Trusted services list — the app maintains a list of registered services visible to the user. Services can be removed at any time, immediately revoking the service’s ability to request authentication.
• Push notification filtering — the app rejects push notifications from services not in the user’s trusted list, preventing unwanted authentication prompts from unknown services.
• Server-side binding — the IDToken Seal server stores the user-service relationship and enforces it: authentication requests for a service are rejected if the user has not registered that service.

Privacy & Selective Disclosure

Users control exactly what personal information is shared with each service, following GDPR data minimization principles. See Selective Disclosure for full details.

• Granular scope system — identity attributes are organized into scopes that services request and users approve. A bar requests identity:age_over_18; a government portal requests identity:full.
• Derived claims — computed attributes that answer a question without revealing the underlying data. age_over_18 returns true/false without disclosing the date of birth. is_eu_citizen returns true/false without disclosing the nationality. name_initial returns “J. D.” without the full name.
• Consent screen on mobile — before approving, the user sees exactly which data the service is requesting and can selectively decline individual attributes.
• Cryptographic consent binding — the granted scopes are included in the ECDSA signature from the mobile app. The server cannot add scopes after the user’s face verification approval.
• Service-level access control — each registered service declares which scopes it is allowed to request. The server rejects scope overreach before the authentication flow even starts.
• Immutable consent log — every consent decision is recorded: what was requested, what was granted, what was denied, by whom, and when. Supports GDPR data subject access requests.

Mobile Application

The IDToken Seal mobile app (Flutter, iOS + Android) serves as the user’s credential wallet, OTP verifier, and cryptographic authenticator.

• Credential wallet — stores the IDToken Seal VDS (decoded identity data + biometric photo + original QR code) in encrypted device storage (iOS Keychain / Android EncryptedSharedPreferences).
• Hardware-bound keys — the ECDSA P-256 private key is generated in the device’s secure element (iOS Secure Enclave / Android Keystore with StrongBox). The key is non-exportable.
• id3 face verification — every authentication approval requires a live face capture matched against the credential photo using id3 Face SDK (passive + active liveness detection, 1:1 matching). This verifies that the person approving is the credential holder, not just someone with access to the device.
• OTP verification — the app displays the server-generated code alongside the code shown on the browser/kiosk, enabling the user to visually confirm they are authenticating with the legitimate service.
• Push-based activation — FCM data messages deliver authentication requests silently (no lock screen notification). The app opens to the approval screen with the code, service name, and requested scopes.
• Service registration via QR scan — scanning a Service VDS QR code displayed on a website registers the service in the app. The app verifies the server signature, shows the service identity and scope ceiling, and asks the user to confirm trust.
• Trusted services management — the app displays all registered services with their name, registration date, authorized scopes, and last use. Users can remove a service at any time to revoke its access.
• Enrollment with liveness — scanning the IDToken Seal QR code triggers local VDS verification, face liveness detection, and 1:1 face matching against the credential photo, all before device registration.
• Consent history — the app maintains a local log of what data was shared with which service and when.

VDS Issuance (BioSeal)

Credential issuance is handled by the BioSeal Issuance Service — a managed platform from id3 Technologies. All issuance requests are gated by the IDToken Seal Auth Server for issuance integrity.

• Document reading — NFC chip reading (ICAO 9303 for passports/ID cards, or organizational data carrier) with cryptographic verification of the document’s origin.
• Biometric verification — live face capture matched against the document photo using id3 Face SDK with passive and active liveness detection.
• HSM-backed signing — credentials are signed via Hardware Security Module (PKCS#11) with ECDSA P-256. Private signing keys never leave the HSM.
• Compact photo encoding — face photos are compressed to WEBP at 200x200px (~900 bytes), enabling the full credential to fit in a standard QR code.
• Audit trail — every issuance is logged with token ID, timestamp, operator identity, and the certificate used for signing.

SAML 2.0 Identity Provider

The IDToken Seal server can act as a SAML 2.0 Identity Provider, enabling passwordless authentication for any SAML-capable enterprise system without modifications to the Service Provider.

• Drop-in SSO replacement — corporate intranets, government portals, and SaaS platforms that support SAML can accept IDToken Seal authentication by adding the IdP metadata URL to their configuration.
• Standard bindings — supports HTTP-Redirect and HTTP-POST bindings for AuthnRequest, and HTTP-POST for SAML Response delivery.
• Signed assertions — SAML Assertions are XML-DSIG signed (RSA-SHA256 or ECDSA-SHA256). Optional assertion encryption (AES-256-CBC + RSA-OAEP) for Service Providers that require it.
• Trust level enforcement — Service Providers can declare a minimum trust level. Users with insufficient trust level receive a SAML error rather than an assertion with insufficient assurance.
• Scoped attributes in SAML — selective disclosure applies to SAML assertions identically to JWT: only consented attributes appear in the AttributeStatement.
• Single Logout — SP-initiated and IdP-initiated SLO, with session invalidation and signed LogoutResponse.
• SP registry — Service Providers are registered with entity ID, ACS URL, signing/encryption certificates, NameID format preference, and custom attribute mapping.

Administration Console

The IDToken Seal Admin Console provides centralized management of the authentication ecosystem.

• Enrollment management — searchable list of all enrolled credentials with filtering by trust level, revocation status, and date range. Detail view shows identity metadata and authentication history.
• Token revocation — operators can revoke credentials with a reason (lost device, compromised, expired document, user request). Revocation propagates immediately — no per-service action required.
• Real-time session monitoring — live feed of pending authentication sessions with countdown timers, status badges, and service identification.
• Audit log viewer — searchable, filterable view of the immutable audit trail with color-coded event types, token/session drill-down, and CSV export.
• Trust health dashboard — certificate inventory with expiry warnings, trust list freshness indicators, and VRL status.
• Role-based access — Super Admin (full access), Operator (revoke, view enrollments/audit), Auditor (read-only). All roles authenticate via IDToken Seal itself (dogfooding).
• Statistics — authentication success rates, enrollment counts, session volume charts, and rate limit monitoring.

Verifiable Credentials for Digital Wallets

Beyond login sessions, IDToken Seal can issue W3C Verifiable Credentials — standardized digital identity proofs that users store in wallet apps and present on demand, even offline. See Verifiable Credentials for the full technical specification.

• Standards-compliant format — credentials follow the W3C Verifiable Credentials Data Model 2.0 in JWT-VC format (vc+jwt), signed with ES256.
• Same authentication, different output — the user goes through the same X.1280 flow (OTP + face verification). Instead of a session JWT, the result is a portable credential the user keeps.
• Wallet-ready — compatible with the European Digital Identity Wallet (EUDIW), and any wallet that supports OID4VCI (OpenID for Verifiable Credential Issuance) discovery.
• Selective disclosure — uses the same scope system as all other integration methods. An age verification credential proves “over 18” without revealing the date of birth.
• VDS-backed evidence — every credential includes an evidence field linking back to the Visible Digital Seal and its PKI trust chain, proving the identity claims originate from a verified document — not a self-declared account.
• Credential revocation — uses the W3C Bitstring Status List. When an enrollment is revoked, the credential’s status is updated in a published, cacheable status list that verifiers can check without contacting the issuer.
• Decentralized issuer identity — the issuer is identified by a did:web Decentralized Identifier, resolved via a standard DID document over HTTPS. No blockchain required — trust is anchored in DNS + TLS + the VDS PKI chain.

Enterprise Integration

• JWT for modern services — authentication produces a signed JWT (ES256) with scoped identity claims. Relying services verify using the server’s public key via the JWKS endpoint (/.well-known/jwks.json). See the Integration Guide.
• OpenID Connect — standard OIDC provider with discovery, authorization endpoint, and token endpoint.
• SAML for legacy systems — the same authentication flow produces SAML assertions for enterprise Service Providers that have not yet migrated to OIDC/JWT.
• Verifiable Credentials — issue W3C Verifiable Credentials for digital wallet ecosystems (EUDIW, eIDAS 2.0).
• Service registration — relying parties register with their allowed scopes, display name, and logo. The mobile app shows the service identity on the consent screen.
• Cloudflare-ready deployment — designed to run behind Cloudflare for TLS termination, DDoS protection, WebSocket proxying, and JWKS edge caching.

Security

See the Security Model and Security & Deployment pages for the full threat analysis and hardening guidelines.

• Phishing-proof by design — the out-of-band model means the OTP is generated by the server and displayed to the user. A phishing site cannot generate a valid OTP because it does not have the server’s secret key material. Additionally, a fake website cannot produce a valid Service VDS, so users cannot be tricked into registering a malicious service.
• No credential theft — there are no passwords to steal, no password hashes to crack, no session cookies to hijack. The private key never leaves the device’s secure element.
• User-controlled service access — services can only request authentication from users who have explicitly registered them by scanning the Service VDS. Users can revoke service access at any time.
• Replay protection — single-use sessions, timestamp validation (±30 seconds), and brute force protection (3 attempts per session).
• Rate limiting — configurable per-IP limits on authentication and enrollment endpoints, plus separate limits for admin API access.
• Immutable audit trail — all security-relevant events are logged to a database table with PostgreSQL rules preventing modification or deletion.
• Security headers — CSP, HSTS, X-Frame-Options, and other protective headers via Helmet. CORS restricted to explicitly allowed origins.

Standards Compliance

Standard	Role in IDToken Seal
ITU-T X.1280	Mutual out-of-band authentication protocol — the core authentication flow
ISO 22376 (VDS)	Visible Digital Seal format — the identity credential structure, encoding, and signature
ISO 22385 (ESEDS)	PKI governance framework — trust chain from international governance board to credential issuer
ICAO 9303	Machine-readable travel documents — passport NFC chip reading at issuance
SAML 2.0	Enterprise SSO federation — identity provider for corporate Service Providers
CBEFF	Biometric data format — face photo encoding within the VDS payload
eIDAS	Trust level mapping — Level 2 (Substantial) and Level 3 (High) alignment