Passlock | Blog

Ensure your LLM coding agent uses the latest Passlock docs

Fri, 15 May 2026 00:00:00 GMT

Passlock now provides an AI agent skill for Codex, Claude Code, and other LLM coding agents.

The skill is a small SKILL.md file that tells an agent how to discover the current Passlock documentation, search the agent-friendly runbooks, and fetch only the pages that are relevant to the task.

If you use AI coding tools to add passkeys, one-time codes, or Passlock server flows, install the skill before asking the agent to write code. It gives the agent a reliable path to the latest docs instead of leaving it to guess from stale model knowledge.

See the full setup reference at passlock.dev/agents/agent-skill/.

Why we added an agent skill

Passlock’s public API is intentionally small, but passkey integration still has details that matter:

browser and server packages have different responsibilities
safe and unsafe entry points return errors differently
passkey registration and authentication require separate browser and server steps
REST API endpoints use tenancy-scoped URLs
API symbols and result types can change as the libraries evolve

Those details are exactly where an LLM can make plausible but incorrect assumptions.

The agent skill narrows that risk. It instructs the agent to start from Passlock’s public documentation, use the generated LLM indexes for search, and treat the hosted API reference as the source of truth for exact package symbols.

What the skill does

The skill teaches an agent a retrieval workflow:

start with https://passlock.dev/llms.txt for broad documentation discovery
search the generated LLM documentation index for topic-specific pages
use https://apidocs.passlock.dev/llms/ for symbol-level package reference
prefer runbook pages for integration flow and API docs for exact signatures
fetch only the relevant markdown pages after the search has narrowed the topic
cite public Passlock URLs when explaining the implementation

It does not give the agent private implementation details. It points the agent at the same public documentation you can read on the website.

Where to install it

Download the skill from the reference page and place it where your coding agent expects skills or project instructions.

For Codex project-level use:

.agents/skills/passlock-agent-docs/SKILL.md

For Codex user-level use:

~/.agents/skills/passlock-agent-docs/SKILL.md

For Claude Code project-level use:

.claude/skills/passlock-agent-docs/SKILL.md

For Claude Code user-level use:

~/.claude/skills/passlock-agent-docs/SKILL.md

Use a project-level install when the repository actively integrates Passlock. Use a user-level install when you want the skill available across many projects.

How to use it

After installing the skill, ask your agent to use it when working on Passlock code:

Use the Passlock agent docs skill to add passkey registration to this app.

Or make the retrieval target explicit:

Use the Passlock agent docs skill. Verify the current @passlock/browser API before changing this registration flow.

For server-side work, point the agent at the package boundary:

Use the Passlock agent docs skill and update this API route to exchange a Passlock code with @passlock/server.

Good prompts tell the agent which Passlock flow is being changed and require it to verify the current docs before editing code.

When it helps most

The skill is most useful when the agent needs to choose between similar Passlock concepts:

The default recommendation is to use the safe Passlock APIs unless your application already standardizes on thrown errors. The skill should guide the agent toward those safe examples for runbook-style implementation work.

Keep the agent honest

The skill improves retrieval, but it is still worth making your prompt specific. Ask the agent to:

verify the relevant Passlock docs before editing
prefer public runbooks for flow guidance
use the API reference for exact imports and type names
avoid inventing package APIs
run your project’s normal typecheck or build after changes

That combination gives the agent enough context to move quickly without treating generated code as authoritative.

Class based clients and tree-shakeable functions

Thu, 07 May 2026 00:00:00 GMT

New feature

Passlock now supports both class-based clients and standalone functions across the browser and server libraries.

Both styles are functionally equivalent. The difference is how you want to structure your integration:

use a Passlock class when you want to configure the client once
use standalone functions when you want tree-shakeable imports
use safe entry points when expected Passlock errors should return as typed result envelopes
use unsafe entry points when expected Passlock errors should throw and be handled with try / catch

For the full side-by-side reference, see Choose your code style.

Why we added both styles

Different teams want different integration shapes.

Some applications prefer a configured client object. That keeps tenancy and API configuration in one place, makes dependency injection straightforward, and reads naturally in service classes or route handlers.

Other applications care more about importing only the functions they use. That is especially useful in browser code, where a registration-only page should not have to pull in every other client method just because a class exists.

Passlock now supports both approaches directly, without forcing either code style on every project.

Class clients

