Pick a stack the way you pick a deploy package: situation first, then face, then topology. Every stack uses the same publish → pin → challenge → prove → burn loop under the reference architecture.
Match your situation, open the stack, then book a live demo to walk it against your routes.
BYOI (Path B)
Situation
Users or partners publish their own public verifier and authenticate on your site.
Mechanism
Discover authenticator by HTTPS URL. Pin the sibling digest file, cache bytes, challenge, prove, burn nonce. Identity key derives from the digest.
Face: Web ceremony client or resource-server embed
Book a live demo →Org twin (Path A)
Situation
Organization-issued or demo authenticators identified by handle.
Mechanism
User enters a handle only. Relying party validates against an org-issued or embedded twin. Blob cache not required for the reference face.
Face: Web ceremony client
Book a live demo →Dual XOR login
Situation
Production login that offers org twin or BYOI without dangerous mixes.
Mechanism
Exactly one of handle or authenticator URL. Both or neither → reject. Prevents pairing a victim subject with an attacker-supplied authenticator URL.
Face: One login card; two operational modes
Book a live demo →Hosted login BFF
Situation
Teams want a deployable auth origin with ordinary HTTP challenge / prove / validate routes.
Mechanism
Same-origin APIs for health, challenge, and validate-proof. Downstream apps keep their session issuer after success.
Face: Serverless web + API
Book a live demo →Digest-cache progressive
Situation
Path B at serverless scale needs cold-start resilience.
Mechanism
Warm instance hits local temp cache; cold start hydrates from blob storage; first contact pulls origin, verifies digest, persists. Fail closed on mismatch at every boundary.
Face: Ops package beside Path B
Book a live demo →Resource-server embed
Situation
Headless API or ring clients need checks without adopting Pass+ as visible chrome.
Mechanism
Client posts validation entries to a validate endpoint; full interactive flows still use challenge / validate-proof.
Face: API / embed
Book a live demo →Sovereign / air-gapped
Situation
Execution and ledger must stay inside the customer boundary.
Mechanism
Enterprise or sovereign executor with digest-keyed local store; optional signed authority snapshot within stated staleness.
Face: Enterprise self-hosted topology
Book a live demo →Agent / workload
Situation
Automation must call APIs without static bearer tokens in environment files.
Mechanism
Agent responds to a fresh challenge with an automated proof against a pinned peer verifier. Rotation is digest rebinding with proof-gated controls.
Face: Agent / MPC
Book a live demo →Wallet proof-before-sign
Situation
Irreversible sign or spend must not equal an unlock timer.
Mechanism
Each high-value sign triggers a fresh challenge. Signing proceeds only after a successful proof against the pinned digest.
Face: Wallet / step-up
Book a live demo →Workforce + BYOI hybrid
Situation
Corporate twins and personal authenticators share one face.
Mechanism
Path A for org-issued twins; Path B for personal authenticators. Authorization maps which resources accept which subject class.
Face: Hybrid login
Book a live demo →Account linking after first BYOI
RoadmapSituation
First visit by URL; return visits by stable handle.
Mechanism
After first Path B success, store digest and URL under a handle. Return visits use handle; cache-first Path B pipeline remains underneath.
Face: Roadmap SKU
Book a live demo →