Auth (Passkeys)

Overview

PVERSE uses a passkey-first authentication model because strong origin-bound authentication reduces phishing exposure, removes shared-secret storage risk, and raises the security baseline for account access. In a platform that includes sensitive account, payout, and operational surfaces, this matters more than treating authentication as a convenience feature alone.

At a public level, the model is simple: passkeys establish strong account access, ordinary session continuity remains bounded rather than absolute, and higher-risk actions may require fresh verification rather than relying only on an older signed-in state.

Scope

This page defines the public meaning of passkey-based authentication within the Infrastructure section.

• passkey-first account access principles
• bounded session continuity after strong authentication
• stronger verification for sensitive actions
• forward-only security integrity for authentication-related history

Core Model

The core model is strong authentication first, continuity second. Passkeys establish the trusted account-access posture, while sessions provide limited continuity rather than replacing strong verification forever. Sensitive actions are treated differently from ordinary navigation because account access and irreversible control should not share the exact same trust threshold.

• passkeys are the primary authentication method
• session continuity is useful but remains bounded
• sensitive actions may require recent stronger verification
• historical meaning should remain reconstructable through forward-only records

Operational Behavior

In normal operation, a user signs in or re-authenticates through a passkey-backed flow that establishes strong access to the account. Public documentation does not need to expose the exact ceremony sequencing or backend enforcement details to explain the user-facing meaning of this layer.

What matters publicly is that authentication remains stronger than ordinary session continuity, that important account-control actions are not treated casually, and that recovery or credential changes do not silently bypass the broader security posture of the account.

What this is

This layer is a public-facing summary of how PVERSE keeps authentication strong, origin-bound, and structurally conservative.

It is not a public API reference, not an implementation manual, and not a disclosure of internal auth sequencing or defensive enforcement logic.

Goals

• Strong account access: ordinary sign-in should begin from a phishing-resistant authentication posture.
• Reduced secret risk: the platform should avoid depending on reusable password-style shared secrets.
• Controlled sensitive actions: high-impact operations should not rely only on stale session continuity.
• Auditability: important authentication-related outcomes should remain historically readable.
• Forward-only integrity: authentication history should remain reconstructable through explicit later records.

Non-goals

• treating passkeys as wallet-signing keys or on-chain custody keys
• publishing private authentication flow detail, thresholds, or restricted fallback logic
• turning public docs into an authentication operations manual
• implying that ordinary session continuity is always equivalent to fresh strong verification

Core Concepts

Passkey-First Authentication

Passkey-first authentication means the account-access baseline is built on strong, origin-bound authentication rather than on ordinary reusable passwords.

Bounded Session Continuity

Bounded session continuity means a signed-in state provides limited continuity, but it does not automatically authorize every higher-risk action forever.

Step-Up Verification

Step-up verification means some sensitive actions require more recent or stronger confirmation than ordinary account browsing.

Forward-Only History

Forward-only history means authentication-related records should remain readable through explicit later outcomes rather than silent replacement of earlier meaning.

Public Principles

• Strong by default: account access should begin from a stronger authentication posture.
• Sensitive actions stay sensitive: irreversible or account-control actions may require stronger verification than routine use.
• Recovery does not weaken the model: restoration paths should return the account to a strong posture rather than become a permanent weaker alternative.
• Limited disclosure: public docs should explain boundaries and meaning without exposing attack leverage points.

Constraints

• PVERSE does not fully control browser support, device state, or third-party platform behavior around passkeys.
• Public summaries do not expose sensitive ceremony details, private enforcement thresholds, or restricted recovery procedures.
• Authentication implementations may evolve over time while preserving the same public principles.
• Some operational or security-sensitive logic must remain outside the public documentation layer.

Integrity Considerations

Authentication becomes an integrity issue when a platform cannot later explain how an account was allowed to act, whether stronger verification was required, or whether recovery weakened the account posture. PVERSE treats passkey-first access, bounded continuity, and forward-only records as the public answer to that problem.

• important account access should remain attributable
• historical meaning should remain reconstructable
• public explanation should not weaken authentication security through over-disclosure

Future Expansion

As the Infrastructure section grows, this page may expand with additional public explanation around strong authentication posture, session continuity boundaries, and verification principles for sensitive actions. Sensitive implementation detail and restricted operational mechanics should remain outside the public summary layer.

Summary

• PVERSE uses passkeys as the primary strong-authentication layer for account access.
• Sessions provide bounded continuity, but higher-risk actions may require stronger or more recent verification.
• Recovery and credential changes remain part of the same broader security posture.
• This page is intentionally compressed and excludes sensitive implementation detail.