The problem can be reproduced on https://webauthntest.azurewebsites.net/ or other test pages by registering 12 or more credential ID with authenticator A, then register Authenticator B (Registration can be done on any platform.) Tests were done with a Yubikey 5 NFC, other keys will behave the same but may have different sized credentialID and or transport buffers. On iOS use Authenticator B to authenticate via NFC tap. The encoded request will be larger than the 1200byte maxMsgSize supported by a YubiKey The authenticator will appear unresponsive. Over NFC the authenticator will return a NFC layer error SW_DATA_INVALID. iOS is not capturing that error and continues to wait for a response. Over USB the behavior is harder to debug. Due to transport differences a CTAP error is returned TAP1_ERR_INVALID_LENGTH after the first APDU is received. iOS seems to continue sending APDU but eventually stops and retries using CTAP1/U2F commands if user verification is set to discouraged at the WebAuthn level. If we look at Message encoding https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#message-encoding The platform needs to look at maxMsgSize and not send larger messages. The current code clearly breaks over NFC with a large allow list and over USB with a large allow list if user verification is required. In get Assertion 6.2.1 https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#sctn-getAssert-platf-actions step 1.1 pre-flight is discussed as a way to process large allow lists. The getInfo maxCredentialCountInList (0x07) and maxCredentialIdLength (0x08) should be used to filter the allow list and batch credentalID into requests with PinTokens to step through the allow list rather than falling back to U2F. This has been seen to be a problem over NFC with Google Advanced Protection accounts when multiple authenticators are registered. As Google sends uv discouraged authentication the U2F fallback works for those accounts over USB. There are other sites that set user verification preferred or required in WebAtuthn, those sites will break over both NFC and USB if the allowlist is too large. In the short term over NFC you could try immediately falling back to U2F if the allow list size would cause a request to be too large. The correct long term solution is to refactor the code to properly deal with large allow and exclude lists, using the information in getInfo. I hope the additional platform info in CTAP2.1 can help explain things.
<rdar://problem/73199796>
This is an ongoing issue. With sites like Github allowing multiple credentials to be registered, The allow lists are starting to trip this issue. The user sees the no credentials error for the authenticator once the list gets too big, until they delete one on the server, and then it works again. 8 to 10 credentials triggers this depending on authenticator.