From 9534adf8204ddd1b70afa98ecd5e0cc4027288db Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Tue, 4 Aug 2026 15:12:34 -0400 Subject: [PATCH] PK6: record concrete PRF provider support, including KeePassXC's absence Replaces the vague 'modern authenticator stack' line with an observed snapshot table: Google Password Manager, iCloud Keychain, Bitwarden, and hmac-secret hardware keys work; KeePassXC 2.7.12 does not (it manages passkeys and ships credProps, but no prf/hmac-secret -- verified by binary inspection, and PRF must be evaluated inside the authenticator, so its browser extension cannot supply it); de-Googled Android is unreliable and better served by the NIP-46 rail. States plainly that uneven support is the method's real limitation, that only the ceremony is authoritative, and that a deployment must never make a passkey the only route to an account. Co-Authored-By: Claude Fable 5 --- docs/passkey-login.md | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/docs/passkey-login.md b/docs/passkey-login.md index 6c6b613..f38b58d 100644 --- a/docs/passkey-login.md +++ b/docs/passkey-login.md @@ -100,9 +100,29 @@ account at setup. # PK6. Support boundaries -PRF requires a modern authenticator stack (Chrome/Android and Google -Password Manager, recent Safari/iOS, hardware keys with hmac-secret). -Support cannot be feature-detected without running a ceremony, so an -unsupported combination surfaces as an honest in-flow message pointing at -the other methods. The password path remains the universal fallback — and -the primary method, per the standing password-first decision (§LM9.1). +PRF requires a modern authenticator stack, and support is **genuinely +uneven across password managers today** — this is the method's real +limitation, not a rounding error. Support cannot be feature-detected +without running a ceremony (the widget asks for `prf` in the ceremony and +inspects the result), so an unsupported combination surfaces as an honest +in-flow message pointing at the other methods rather than a mystery +failure or a half-created account. The password path remains the universal +fallback — and the primary method, per the standing password-first +decision (§LM9.1). + +Known provider status, as observed 2026-08-04. Treat as a snapshot: this +landscape moves, and only the ceremony is authoritative. + +| Provider | PRF | Notes | +| --- | --- | --- | +| Chrome / Android + Google Password Manager | Yes | The mainstream path; passkeys sync with the platform account. | +| Safari / iOS + iCloud Keychain (recent versions) | Yes | Same shape on Apple platforms. | +| Bitwarden browser extension | Yes | Uses PRF itself for passkey vault unlock; open source, self-hostable via Vaultwarden — the practical choice on Linux desktops. | +| Hardware keys with hmac-secret (YubiKey 5, Nitrokey 3, SoloKeys v2) | Yes | PRF rides on CTAP2 hmac-secret. | +| KeePassXC 2.7.12 | **No** | Stores and manages passkeys (`credProps` present) but ships no `prf`/`hmac-secret` support — verified by binary inspection on 2.7.12, and PRF evaluation must happen inside the authenticator, so the browser extension cannot supply it. Users see the unsupported message. | +| de-Googled Android (/e/OS, GrapheneOS without Play Services) | Not reliably | Browser ceremonies typically route through Play Services' FIDO2 API; third-party credential-provider coverage is still patchy. Such users are well served by the NIP-46 remote-signer rail instead (§LM5), which needs no platform account at all. | + +For a deployment, the practical reading: offer passkeys, expect a +meaningful minority to fall back, and never make the passkey the only +route to an account — which the graduation ladder (§PK4) already +guarantees.