User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

I tried to log in to accounts.google.com with my user credentials, then inserted my Yubico Security Key (the old ones, FIDO v1) and touched on the tactile button.

I repeated the same process with Github afterwards.

Actual results:

The authentication was rejected until I either:

• set the security.webauthn.ctapv2 configuration to true,
• or got in through alternate 2FA means and enrolled the key again.

For the second alternative, the key was not recognised as enrolled previously, so a new key handle was generated.

Expected results:

Authentication should have succeeded out of the box.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Thanks for this report. It sounds like we broke support for the AppID extension while implementing allow-list filtering. If I'm right about that, then this should only affect 115. Can you confirm that 114 is not affected?

The WebAuthn AppID extension presents an alternative RP ID that is acceptable
in a CTAP2 authenticatorGetAssertion response. Version 0.4.0-alpha.15 of the
authenticator library implemented allowlist filtering (or "pre-flighting") to
accomodate devices that limit the number of entries in an allowlist. The
implementation of filtering did not take the AppID extension into
consideration, so credentials bound to relying party IDs matching the AppID
were mistakenly filtered from the allowlist.

Set release status flags based on info from the regressing bug 1833240

@jschanck I got a copy of 114.0b8 (64-bit) for macOS some minutes ago, and can confirm only 115 is affected.

https://hg.mozilla.org/mozilla-central/rev/80b59a654414

Thanks! Could you try the latest Nightly?

Can confirm it works again with 115.0a1 (build id: 20230526094428)!

Great!