Passkey Bundle Laravel Package

Product Decisions This Supports

• Passwordless roadmap sequencing. Adopting this package is a buy decision for the WebAuthn ceremony layer (registration/assertion, challenge handling, credential storage) rather than a build decision — it lets you put passkeys on the roadmap without allocating an engineering quarter to spec compliance and browser quirks. The remaining work is product work: where to surface enrollment, how to handle the "no passkey yet" state, and what recovery path exists.
• Feature scoping for step-up authentication. Because the package ships the ceremonies as drop-in UI, you can scope passkeys to a single high-value moment first (login for returning users, or step-up before a payout/credential change) instead of a full account-system migration — a cheap way to test demand before committing to a broader auth rework.
• Front-end architecture is not a blocker. v2.0.1 is the decision-relevant part: the passkey buttons previously bound listeners to the DOM nodes present at module evaluation, so on any page reached via a DOM-replacing navigation (Turbo, Livewire wire:navigate, and morphing equivalents) the module was already in the browser's module map and never re-evaluated — new buttons were bound to nothing. Clicks did nothing, with no error surfaced anywhere. A single delegated listener on document now resolves the clicked button and container. Practically: you do not need to schedule a JS refactor, add per-page re-initialization hooks, or exclude passkey pages from your SPA-style navigation to ship this. If your app is Hotwire/Livewire/Inertia with partial reloads, this is the release that makes the package safe to ship there.
• Upgrade cost is effectively zero. No configuration change; v2.0.0 → v2.0.1 is a composer update. It can ride along with routine maintenance rather than needing its own release slot, which makes "adopt now" cheaper than "adopt next quarter."
• Use cases worth evaluating against your funnel: passkey-first sign-in for returning users, phishing-resistant MFA for admin/back-office consoles, step-up auth on sensitive actions, and post-breach hardening of account recovery.

When to Consider This Package

Consider it when all of the following hold:

• You have a Laravel/PHP application and want passkey (WebAuthn/FIDO2) authentication without owning the ceremony implementation.
• Your front end is Blade, Livewire, or Inertia, and — importantly — you use DOM-replacing navigation (Turbo, wire:navigate, morphing/partial reloads). v2.0.1 is the version that makes this combination viable; on v2.0.0 this pattern produced silent, unreportable click failures.
• You want passkeys as an addition to an existing account system rather than a wholesale identity migration.
• You can absorb a patch-level dependency bump in normal maintenance.

Look elsewhere when:

• You are not on Laravel/PHP, or you need the same auth surface across multiple runtimes.
• You need a hosted identity provider with SSO, SCIM, org-level policy, and audit tooling — this is a ceremony/UI layer, not an IdP.
• You require advanced WebAuthn policy controls (attestation conveyance and trust policy, authenticator allow/deny lists, enterprise-managed credential lifecycle).
• You need first-party native mobile passkey flows; the delegated-listener fix is explicitly about browser DOM replacement, and native SDKs are a different integration.
• Your team has no appetite for owning the recovery/fallback UX — passkeys require a deliberate "lost device" product decision that no package makes for you.

Adoption caveat worth carrying into QA: the defect this release fixes failed silently — no console error, no thrown exception, just an inert button. That is the failure mode this whole class of integration is prone to. Whatever the release notes say, add an explicit smoke test to your own acceptance criteria: navigate to the passkey screen via your SPA-style route transition (not a hard reload), then click. A green integration here is not self-evident from the absence of errors.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk increment on our authentication roadmap that moves us toward phishing-resistant sign-in — the credential type that removes shared secrets from the login flow entirely — and reduces the password-reset load that drives a meaningful share of support tickets. We are buying the protocol-level implementation rather than building it, so the cost is integration and product design, not WebAuthn expertise. The v2.0.1 patch carries no configuration change and no migration: it is a routine dependency update. It also removes a real blocker — the previous version's passkey buttons failed silently on the navigation pattern our front end already uses, which would have looked like a mysterious "the button doesn't work" bug in production and cost us a debugging cycle to even diagnose. That specific risk is now closed, and it closed without asking anything of our front-end architecture.

For engineering: v2.0.1 replaces per-node listener binding with a single delegated listener on document that resolves the clicked button and its container, so the ceremonies survive whatever replaces the markup — Turbo, Livewire navigate, and morphing equivalents. The root cause was the module being cached in the browser's module map after first evaluation: subsequent navigations swapped the DOM, the module never re-ran, and the new buttons had no handlers. Fix is confined to the asset; upgrade is composer update with no config changes. Please still add a post-navigation click smoke test in our own harness — the original failure emitted no error, so our test coverage, not the package, is what will catch a regression of this shape.