Class clients are the simplest option when you call Passlock from several places that share the same config.

import { Passlock } from "@passlock/browser";

const passlock = new Passlock({ tenancyId: "myTenancyId" });

const result = await passlock.registerPasskey({
  username: "jdoe@example.com",
});

if (result.success) {
  console.log(result.value.code);
} else {
  console.log(result.error.message);
}

The same pattern works in server code:

import { Passlock } from "@passlock/server";

const passlock = new Passlock({
  tenancyId: "myTenancyId",
  apiKey: "myApiKey",
});

const result = await passlock.exchangeCode({ code });

if (result.success) {
  console.log(result.value.id);
}

The class methods supply the constructor config for every operation. That reduces repetition and keeps application-level setup separate from per-call data.

Standalone functions

Standalone functions are better when tree-shaking is important or when you prefer explicit call sites.

import { registerPasskey } from "@passlock/browser";

const result = await registerPasskey(
  { username: "jdoe@example.com" },
  { tenancyId: "myTenancyId" }
);

if (result.success) {
  console.log(result.value.code);
}

The function import gives bundlers a smaller surface to analyze. It also makes each operation’s config dependency visible at the call site.

Server functions follow the same shape:

import { exchangeCode } from "@passlock/server";

const result = await exchangeCode(
  { code },
  { tenancyId: "myTenancyId", apiKey: "myApiKey" }
);

if (result.success) {
  console.log(result.value.id);
}

Safe entry points

The default package entry points are safe:

import { Passlock, registerPasskey } from "@passlock/browser";
import { Passlock as ServerPasslock, exchangeCode } from "@passlock/server";

Safe functions and methods return a result envelope for expected Passlock errors. You branch on result.success or result.failure, and TypeScript narrows the success and error paths.

That shape is useful when errors are part of normal product flow: unsupported passkeys, duplicate credentials, invalid one-time codes, expired challenges, or failed verification.

import { isPasskeyUnsupportedError, registerPasskey } from "@passlock/browser";

const result = await registerPasskey(
  { username: "jdoe@example.com" },
  { tenancyId: "myTenancyId" }
);

if (result.failure && isPasskeyUnsupportedError(result.error)) {
  console.log("This device does not support passkeys");
}

Unexpected runtime failures can still throw. Safe entry points are about typed handling for expected Passlock outcomes.

Unsafe entry points

Unsafe entry points live under /unsafe:

import { Passlock, registerPasskey } from "@passlock/browser/unsafe";
import { Passlock as ServerPasslock, exchangeCode } from "@passlock/server/unsafe";

Unsafe functions and methods resolve with the success payload directly. Expected Passlock errors reject the promise, so you handle them with try / catch and narrow with the exported type guards.

import {
  isDuplicatePasskeyError,
  registerPasskey,
} from "@passlock/browser/unsafe";

try {
  const result = await registerPasskey(
    { username: "jdoe@example.com" },
    { tenancyId: "myTenancyId" }
  );

  console.log(result.code);
} catch (error) {
  if (isDuplicatePasskeyError(error)) {
    console.log("This passkey is already registered");
  }
}

This style is useful when the rest of your application already uses thrown errors and centralized exception handling.

Choosing a style

There is no special capability hidden behind one style. Pick the one that best fits the code you are writing.

Our default recommendation is simple: start with the safe Passlock class for application code, then move hot browser paths to standalone safe functions when bundle size matters. Use unsafe entry points when thrown errors fit your existing conventions better.

Why we launched Passlock as a cloud based toolkit

Mon, 27 Apr 2026 00:00:00 GMT

When we set out to build Passlock, we had a choice:

Should this be a self-hosted library developers run themselves, or a fully managed cloud platform?

On the surface, a library might seem simpler. Developers get full control, no external dependency, and everything runs in their own infrastructure. But after working deeply with WebAuthn—and seeing the real-world complexity behind passkeys—we made a deliberate decision:

Passlock would be cloud-first.

Here’s why.

Authentication is not a “feature”—it’s infrastructure

Authentication sits on the critical path of your application. If it breaks, users can’t log in. If it’s insecure, everything else is at risk.

Building on top of a library gives you primitives—but it also means:

Designing your own credential storage
Handling edge cases across browsers and devices
Managing security, replay protection, and abuse prevention
Maintaining and evolving the system over time

