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. Broad social-login coverage, provider-specific certification, and automatic-linking claims are not complete.
Enterprise identity
OIDC and SCIM preview surfaces exist; SAML and certified enterprise SSO are 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. SAML is planned for a later enterprise release and is not public-launch enabled. 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
Non-destructive hosted preflights and an explicitly approved generated-data full-platform validation run have passed against separated dashboard and engine targets. This does not authorize broad production data cleanup and does not 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.
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, a hosted passkey verification helper for already registered credentials, and hosted-origin passkey registration from the memory-only account security helper exist with virtual-authenticator evidence. Broad hardware/passkey compatibility, cross-origin passkey support, and full passkey account management are not claimed.
Billing
Billing records and provider hooks exist, but paid self-serve launch is deferred.
+-Current boundary
Usage tracking, account-scoped plan records, checkout/portal routes, entitlement snapshots, and billing-provider webhook verification exist. Live card/provider/product/tax activation, paid self-serve checkout, production entitlement enforcement, and mature invoice operations are not launched.
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.
- 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.
- SAML is deferred to a later enterprise release and 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.
- Broad provider compatibility and automatic account-linking claims are not complete.
- SAML remains 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.