Security

1 · Key custody — who holds what

When you create an identity, an Ed25519 keypair is generated inside your browser using the Web Crypto stack. The private key is 32 bytes of randomness that has never existed anywhere else. It is sealed with AES-GCM under a key derived from your PIN with PBKDF2 at 600,000 iterations, and stored only in your browser’s IndexedDB.

The platform receives the public key and your derived address — nothing more. The private key is never transmitted, never copied to a server, never written to a log. Legacy server-side key handling was removed from the API entirely: those endpoints now return 410 Gone permanently.

Consequence you must understand: the PIN cannot be reset or recovered by anyone, including you. Recovery exists for exactly this case — and only with proofs you set up in advance.

2 · Authentication — proof without transmission

Signing in is a three-move challenge-response. Your device asks the platform for a one-time challenge bound to your address; the challenge expires in five minutes and is consumed on first use. Your device signs the challenge with the private key; the platform verifies the signature against your registered public key.

A valid signature is mathematical proof that the private key was present — the key itself never crosses the network. There is no password, so there is nothing to phish, replay, or leak. Sessions are bearer tokens held by your browser only.

Sessions expire. When they do, the client detects the expiry and returns you to sign-in with an explanation — a stale session never leaves you on a broken screen.

3 · The verification ceremony

Identity verification is a server-owned protocol, not a self-assessment. The platform creates a short-lived session carrying a single-use cryptographic nonce. Every capture is a multi-frame bundle: each frame is hashed, the hashes are chained, and the chain is signed with your identity key over canonical JSON bound to the session nonce.

The server verifies the signature against your registered public key, recomputes the hash chain, and enforces the session state machine. A capture from another session, another person, or yesterday is structurally unusable. Replay, tampered signatures, cross-session nonce substitution, and session hijack are all rejected — and were all tested against the live protocol.

Client-side measurements (motion, face presence where the browser supports it) are recorded as claims. They can inform review decisions, but they can never alone produce a verified verdict: authoritative biometric decisions belong to the operator path, by design. Read the full flow on the verification page.

4 · Recovery — the 24-hour design

Anyone can initiate a recovery for any address; that is intentional, because initiation is proofless and therefore harmless. The moment a recovery starts, the wallet owner is notified and can cancel it with one action from the Recovery page.

Nothing can complete for 24 hours. After the waiting period, completion still requires a per-method proof: a one-time backup code provisioned in advance, a trusted-device token, or signatures from a majority of your enrolled guardian wallets.

On completion, your address stays the same and a new key takes over, recorded on chain. The old key — lost, stolen, or obsolete — becomes permanently invalid.

5 · The chain of record

Registrations, verifications, recoveries, and key rotations are applied to XityChain state. Public read paths redact identity payloads and strip signatures so transactions cannot be fingerprinted: the public learns that an event happened, and when — never its contents.

The machine-readable strip on your identity card uses the genuine ICAO 9303 check-digit algorithm over real card fields, so any party can verify the encoding rather than trusting the rendering.

6 · Privacy engineering

Claims you store — your declared name, your photograph, your face-s enrolment — live in your vault as integrity-sealed records, disclosed only through permissions you grant and can let expire. The photograph is processed on your device; the automated comparison, when models are available, runs in your browser.

The privacy notice lists every purpose and lawful basis, and names what is deliberately never collected: your PIN, your private key, your documents, anything you never entered.

7 · Honest limits — what this does not yet do

A trustworthy system states its boundaries. During the development phase: verification codes are delivered by the operator from the platform log, not yet by email/SMS gateways. Face matching runs client-side where models can load; the authoritative server-side verifier (with presentation-attack detection) is the next phase. Notifications and pending-recovery lists are held in platform memory — a restart clears them (fail-closed: an in-flight recovery dies and must re-serve its full window). The web client cannot perform NFC document reading or hardware-depth capture; those belong to the native client milestone.

Nothing on this site claims a capability that was not actually performed. Where a feature is pending, the interface says so.