ZKAuth security claims should be tied to implementation files, tests, formal-model scope, or a caveat. This page explains what evidence exists today and how to interpret it.
Boundary
Evidence is not the same as certification. ZKAuth does not claim a completed external audit, SOC 2, HIPAA, or full formal verification of deployed code.
Proof V2 local latency evidence
Three 30-login trials against the real local engine and disposable PostgreSQL 17 completed 90/90 measured logins. The median trial measured a 229.8 ms warm p50, 240.8 ms warm p95, and 590.1 ms cold login. A separate 30-login SDK mock-server diagnostic measured 154.2 ms p50 and 160.4 ms p95. These are loopback development measurements, not a hosted SLO or Neon/internet result. Two completion reruns on the current commits ranged from 691.3-707.0 ms warm p50 and 745.5-835.6 ms warm p95, with 1.87-1.88 s cold-process totals. That variance is why the faster baseline is evidence, not a latency guarantee.
Dashboard build evidence
The August 10 local migration retained Next.js 16.3, enabled stable Turbopack, and adopted the TypeScript 7 native compiler. A cold Turbopack build regressed to 46.5 s; the subsequent warm build completed in 8.32 s with approximately 2,745 MiB aggregate peak Node working set. Cache state differs from the 21.9 s Webpack comparison, so these are local workflow observations, not hosted or browser performance guarantees.
Current verification snapshot
This snapshot reflects the latest local verification pass, including Proof V2 and experimental Access Pass. It is useful release evidence, not a substitute for an external audit or live-provider certification.
Dashboard
Passed
Type-check, lint, and production build completed for the developer dashboard.
Engine
Passed
Format check, generated API docs currentness, and 772 engine tests passed; 23 environment-gated checks remain explicitly pending. The separately gated pinned disposable Keycloak 26.7.0 OIDC and SAML flows also passed and removed their shared container and volume.
SDK, demo, and CLI
Passed
The current SDK completed 59 default checks (52 passed and 7 explicit artifact-gated skips), its release-package gate, and all dedicated real Proof V2 and Access Pass integration paths. Version 2.0.0-beta.5 was published on August 18 and now resolves from both the npm latest and beta tags after exact-tag, registry-tarball, clean-install, and import checks. Publication does not change the experimental production boundary.
Policy checks
Passed
Public claims, hosted proxy/security/UI metadata, log hygiene, session security, SDK install checks, public paths, redirects, route metadata, and secret scanning completed.
Hosted acceptance
Partial
On August 15, a disposable production run passed 120/120 dashboard, engine-boundary, organization, federation-configuration, SCIM-token, webhook, billing-read, ownership, CSRF, and cleanup checks. Generated dashboard rows returned to zero and the deleted engine credential returned 401. A real-browser run passed 17/17 page/auth checks. Proof V2 login remained correctly production-gated pending independent review and a production ceremony, so no production ZK-login pass is claimed.
Evidence endpoints
Evidence
/security/evidence
Machine-readable evidence manifest for implemented claims.
Assurance
/security/assurance/policy
Assurance policy metadata for reviewer and operator inspection.
Crypto
/security/crypto-policy
Current cryptographic parameter reporting.
Standards
/security/standards
Standards-alignment map without certification claims.
Readiness
/security/pq-readiness
Crypto-agility and migration-readiness inventory.
Implemented claim map
Evidence ledger
Claims stay narrow unless implementation, tests, or caveats back them.
Proof pathExperimental local evidence
Ceremony-bound Groth16 Proof V2 login and QR pairing
Login and QR pairing are checked for tenant, account, purpose, policy, circuit, key, challenge, expiry, and exact pending-request binding with atomic one-time consumption.
+-Evidence details
Auth and pairing controllers, challenge service, V2 circuit, SDK vectors, browser flow, and PostgreSQL transaction boundaries are covered by tests.
Pairing consumes both its proof ceremony and pending request in one transaction, returns status-only polling data, and leaves MFA unverified for every outcome.
Redis and legacy proof hashes are defense in depth only; the V2 correctness boundary is the exact statement plus atomic PostgreSQL ceremony consumption.
Production remains disabled pending independent cryptographic review, a multi-party phase-2 ceremony, and signed artifact provenance.
Tenant isolationImplemented evidence
API-key tenant isolation
Project API keys are validated against the tenant they belong to before protected routes run.
+-Evidence details
Secure API-key middleware and service enforce project/client matching.
Tenant mismatch tests cover requests that present a valid key for the wrong project.
Machine authImplemented evidence
Project API-key lifecycle, limits, and opaque introspection
Project keys have lifecycle metadata, limits, and server-side opaque introspection.
+-Evidence details
Engine and dashboard evidence covers creation metadata, rotation, revocation, per-key limits, and quota tracking.
Opaque machine-token self-introspection is available for trusted server code.
This is not OAuth client credentials or JWT machine-token issuance.
User API keysImplemented evidence
Scoped end-user opaque API keys
End-user keys are scoped, project-bound opaque secrets with reveal-once handling.
+-Evidence details
Engine, dashboard, hosted helper, SDK, and tests cover reveal-once creation and HMAC-only storage.
Scopes, expiry, revocation, last-used metadata, and project-bound validation are covered.
These are not OAuth access tokens or full personal-access-token parity.
OrganizationsScoped helper
Preview B2B organization foundation
The organization surface supports preview B2B building blocks without claiming full enterprise identity parity.
+-Evidence details
Engine, generated API docs, and dashboard UI cover profiles, memberships, roles, invitations, teams, and verified domains.
Webhooks, audit events, and SCIM Users/Groups/Bulk attachment are included in the preview surface.
Certified enterprise SSO, certified directory sync, and per-seat billing are not shipped.
FederationScoped helper
Preview OAuth/OIDC and SCIM foundation
OAuth/OIDC and SCIM foundations exist as a preview, with conservative linking and explicit SAML non-claim language.
+-Evidence details
Provider configuration, encrypted provider secrets, OAuth state/nonce/PKCE, and OIDC discovery/JWKS refresh are covered.
A pinned disposable Keycloak 26.7.0 flow passes authorization code with S256 PKCE, state, nonce, ID-token/JWKS verification, and userinfo locally. This is not OpenID certification or hosted-provider evidence.
The same isolated lab returns a signed HTTP-POST SAML assertion that is checked for signature, issuer, audience, recipient, request correlation, time bounds, and email mapping.
Account linking is conservative; local sessions are created only for active trusted links.
SCIM evidence covers bearer-token lifecycle, Users/Groups provisioning, signed cursor pagination, and bounded Bulk writes.
Dashboard setup exists for provider configuration, OIDC refresh, and reveal-once SCIM token issuance.
The local SAML result is internal evidence only, not certification, hosted-provider compatibility, or production support; SAML is not public-launch enabled.
Credential-gated hosted-provider E2E harnesses exist, but broad provider compatibility evidence is not complete.
OPAQUEScoped helper
OPAQUE helper flow
OPAQUE helper routes exist for preview testing, but production setup still requires persistent server configuration.
+-Evidence details
Preview helper routes use DB-backed registration records.
Registration-before-login checks, tenant/user record binding, and single-use login-session tests are covered.
Production requires persistent OPAQUE server setup.
WebAuthnPreview / scoped
Policy-bound WebAuthn sign-in and hosted credential management
A verified assertion is followed by tenant/account, threat, device-approval, project-MFA, and session policy before the engine issues a token.
+-Evidence details
Unit coverage locks tenant binding, inactive-account denial, critical-threat rejection, device approval, MFA enrollment/challenge, and policy-derived session lifetime.
Virtual authenticator E2E covers registration and assertion verification; it is simulated interoperability, not physical-device evidence.
DB-backed single-use challenge tests and ceremony challenge mismatch rejection are covered.
Credential tenant/user ownership checks are included.
Authenticated users can list bounded passkey metadata and revoke one opaque credential identifier. Registration and revocation require a recent first-factor session, and the account API never returns credential IDs, public keys, or counters.
A disposable PostgreSQL 17 integration run covers safe-field listing, cross-tenant deletion denial, successful owner deletion, and the removal security event.
Revocation attempts a credential-free security notification after deletion. Unit coverage proves provider failure cannot restore or report failure for an already revoked passkey; live-provider delivery evidence remains separate.
Hosted foundationScoped helper
Project-bound hosted proxy
Hosted routes are project-bound helpers; the developer application still owns the final app session.
+-Evidence details
Hosted settings and proxy routes cover slug/client binding, callback and origin allowlists, and server-side key injection.
No-store responses, request-context checks, bounded result pages, and hosted sign-up/sign-in/recovery helpers are covered.
Hosted passkey helper, account-security helper controls, and single-use handoff-code redemption are included.
The developer app still owns its session cookie.
Public metadataDocumented boundary
Standards-aware metadata
Public security metadata exists with explicit non-claims instead of certification language.
+-Evidence details
Assurance, standards alignment, crypto policy, and post-quantum readiness endpoints exist.
The endpoints document boundaries and non-claims instead of implying certification.
Formal model scope
The formal model is intentionally scoped. Use this wording when describing it publicly:
text
We provide a focused symbolic Tamarin model for single-use authentication, device, and experimental anonymous-authorization ceremonies; issued-context requirements; and ceremony-to-privilege-transition binding. The model abstracts circuit arithmetic, Merkle and role semantics, and Groth16 soundness, and does not constitute full formal verification of the deployed implementation.
Executed formal evidence
On August 9, 2026, the official Tamarin 1.12.0 archive matched its pinned SHA-256 and ran with supported Maude 3.4 in a disposable read-only container. All eight current lemmas and all well-formedness checks passed. This verifies the symbolic model only.
Verified Tamarin lemmas
Single-use ceremonies
At-most-once acceptance for each modeled ceremony family.
The engine and SDK repositories contain the security-sensitive tests. Run focused checks after any auth, proof, replay, callback, session, or device change. Run each block from the matching repository root.
Proof and replay gates. Use these targeted checks before relying on any tenant-bound proof, freshness, or replay claim.
engine: proof and replaypowershell
npm exec -- mocha "tests/unit/zkpService.test.js" --require tests/setup.js --timeout 30000npm run test:integrationnpm run test:property
enginepowershell
npm run format:checknpm run lintnpm run testnpm run test:unitnpm run test:integrationnpm run test:property
sdkpowershell
npm run type-checknpm run lintnpm run buildnpm run testnpm run test:proof-v2:integrationnpm run test:access-pass:integration