In practice, you’re not just “adding auth”—you’re building and operating an authentication service.

Passlock exists to take that off your plate.

Language and framework agnostic by design

One of our core goals was to avoid locking developers into a specific stack.

While we provide a JavaScript server library, it’s intentionally thin - just a wrapper around our REST API.

That means Passlock works with:

JavaScript / TypeScript (Node, Bun, Deno, edge runtimes)
Python, Java, Go
Or any backend capable of making HTTP requests

By running as a cloud service, we can offer a consistent, language-agnostic interface instead of maintaining multiple deeply integrated SDKs across ecosystems.

Avoiding deployment complexity (for everyone)

If Passlock were self-hosted, we wouldn’t just be shipping code—we’d be shipping infrastructure.

That would mean supporting combinations like:

Docker vs native installs
Kubernetes vs simple VM deployments
Serverless environments
Multiple database backends (Postgres, MySQL, MongoDB, etc.)

Each combination introduces:

Different failure modes
Different performance characteristics
Different operational challenges

By running Passlock as a cloud platform, we eliminate that entire class of complexity—for both you and us.

Faster iteration in a fast-moving space

WebAuthn and passkeys are still evolving.

Browsers are changing behaviour. New capabilities are being introduced. Edge cases are constantly being discovered.

At the same time, we have an aggressive roadmap for Passlock itself.

If we shipped a self-hosted product, we’d need to:

Support multiple versions “in the wild”
Maintain backward compatibility across deployments
Slow down changes to avoid breaking existing installations

By running in the cloud, we can:

Ship improvements immediately
Fix issues once, for everyone
Continuously refine behaviour as the ecosystem evolves

This lets us move much faster than a traditional self-hosted model allows.

Seamless data migrations

Authentication data isn’t static.

As new features are introduced—or as the WebAuthn spec evolves—data structures may need to change.

In a self-hosted world, that means:

Writing migration scripts
Coordinating deployments
Risking inconsistencies across environments

With Passlock in the cloud:

We handle migrations centrally
Changes are applied safely and consistently
Everything is transparent to you

You don’t need to think about schema changes—we take care of it.

Instant security patching

Security issues don’t wait for release cycles.

In a self-hosted model:

A vulnerability is discovered
A patch is released
You need to upgrade
You need to deploy
You need to verify everything still works

That gap—between patch release and deployment—is where risk lives.

With Passlock:

We patch vulnerabilities immediately
Fixes are applied globally
No action is required from you

Your application benefits from the latest security improvements automatically.

Reducing the hidden cost of WebAuthn

WebAuthn is powerful—but it’s not trivial.

Behind the scenes, there are complexities around:

Browser inconsistencies (especially Safari)
Credential lifecycle management
Cross-origin and RP ID behaviour
Device-specific quirks

These aren’t things you solve once. They’re things you continuously maintain.

Passlock centralises that effort, so every improvement benefits every developer using the platform.

The trade-off: control vs velocity

Choosing a cloud platform is ultimately a trade-off.

With Passlock, you’re choosing:

Faster development
Less operational overhead
Continuous improvements
Centralised security and reliability

In exchange for:

Relying on an external service
Less direct control over the underlying system

For most teams, especially those where authentication isn’t the core product, that’s the right trade.

Our philosophy

We don’t see Passlock as just an API.

We see it as authentication infrastructure, delivered as a service.

You focus on building your product.
We handle the complexity of passkeys, WebAuthn, and everything that comes with them.

If you’re building with passkeys and want to move fast without owning the entire auth stack, Passlock is designed for you.

Migrating passkeys to a new domain

Thu, 16 Apr 2026 00:00:00 GMT

Changing domains is usually when developers realise their user’s passkeys only work on the existing domain 💥

A passkey created for oldsite.com is not automatically available on newsite.com. That domain binding is part of what makes passkeys resistant to phishing, but it also means a rebrand, acquisition, or infrastructure move can break sign-in if you treat passkeys like portable usernames and passwords.

Related origin requests are the standards-based answer. They let newsite.com ask the browser for a passkey that was originally created for oldsite.com, but only if oldsite.com explicitly trusts the new origin.

Why domain migration gets awkward quickly

The browser piece is only part of the problem. A real migration usually forces you to answer several application-level questions:

