Face ID and Touch ID for the Web

Since we are really talking about WebAuthn and not just the iOS implementation, You probably could use alternative hardware (maybe android based) that supports the multiple-user biometric use-case. From the server/web-app side it still would just be WebAuthn.

Looks like you use a separate device like this: https://www.ftsafe.com/Products/FIDO/Bio

That supports fido2, hooked to any tablet to make it work.

This isn't really true any more. Apple requires their competitors' browser apps to use a 'webview' to display websites, and Safari does not use this. The iOS webview may share a layout/paint engine with Safari, but it is heavily restricted in other ways. Apps with webviews (like Chrome for iOS) can't have extensions, for example. But the subtlest, cleverest restriction is that webviews are forced to use an older and slower JavaScript engine. This ensures that websites feel a little slower in Apple's competitors' browsers. Another major upshot of this is non-Apple browsers can't offer the same modern JavaScript APIs to websites as Safari can. For example, last time I checked, 'getUserMedia' was not available on iOS outside Safari, meaning non-Apple browsers can't support web-based video conferencing tools like Jitsi. This also implies that websites running in non-Apple browsers won't necessarily have access to the APIs necessary request Face ID sign-in, unless Apple decides it is in their interests to make this available to webviews.

It's mentioned in the video as well that website should always use this as faster sign in option with providing other options alongside.

Similar to how you would sign in on devices/browsers without WebAuthn support or don't have physical token (Yubikey/etc.) with you: use a fallback method provided by a website. This is usually TOTP or a scratch code. The website need to implement it though.

One thing to keep in mind is this is not supposed to be the only factor required to sign in. It should be used as a 2nd factor in the similar way to TOTP (but with much better usability).

Apple is considering this to be multi-factor authentication all in one click, the something you have (the phone) and the something you are (FaceID or TouchID). For the site perspective, if you ask for attestation then you will have cryptographic evidence of this. No more SMS 2FA!

Apple is promising to do something extra with their attestation process which they call "Apple Anonymous Attestation" to mitigate the issue where attestation allows tracking the same device across different websites even if they are using different usernames. Not included in the current release, but "coming soon".

The process of enrolling an authenticator is presented as a "one and done" event, but of course the devil is in the details. Shared accounts would need multiple authenticators, and what happens when you upgrade your phone or lose your phone? I guess this gets handled like a password reset. You probably will want users to be able to add/remove authenticators, which means also having to name them.

The enrollment process in this video highlights the upgrade path from a password login to a FaceID/TouchID login, but doesn't give us the UI flow of a new login. It seems like sites would need to implement a standard registration page and then perhaps swap out the password field with a Next button which would prompt for the FaceID/TouchID enrollment. Makes me wonder how does this compete with or tie into the 'Signin with Apple' if a site wants to offer one-click registration?

Will my Mac and iOS devices automatically and securely sync the private keys between their respective Secure Enclaves so that I can signin from any of my devices after enrolling on just one?

Lastly, how about the case when returning to a site where the user is on their enrolled device, but there isn't a cookie present. It looks like the site can detect that the device supports Webauthn, but I'm not sure if it can automatically detect that the device already has an account enrolled with the site?

The call to 'credentials.get' includes the 'credentialIdBuffer' which is a value provided by the platform authenticator and saved during registration. But in the video they make it sound like 'credentialIdBuffer' is actually optional? It's not even clear to me in the official WebAuthn spec [1] if this value is required, or if the authenticator will just use the RP domain to present the user a list of available credentials? Ultimately I'm wondering if a user without a cookie will still have to type in their username before the site can prompt them for FaceID/TouchID authentication.

[1] - https://w3c.github.io/webauthn/#dom-publickeycredentialreque...