- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Nov 2022 12:08:08 +0000
- To: public-webauthn@w3.org
On the topic of a less preferred preferred. We introduced preferred in Level2 because Google and some others thought it would be good for some RP to begin making discoverable credentials in preparation for going passwordless, but to not blow up android which still only has discoverable credentials in preview, and allow U2F keys to still be used. Now I don't know if preferred has actually been used for that by any RP. It seems to me that there are three classes of RP. One's continuing to use Fido as a second factor with allow lists. These could send resident key discouraged but that may not do the correct thing on upcoming android if the RP wants there credentials to be backed up. RP's allowing a hybrid type of login based on the autofill UI where they login with a passkey if one is available otherwise they fill a username and password and then do a traditional allow list second factor. This may be a path for RP with existing U2F credentials to transition to passkey. These RP probably should be using preferred to make new credentials. Old Android and U2F will continue to work but only as second factors. The problem is that security keys will fill up quickly and may not have space for sites that only support discoverable. Discoverable only (eg Microsoft). These sites will use the autofill UI or a button with no allow list. These sites must logically set resident key to required or they won't work. To be realistic there is not all that much we can do in the spec. Windows 10 is still using CTAP2.0 so the browser doesn't really know what the authenticator is before invoking L1 webauthn.dll it has to guess at the two L1 options true or false. However, there may be some fine-tuning we could do in L3 for some platforms. We probably want preferred to make a discoverable credential in all cases that make sense. We clarify that rather than making the credential discoverable if there is any available space that the platform only makes it discoverable if remainingDiscoverableCredentials (0x14) is absent or has a value of less than 25. That allows for CTAP2.1 authenticators with larger storage to create discoverable credentials by default until the storage gets tight, but continue to reserve some slots for discoverable only RP. Perhaps 25 is not the correct number, but I think fine tuning the logic for preferred is better than confusing RP with yet another option. Again even doing this is not going to get into all platforms in the next year or so, or stop RP from just setting resident true even if they are only supporting second factor flows with allow lists. A bit of fine-tuning may help some people but realistically won't have a major impact on security keys going forward. -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1310188296 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 November 2022 12:08:10 UTC