Should you keep issuing passkeys against oldsite.com, or switch new registrations to newsite.com?
How will oldsite.com publish a valid /.well-known/webauthn file over HTTPS?
How will you decide whether a given login attempt should request oldsite.com or newsite.com?
How will you track which users still have legacy passkeys?
When a user finally registers a new-domain passkey, how will you retire the old one?

That is where developers usually end up writing migration-specific authentication logic.

What the raw standards require

The core WebAuthn rule is simple: the source domain must explicitly trust the calling origin.

If you want newsite.com to authenticate passkeys that were created for oldsite.com, then oldsite.com needs to host this file:

https://oldsite.com/.well-known/webauthn

{
  "origins": [
    "https://oldsite.com",
    "https://newsite.com"
  ]
}

That solves only the browser permission check.

You still need to choose a migration strategy. The two main options are covered in our docs guide to Related origin requests:

Keep using oldsite.com as the rpID indefinitely, even from newsite.com.
Switch the tenancy to newsite.com for all new registrations, while continuing to accept legacy oldsite.com passkeys during the transition.

In practice the second option is usually what people mean by a domain migration.

Where Passlock takes care of the complexity

Passlock already documents the low-level rules in Migrating passkeys to a new domain. What Passlock adds is the application plumbing around those rules.

1. Configure the new steady state in the Passlock console

Once you are ready to start issuing passkeys for the new domain, update the tenancy so the primary rpID is newsite.com and oldsite.com remains available as a related origin:

New registrations now use the new domain, while legacy passkeys can still be accepted.

After that, your normal Passlock registration flow continues to work. New passkeys are created against the tenancy’s current rpID, so you do not need a separate migration-specific registration path.

2. Ask for the legacy rpID only when you need it

The awkward part of migration is authentication, not registration.

A browser cannot present passkeys from oldsite.com and newsite.com in one combined request. Your application has to decide which rpID to ask for.

Passlock exposes that decision as a simple override on the normal browser helper:

import { authenticatePasskey } from "@passlock/browser";

await authenticatePasskey({
  rpId: "oldsite.com",
}, { tenancyId: "myTenancyId" });

That is the main benefit during migration. You do not need to hand-roll WebAuthn option endpoints or custom browser ceremony code for the legacy case. You keep using authenticatePasskey(), and only switch the rpID when your flow determines the user is still on the old domain.

3. Use Passlock’s credential metadata to drive the migration

The hardest operational part is usually knowing which passkeys are still legacy credentials.

Passlock keeps the underlying WebAuthn credential mapping, including the credential’s rpId, available through its APIs. The Get passkey response includes credential.rpId, which lets your backend reason about whether a passkey belongs to oldsite.com or newsite.com.

import { getPasskey } from "@passlock/server/unsafe";

const passkey = await getPasskey({
  passkeyId: "myPasskeyId",
}, { tenancyId: "myTenancyId", apiKey: "myApiKey" });

if (passkey.credential.rpId === "oldsite.com") {
  // Offer the legacy login path or prompt for a replacement passkey
}

That same metadata is also what Passlock uses for device-side maintenance operations such as updating or deleting passkeys. You do not need to manually preserve raw WebAuthn identifiers just to make the migration workable later.

4. Replace and retire old passkeys with the same library surface

Once a user has authenticated with a legacy passkey, the migration path becomes straightforward:

Let them complete sign-in using authenticatePasskey({ rpId: "oldsite.com" }, { tenancyId }).
Prompt them to register a fresh passkey on newsite.com.
Delete the old passkey from your vault and, where supported, from the local device.

Passlock already has docs and helpers for the cleanup step, including backend and device passkey deletion. That means the migration does not stop at “the user managed to sign in once”; you can actually move them onto the new domain and retire the legacy credential.

A practical migration flow

If you are migrating from oldsite.com to newsite.com, the typical Passlock flow looks like this:

Update your Passlock tenancy so new registrations use newsite.com.
Add newsite.com to https://oldsite.com/.well-known/webauthn.
Keep standard registration on the new domain for all new or replacement passkeys.
Use a two-step authentication flow or a dedicated “Sign in with your old domain passkey” action when a user may still be carrying an oldsite.com credential.
After a successful legacy login, register a replacement passkey on newsite.com.
Retire the old passkey once the new one is confirmed.

That leaves each piece of complexity in the right place:

The standards details live in the Related origin requests guide.
The application helpers live in @passlock/browser and @passlock/server.
The credential metadata needed for migration stays available through Passlock’s REST API and server helpers.

