Trust boundary
Limitations
ZKAuth is a privacy-first zero-knowledge password authentication layer. It is not yet a complete identity platform. This page is the public boundary for what the product does not claim today.
Positioning
Capability boundaries
The table below separates shipped capabilities from partial surfaces and roadmap work. It is meant to prevent accidental over-claiming.
OAuth and social login
OAuth/OIDC foundations exist, but broad provider coverage is not claimed.
+-Current boundary
Selected OAuth/OIDC federation foundations exist for provider setup, exact callback handling, state/nonce/PKCE, profile normalization, and conservative account-linking decisions. A pinned disposable Keycloak 26.7.0 flow passes locally. OpenID certification, broad hosted-provider coverage, and automatic-linking claims are not complete.
Enterprise identity
OIDC and SCIM preview surfaces exist; local SAML evidence exists, while public SAML and certified enterprise SSO remain deferred.
+-Current boundary
The engine has preview OAuth/OIDC federation foundations and organization-scoped SCIM Users, Groups, Bulk writes, and signed cursor pagination. Dashboard setup exists for provider configuration and SCIM token issuance. A pinned local Keycloak flow returns a signed SAML assertion that the engine checks against exact trusted context, but this is not certification, hosted-provider compatibility, public availability, or production support. Certified enterprise SSO, certified directory sync, and provider compatibility guarantees are not shipped.
Organizations and B2B
Organization, team, invitation, domain, and SCIM building blocks are preview-scoped.
+-Current boundary
A preview organization foundation exists for end-user B2B apps: profiles, memberships, roles, invitations, teams, verified domains, webhooks, audit events, and SCIM Users/Groups/Bulk attachment. SAML SSO, full enterprise SSO, certified directory sync, and per-seat billing are not shipped.
Hosted Account Portal
Hosted helper pages exist, but the developer app still owns the final session.
+-Current boundary
Hosted auth, recovery, passkey, callback, branding, email-copy, and account-security helper surfaces exist. They are project-bound and deliberately constrained. The developer application still redeems handoff codes from trusted server code and owns its own session cookie; this is not a complete Account Portal.
Hosted launch acceptance
Hosted validation has passed controlled generated-data runs, not broad production cleanup.
+-Current boundary
A disposable August 15 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 signup, authenticated dashboard, and account-deletion run passed 17/17 checks. Production Proof V2 login is still deliberately gated pending independent review and a production ceremony; live SCIM, OIDC, SMS, and physical-authenticator evidence remains provider- or hardware-gated. This does not authorize broad production data cleanup or make hosted account-management parity complete.
Framework coverage
Core web/server packages exist; mobile/native SDKs remain roadmap work.
+-Current boundary
Server-side Node helpers, Next.js App Router, React, Express, and Hono packages exist. Mobile/native SDKs and full framework automation remain roadmap work.
Machine authentication
Opaque project-key introspection exists; OAuth client credentials and JWT M2M are not shipped.
+-Current boundary
Project API keys can be introspected as opaque machine tokens from trusted server code with issuer/audience checks and audit events. OAuth client credentials, JWT machine-token issuance, and local JWT verification are not shipped.
User API keys
Scoped end-user opaque keys exist, but they are not OAuth access tokens.
+-Current boundary
Scoped end-user opaque API keys exist with scopes, expiry, revocation, last-used metadata, reveal-once secrets, and project-bound server-side validation. They are not OAuth access tokens, project API keys, or full personal-access-token parity.
ZK Access Pass
Anonymous authorization exists as a local experiment, not a production or hosted capability.
+-Current boundary
The local engine and published SDK beta can prove tenant Merkle membership and a hidden role threshold for an exact origin and action, then issue a short-lived identity-free capability. The credential issuer must control the enrolled role. Development-only proving artifacts, no independent review, no production ceremony, and no hosted deployment keep this experimental. The hosted proxy does not support Access Pass because it cannot preserve the relying application's exact Origin.
MFA
TOTP and backup-code enforcement exist; broader account-management parity is still partial.
+-Current boundary
TOTP and backup-code challenge enforcement exists, including project-required MFA and first-time hosted TOTP enrollment after first-factor proof verification. Broader account-management parity remains partial.
OPAQUE
Preview OPAQUE helper state exists; production server setup is not shipped.
+-Current boundary
Preview helper endpoints and DB-backed registration/login-session state exist. Hosted product UI and full migration automation are not shipped.
WebAuthn/passkeys
Preview passkey helpers exist with virtual-authenticator evidence, not broad passkey parity.
+-Current boundary
Preview helper endpoints, dashboard proxy routes, hosted policy-bound passkey sign-in for an already registered credential and known user ID, single-use application handoff, and recent-sign-in-guarded hosted-origin registration, safe metadata inventory, and revocation exist with virtual-authenticator and disposable PostgreSQL evidence. Revocation attempts a credential-free email without blocking deletion, but live-provider delivery is not claimed. Account discovery, passkey-only recovery, broad hardware/passkey compatibility, cross-origin passkey support, and complete account-portal parity are not claimed.
Billing
Self-serve Pro billing is early access, with a deliberately narrow live-evidence boundary.
+-Current boundary
Usage tracking, account-scoped plan records, hosted checkout and portal routes, signed webhook processing, entitlement snapshots, and production entitlement synchronization exist. One live INR checkout, entitlement activation, portal session, and immediate cancellation were verified. The provider rejected the refund before creation because the merchant wallet could not cover the gross refund; renewal recovery, disputes, refund success, retained production metering, and mature invoice operations are not yet evidenced broadly.
Compliance
No external compliance certification or completed external audit is claimed.
+-Current boundary
No SOC 2, HIPAA, GDPR certification package, or completed external audit is claimed.
What the ZK password flow proves
The main ZKAuth login path is designed to prove:
- The user can derive the expected password-based secret.
- The proof is bound to the project/tenant context.
- The proof is fresh and not a previously accepted replay.
- The engine can issue a session after verification succeeds.
What it does not prove
- It does not remove phishing, malware, or session theft risk.
- It does not make browser storage safe for secrets.
- It does not make a compromised tenant backend trustworthy.
- It does not provide post-quantum security.
- Access Pass does not prove legal identity, human presence, device integrity, network anonymity, or unlinkability within one relying origin.
- Access Pass is a bearer-capability experiment; it does not replace login, MFA, federation, recovery, or an application session.
- It does not replace certified enterprise SSO or complete directory provisioning.
- The current OAuth/OIDC and SCIM Users, Groups, Bulk, and cursor surface is a scoped preview, not certified enterprise identity parity.
- A pinned local Keycloak flow returns a signed SAML assertion that is checked against exact trusted context. This is internal evidence, not certification or production support; SAML is not public-launch enabled.
How to read ZKAuth claims
Public claims should map to implementation evidence or a caveat. Start with Security, Threat model, and Evidence before using ZKAuth in a production security boundary.
Federation boundary
OAuth, enterprise OIDC, and SCIM claims must stay preview-scoped and attached to the existing organization, verified-domain, callback-validation, audit, and single-use-token foundations.
- A controlled live OAuth/OIDC callback path has been validated for the manual-review branch.
- A pinned disposable Keycloak 26.7.0 flow passes locally. It is not OpenID certification or evidence for a hosted provider.
- Broad provider compatibility and automatic account-linking claims are not complete.
- Local signed-assertion evidence exists, but public and production SAML remain future enterprise work.
- Certified enterprise identity, provider-specific compatibility guarantees, and per-seat billing remain incomplete.
- ZKAuth should not be described as a complete enterprise identity suite.