This is a regression. Safari was using CTAP2 for CTAP2.0 and CTAP2.1 devices. In Safari 15.1 and STP 15.4 I am still seeing Safari using CTAP2.0 for make credential, but all getAssertion commands are using CTAP1/U2F to talk to CTAP2.0 and CTAP2.1 authenticators. If the RP specifies User Verification: required then the external authenticator doesn't flash, Safari appears not to send the request to the authenticator. I have tested with older CTAP2.0 authenticators so I don't think it is anything new with getInfo on the keys that is causing this issue. I recall that this happened before because of a getinfo parsing error causing Safari to fall back to CTAP1. However since this is not impacting makeCredential it is probably something else. Currently any site that sets User Verification required (EG Microsoft) is going to be broken with roaming authenticators.
Thank you for filing. The appropriate engineers have been notified.
<rdar://problem/83773379>
If applicable please attach a reduced test case that demonstrates this. Thanks
Hi! I've been attempting to replicate this but am unable. I attempted getAssertion with live.com login (needed to set user agent to (Google Chrome - MacOS to get the option to use a security key to show up) with two different registered security keys (Yubikey 5c nano, Authentrend ATKey.Pro) on STP 15.4 (using releases 132, 133). I also tried using https://webauthntest.azurewebsites.net
The behaviour seems intermittent. It is observed in Safari 16 and 16.1 on MacOS 12.6 and 13.0. And it is observed during makeCredential. When forcing the use of CTAP2 (by using a CTAP2-only key) the modal credentials.create dialog appears without the security key flashing, resulting in a timeout. When using a CTAP1+CTAP2 device, it will intermittently fallback to CTAP1, and trigger another bug (https://bugs.webkit.org/show_bug.cgi?id=247344) resulting in an incorrect RP ID Hash. Once this issue is triggered it can be reproduced consistently until Safari is restarted.