Introducing mailbox challenges

Wed, 08 Apr 2026 00:00:00 GMT

New feature Passlock now supports mailbox challenges, a server-side feature for building email one-time code flows without rebuilding the awkward security and lifecycle pieces yourself.

This is aimed at the cases teams keep needing even when passkeys are the long-term goal:

verifying email ownership during signup
passwordless login when passkeys are not available
confirming a new email address before updating an account

What a mailbox challenge is

A mailbox challenge is an email verification flow with a little more structure than “generate a six-digit code and hope for the best”.

When you create a challenge, Passlock returns:

challengeId to identify the challenge
secret for your app to keep server-side
code for you to deliver by email
message.html and message.text if you want ready-made email content

The user receives the code, enters it into your app, and your backend verifies the attempt using all three parts: challengeId, secret, and code.

That detail matters. The emailed code alone is not enough.

Why we built it

Email one-time codes look simple until you try to ship them properly.

You need challenge expiry, retry handling, invalidation of older outstanding codes, rate limiting, consistent verification, and a way to reduce the risk of treating an intercepted code as sufficient proof on its own.

Mailbox challenges package those moving parts into a small API so you can focus on your product flow instead of rebuilding verification plumbing.

Typical flow

The flow is straightforward:

Your backend creates a mailbox challenge for a purpose like signup, login, or email-change.
Your app stores challengeId and secret in a server-side session or HTTP-only cookie.
Your mailer sends the code to the user, using Passlock’s rendered message or your own template.
The user submits the code.
Your backend verifies the challenge and checks the returned purpose, email, and any expected local user context before completing the action.

If you need to restore an in-progress flow, you can also read a challenge without exposing the secret or code.

Using @passlock/server

If you are already using the Passlock server library, the basic shape looks like this:

import {
  createMailboxChallenge,
  verifyMailboxChallenge,
} from "@passlock/server/unsafe";

const created = await createMailboxChallenge({
  email: "jdoe@example.com",
  purpose: "login",
  invalidateOthers: true,
}, { tenancyId: "myTenancyId", apiKey: "myApiKey" });

await savePendingLoginSession({
  challengeId: created.challenge.challengeId,
  secret: created.challenge.secret,
});

await sendEmail({
  to: created.challenge.email,
  html: created.challenge.message.html,
  text: created.challenge.message.text,
});

const pending = await readPendingLoginSession();

const verified = await verifyMailboxChallenge({
  challengeId: pending.challengeId,
  secret: pending.secret,
  code: form.code,
}, { tenancyId: "myTenancyId", apiKey: "myApiKey" });

if (verified.challenge.purpose !== "login") {
  throw new Error("Unexpected challenge purpose");
}

await completeLoginForEmail(verified.challenge.email);

The same feature is also available over raw HTTP if you are not using the JS/TS server library.

Why Passlock does not send the email for you

Passlock creates the challenge and renders the message content, but the email still comes from your system.

That is deliberate:

the email should come from your domain
you keep control over deliverability and branding
you can either send the rendered HTML/text directly or generate your own template from the raw code

Where mailbox challenges fit

Mailbox challenges are not a replacement for passkeys. They cover a different part of the authentication surface.

Passkeys remain the stronger default for ongoing authentication. Mailbox challenges are useful when you need to prove mailbox ownership, offer a passwordless fallback, or verify account changes that are naturally email-centric.

In practice, many applications will use both:

passkeys for primary authentication
mailbox challenges for onboarding, recovery, or account-change verification

Updating passkeys on user devices

Fri, 20 Mar 2026 00:00:00 GMT

WebAuthn Level 3 adds PublicKeyCredential.signalCurrentUserDetails(), a small but useful API for keeping the passkey names shown on a user’s device aligned with the account details they use today.

This is not about changing authentication identifiers. It is about updating the local label a user sees in their password manager after a typo is fixed or an account username or email address changes.

What signalCurrentUserDetails() does

signalCurrentUserDetails() tells the browser or password manager to update the local metadata associated with a passkey.

In practice that means you can change the name a user sees in places like Apple Passwords, Google Password Manager, or browser-managed passkey UI without re-registering the credential.

Becomes…

It is important to keep the scope clear:

It updates local display metadata on the device.
It does not change the credential ID.
It does not change the WebAuthn user.id.
It does not change your backend account identifier.

