You sign in with a discoverable passkey or an email address, and the account carries no password. Every non-public call is authorized against a principal-scoped passkey session and mints a one-use capability bound to the operation, the request body, the destination, the principal, the tenant, the session, the trace and a nonce. Moving money or changing security settings needs a fresh ceremony over the digest of that exact request, so a confirmation cannot be replayed elsewhere.

What it does

A Paxeer X account is held by passkeys rather than a password. Every non-public operation on the authenticated plane is authorized against a durable principal-scoped passkey session and yields a one-use execution capability bound to the operation, the canonical body disclosure, the destination, the principal, the agent tenant, the session, the trace, a random nonce and its issue time. Operations that move money or change security settings additionally require a fresh passkey ceremony bound to an OperationDigest that names that exact request, so a confirmation cannot be replayed against a different payment. The browser never holds signing power: the application identity a passkey opens, the protocol identity underneath it and the wallet a person links for money in and out are three separate things.

Key capabilities

• Sign in with a discoverable passkey, or with an email address; the account has no password.
• Session inventory lists every device holding access with its last activity; revoke one session or all.
• Each authorized call mints a one-use capability bound to operation, body, destination, principal, tenant, session, trace and nonce.
• Step-up issues a fresh ceremony confirming exactly one operation digest, and evidence for another operation is refused.
• The service derives every operation digest for security changes and wallet replacement; the browser never invents one.
• Nine authorization classes cover non-public operations; unclassified, mismatched, expired or replayed requests refuse closed.

Differentiators

Step-up evidence is bound to a digest the service derives from the authenticated principal and the exact canonical request, including its idempotency key for operations that carry one, and the evidence is persisted under that principal, so copying it to another principal or altering its digest authorizes nothing. Execution capabilities have a maximum age of sixty seconds, enforced both at the authorization call and at startup, where a configured capability TTL outside 1-60 seconds stops the service. A completed passkey assertion opens exactly one session before it expires and is then spent. Authenticator verification and verified recovery-receipt disclosure cross a versioned binary Unix-socket boundary to a separate security provider with no local fallback, so when that provider is unreachable those operations refuse rather than degrade.

Outcomes

• Confirm one named request, never a general approval
• See every device with access and end a session
• Refuse closed on mismatched, expired or replayed requests

Technical notes

• passkey-auth is pinned at =0.1.3. The WebAuthn verifier is built with user verification required, a user handle required and strict base64url.
• Ceremony, assertion, session, refresh and step-up lifetimes come from required environment values with no defaults; the service refuses to start unless the ceremony TTL is 1-300 seconds, the step-up TTL does not exceed the ceremony TTL, and the refresh TTL is at least the session TTL.
• A per-principal rate limit is applied independently to registration, assertion, fallback and step-up attempts, and returns a retry-after interval.
• Passkey ceremonies and credentials travel as opaque base64url strings; this plane relays them without interpreting them, and they never carry key material it can use.
• Removal of the final passkey is refused. Opening a session on a new device records the device and sends a security notification. Device metadata is optional on the additive wire contract, but the service fails closed when an opening request omits it.
• Every identity operation ships golden request, response and failure vectors under human/schema/human-api/golden/; the conformance suite fails when an operation lacks them or a vector departs from the declared shapes.
• platform/hosted/identity is a separate mutual-TLS principal, session and introspection service. It performs no passkey ceremony, caps session lifetime at 30 days, and mints a 16-byte session identifier with a 32-byte session secret and a 32-byte CSRF token.

More in Interface