Ceremony-bound password proofs and Access Pass research
Proof V2 binds authentication to one short-lived request, while Access Pass explores identity-hidden membership and role-threshold authorization.
Mohith / 6 min read- Status
- Experimental
- Package
- Unpublished checkout
- Production gate
- Independent review and ceremony
What changed
The experimental password-proof flow now creates a short-lived ceremony before proving. The proof statement binds the request context and the engine consumes the ceremony atomically so a valid proof cannot be replayed for another request.
Access Pass is a separate experiment that proves current tenant membership and a hidden issuer-assigned role threshold for one exact origin and action.
How the ceremony binds the request
Trusted server context determines the expected tenant, account, purpose, policy, circuit, key, challenge, ceremony, and expiry values. The client proves against those exact values, and the engine consumes the ceremony atomically when it accepts the request.
A proof for another tenant, purpose, challenge, version, or expiry does not satisfy the same statement. A consumed or expired ceremony cannot be reused as a fresh request.
What Access Pass explores
Access Pass is a separate research path for proving current tenant membership and a hidden issuer-assigned role threshold for one exact origin and action. It does not return identity fields and it is not a replacement for application authorization policy.
Production boundary
The work exists in the engine research path and the unpublished zkauth-client@2.0.0-beta.1 checkout. No package was published.
Production promotion remains blocked on independent cryptographic review, a multi-party phase-2 ceremony, signed artifact provenance, and rollout evidence. Passkeys remain the recommended production primary factor.
Experimental production status