Browser session establishment (ADR 0007): the shared session cookie, the one-time login-challenge machinery, and every ceremony that resolves a posted proof into a [polyc_crypto::session] token — the persona-rooted passkey ceremony ([passkey_login]) and the wallet-passkey ceremony ([wallet_login]).

Why this is its own crate, not polyc-control-plane modules

Nothing here names the consumer. A session minted by either ceremony is a plain [polyc_crypto::session::SessionSubject] — Persona or Wallet — with independent [polyc_crypto::session::SessionScope]s; neither this crate nor polyc_crypto::session carries any "explorer"-specific naming. polyc-control-plane is the only container that serves browser sessions today, so this crate stays a component it composes, not a second container of its own — but the naming boundary (mechanism, not consumer) holds regardless of how many containers end up depending on it.

What is NOT here

Everything in this crate is web-shaped: a WebAuthn rp_id and origin to check, a Set-Cookie to write, a posted proof to verify. What happens to a session AFTER it is minted — the durable family, its rotating grant, reuse detection, expiry — is not, and lives in polyc-session-family, which this crate depends on. That crate is a foundation and knows nothing about browsers; this one cannot be, because resolving a persona's scopes needs polyc-persona. Both ceremonies create a family and bearer through polyc_session_family::authority::BrowserSessionAuthority and root it with a polyc_session_family::ScopeRoot.

Two ceremonies, one shared half

[passkey_login::PasskeyLoginSessions] and [wallet_login::WalletLoginSessions] differ only in HOW a posted proof resolves to a session subject — a persona's enrolled PersonaCredential record vs. a wallet's stateless, onchain-derived public key. Everything else — minting/redeeming a one-time challenge and the session cookie's shape — is identical, and lives once, here: [LoginChallengeRegistry] (the passkey ceremony builds directly on it) and the cookie module (both ceremonies' HTTP-facing callers share it). [wallet_login] does NOT build on [LoginChallengeRegistry], because it has no WebAuthn rp_id/origin to check at all — see that module's doc for why, and the registry module's doc for the one-time-token primitive both ceremonies' challenge minting is still built on underneath.