Docs · For developers

Security & responsible disclosure

Secure by design, not by obscurity. We publish how VirtualID protects your data so that customers, auditors, and independent researchers can verify it. This page is intentionally explicit.

Found a vulnerability? See Responsible disclosure below. We will not pursue legal action against good-faith research that follows this policy.

Security principles

Secure by design, not by obscurity — security never depends on the design being secret.
Least authority — every component, token, and person gets the minimum access needed. The server alone can never widen a profile's exposure.
Defense in depth — encryption, access control, network isolation, and audit logging are independent layers.
No passwords, ever — passkey (WebAuthn/FIDO2) or OAuth only.
Data minimization — least data stored, identifiers tokenized, sensitive values masked by default.
Everything is UTC and audited — security-relevant actions land in a tamper-evident log.
Your data, your call — export everything, delete with a documented grace period. GDPR by design.

What we protect & how (data-at-rest)

Data class	Protection
High-sensitivity fields (medical, government IDs, insurer/policy)	Client-side / zero-knowledge where feasible + envelope encryption; server stores ciphertext it can't read alone.
Standard shared fields	Envelope-encrypted per profile (per-profile key), wrapped by the account key.
Private notes & labels	Encrypted with your own key; counterparty and operator can't read them.
Public-profile fields	Unencrypted by definition (public tier), clearly labelled.
Consent & DPA records	Append-only, immutable, cryptographically signed.
Audit / access logs	Tamper-evident (hash-chained/signed), UTC, minimized.

Algorithms: authenticated encryption (AEAD) with per-field nonces and AAD binding ciphertext to its context (owner, field, profile) to prevent copy/replay.

Key architecture — why the operator can't silently read your data

Two-key model: a per-account key and per-profile keys. A subscription is a key grant, not a data copy.
The server alone can never widen exposure — exposure changes require the customer's account key (FR-50).
Split-key delivery: the subscriber submits a public key; profile keys are wrapped to it, bounding revocation and blast radius.
Server-assisted key storage with hardware-backed KMS/HSM for any server-held material, and a recovery path that doesn't weaken the zero-knowledge property.

Access control & revocation

ACL-first — access checked on every read; keys are the second gate.
Immediate, permanent revocation — revoked links/subscriptions die at once; QR/RFID copies go dark.
Step-up authentication for high-risk actions (permanent links, high-sensitivity profiles, exposure changes).

Authentication security

Passkeys (WebAuthn/FIDO2) and OAuth only — no password fallback.
Multiple passkeys per account (list / rename / revoke); the last method can't be removed.
Optional TOTP 2FA and hardware security keys.
Sessions are DPoP sender-bound; a stolen bearer token is useless without the device key.
Recovery uses linked methods + a downloadable backup key — never a password-reset email bypass.

Transport, platform & operations

TLS everywhere, modern ciphers, HSTS; no plaintext transport.
Region-scoped storage (EU/US), GDPR-by-design.
Encrypted, durable backups retained in cold storage for disaster recovery.
Rate limiting / DoS protection per principal.
Supply-chain security: pinned deps, SBOM, signed builds, least-privilege CI.
Bounded blast radius by design; documented incident response.

Responsible disclosure

We're grateful to researchers who help keep VirtualID safe, and will not pursue legal action against good-faith research that follows this policy.

How to report

Email: security@virtualid.one
Encrypted: use our PGP key (fingerprint published in security.txt and here). Please encrypt sensitive reports.
Machine-readable policy: /.well-known/security.txt (RFC 9116).

What to include

A clear description and impact assessment, reproduction steps (PoC), affected endpoint/component and prerequisites, and your contact + whether you'd like public credit.

Our SLA

Acknowledge within 72 hours.
Triage assessment within 7 days.
Updates through remediation; coordinated disclosure timeline.
Public credit / hall of fame (and a bounty reward where applicable).

Safe harbor — please DO

Test only against your own accounts/data or a designated test environment.
Give us reasonable time to remediate before public disclosure.
Stop and report immediately if you access another user's data.

Please DON'T

Access/modify/delete other users' data; degrade service (no DoS/spam); run automated scanning that harms availability.
Use social engineering, physical attacks, or attacks on staff/vendors.
Disclose publicly before we've coordinated a fix.

Scope

In scope: *.virtualid.one web apps and the public API, encryption/key handling, authentication flows, share-link/subscription authorization, and privacy/exposure controls. Typically out of scope: missing best-practice headers with no demonstrated impact, volumetric DoS, automated-tool reports without a working PoC, and third-party services we don't control.

security.txt

Published at /.well-known/security.txt (RFC 9116), pointing here and listing the contact, PGP key, and policy URL.

Independent review

We intend to pursue independent third-party penetration testing and cryptographic review before handling real high-sensitivity identifiers, and to publish summaries.