Why passkey names need to change

Passkeys often outlive the account data they were created with.

Someone might register a passkey with jonh@example.com, then later fix the typo to john@example.com. Someone else might rename an account from a personal email address to a work email address. In both cases the passkey can continue to authenticate correctly, but the label shown in the password manager is now stale.

That stale label creates needless confusion:

the user sees the wrong email address when choosing a passkey
support teams have to reason about old and new names
the device appears out of sync with the account even though authentication still works

signalCurrentUserDetails() fixes that gap. It lets you align the device-local passkey name with the current account username and display name.

Using the raw WebAuthn API in browser JavaScript

The raw API is client-side only. You should first check for support, then pass the relying party ID, the credential’s WebAuthn userId, and the new names:

const credential = {
  rpId: "example.com",
  // Base64URL encoded credential userId (binary)
  userId: "MTVkMTFmdHM1Yzg0bDN0anpieG9w",
};

const updates = {
  name: "john@example.com",
  displayName: "John Example",
};

if (typeof PublicKeyCredential?.signalCurrentUserDetails === "function") {
  await PublicKeyCredential.signalCurrentUserDetails({
    ...credential,
    ...updates,
  });

  console.log("Local passkey details updated");
} else {
  console.log("This browser does not support signalCurrentUserDetails()");
}

Two details matter here:

name is the username-like label shown for the passkey.
userId is the credential’s WebAuthn user ID, not your own arbitrary application user ID.

That rpId and userId data usually comes from passkey metadata you already store on the backend. If you are using Passlock, this is exposed through the credential mapping described in the credential property docs.

Because browser support is still evolving, always feature-detect the API and fall back to telling the user how to update or recreate the passkey manually when the signal is unavailable.

Using the @passlock/browser library

If you are already using Passlock, the easier route is updatePasskey() from the @passlock/browser library.

import { updatePasskey } from "@passlock/browser";

await updatePasskey({
  passkeyId: "myPasskeyId",
  username: "john@example.com",
  displayName: "John Example",
}, { tenancyId: "myTenancyId" });

Passlock handles the lookup for the underlying credential mapping, then signals the browser with the right rpId and credential userId.

Under the hood, the browser library maps:

username to WebAuthn name
displayName to WebAuthn displayName

If you omit displayName, Passlock defaults it to the new username, which is often exactly what you want for email-based accounts.

This helper only updates the local device copy of the passkey. If the user has actually changed their username or email address in your system, you should still update that server-side state separately. For Passlock vault data, see Update passkey.

Keep the server and the device in sync

The most reliable flow looks like this:

Update the user’s account data in your own backend.
Update any server-side passkey metadata you keep.
Call signalCurrentUserDetails() or Passlock’s updatePasskey() in the browser to refresh the device-local label.

That gives you the best of both worlds: the server stays authoritative, and the user sees the right passkey name on their device.

Passlock | Blog

Ensure your LLM coding agent uses the latest Passlock docs

Why we added an agent skill

What the skill does

Where to install it

How to use it

When it helps most

Keep the agent honest

Further reading

Class based clients and tree-shakeable functions

Why we added both styles

Class clients

Standalone functions

Safe entry points

Unsafe entry points

Choosing a style

Further reading

Why we launched Passlock as a cloud based toolkit

Authentication is not a “feature”—it’s infrastructure

Language and framework agnostic by design

Avoiding deployment complexity (for everyone)

Faster iteration in a fast-moving space

Seamless data migrations

Instant security patching

Reducing the hidden cost of WebAuthn

The trade-off: control vs velocity

Our philosophy

Migrating passkeys to a new domain

Why domain migration gets awkward quickly

What the raw standards require

Where Passlock takes care of the complexity

1. Configure the new steady state in the Passlock console

2. Ask for the legacy rpID only when you need it

3. Use Passlock’s credential metadata to drive the migration

4. Replace and retire old passkeys with the same library surface

A practical migration flow

Further reading

Introducing mailbox challenges

What a mailbox challenge is

Why we built it

Typical flow

Using @passlock/server

Why Passlock does not send the email for you

Where mailbox challenges fit

Further reading

Updating passkeys on user devices

What signalCurrentUserDetails() does

Why passkey names need to change

Using the raw WebAuthn API in browser JavaScript

Using the @passlock/browser library

Keep the server and the device in sync

Further reading