How identity verification works

Verification begins when the platform — not your browser — creates a session: a cryptographic identifier, a single-use nonce, and a ten-minute expiry. The client never creates trusted state. Everything that follows is bound to this session: a capture from another session, another person, or yesterday is structurally unusable.

Signing a verification capture is a sensitive action. Before the scan, you enter your PIN; it unlocks the private key for the duration of the ceremony only. The key exists in one function’s scope and is never written anywhere.

The camera captures three guided poses — centre, left, right — as multi-frame bundles. Between frames, motion is measured: a live face moves; a photograph held to the lens does not. Where the browser exposes face detection, presence is checked per frame and the result recorded — including “not available” when it is not.

Each pose becomes a manifest: one SHA-256 per frame, the hashes chained (each link hashing the previous), and the whole manifest signed with your identity key over canonical JSON that embeds the session nonce. The server verifies the signature against your registered public key and recomputes the hash chain from the submitted hashes — substitution, reordering, or removal breaks it.

You present the photo page of your identity document. It is stored as a claim in your vault, integrity-sealed like every claim, and disclosed only through permissions you grant.

Where face-recognition models can run in your browser, the live scan’s multi-frame representation is compared against the document photograph (128-dimension descriptors, Euclidean distance, published threshold). The verdict — matched, not matched, or comparison unavailable — is recorded with the actual distance. It is labelled exactly as what it is: a client-side check. Authoritative biometric verification belongs to the operator path and cannot be self-asserted. A modified client could fake a local match; that is why local results inform review but never alone produce a verified credential.

On devices with fingerprint or face scanners, you can register a WebAuthn platform credential. The system never touches your fingerprint: the secure enclave verifies you locally and proves it cryptographically. Once registered, signing in on that device requires your biometrics in addition to your PIN.

The decision engine runs server-side over hard gates — session validity, signature, nonce, hash chain, evidence completeness — each with an internal reason code logged for audit. What you see is a plain verdict and a non-revealing message. Incomplete evidence returns retry, never success; a security failure returns rejection; a missing capability returns review — never a fabricated pass.