Firefox 157 virtual passkey diagnostics, 2026-10-10

These finite diagnostics used the exact UI09 candidate: Debian SHA-256 7047c67defdcbee29b5ba9372debc8906bf8b8af65ef577275a27aabc4bc7c74, packaged console assets from console-live-build-09, Firefox 157.0 and geckodriver 0.37.1. Their private frozen harnesses and complete commands remain in each browser receipt. All executions used python3 -B tools/resource_group.py -- taskset -c 2,3 python3 -B HARNESS ..., verified a 4,000,000,000-byte/no-swap outer bound, and retained logs and screenshots after removing owned fixtures and process groups. They overlapped R2 worker cores 2–3; the measured R2 server remained on cores 0–1. They do not fill standalone browser acceptance.

The first discriminator disabled the fixture USB backend while keeping the software manager enabled, with actual preference readback. Protected owner registration and two passkey enrollments succeeded; a later fresh login failed. Receipt results/console-live-firefox-usb-selection-04/browser.json, unit c259647cbead4689b6533d394f75a9be: exit 1, 43.672 seconds, 874.1 MiB peak, no swap, cleanup confirmed. Earlier USB-enabled 60-second registration failures remain failed. The pinned Firefox dispatch chooses USB before its software manager, which explains why the virtual token was previously unused.

The observation-only retry preserved CTAP 2.0, required UV and the same corrected transport selection. Its failed fresh-login request contained two public credential IDs, no transport hints and RP localhost. The active virtual store contained exactly one matching ID under that RP; its signature counter was 2. Receipt results/console-live-firefox-allowlist-05/browser.json, unit f2f2fd6c770b457bbc10b8f3beb9e66a: exit 1, 103 completed finite assertions, 46.448 seconds, 884 MiB peak, no swap, cleanup confirmed. The minimal public condition and actual receipt hashes are preserved in evidence/firefox-allowlist-diagnostic-05/counterexample.json; no private key material is exported.

Firefox's exact FIREFOX_157_0_RELEASE test token source deliberately omits the CTAP 2.0 credential ID when the filtered allowlist has one entry. The bridge restores the ID only when the original allowlist had one entry. Our original two-entry request and one matched virtual credential exercise that discrepancy. The USB dispatch source separately establishes manager precedence.

Changing only the virtual protocol to CTAP 2.1 completed all 127 finite assertions, including fresh owner login, narrowed delegation, cross-tab clearing, logout, step-up and invitation behavior. Required UV and all original assertions remained. Receipt results/console-live-firefox-ctap21-selection-06/browser.json, unit ffd8e10e1f504796bc8a7cfbd63e6b72: exit 0, 29.548 seconds, 808.7 MiB peak, no swap, cleanup confirmed. This discriminates the virtual CTAP 2.0 omission hypothesis; it does not establish a Fabric or physical-authenticator defect.

Fixture corrections are commits 7c48999 and 63a63ce; prospective standalone Firefox CTAP 2.1 registration is the separate policy commit d84486a. Standalone acceptance, physical authenticators and physical Android/iOS cells remain separate. Resident-key capability was enabled, but the observed production request used residentKey=discouraged and the stored credential was nonresident; actual discoverable-credential coverage is unestablished.