Many of the questions about TOTP lengths / timing / storage are covered in the Security Considerations part of the RFC[1]. This is written in fairly plain language. The meta answer is if you're implementing a security protocol yourself, you should always be reading the RFC for this sort of thing. If you're designing a library to implement a security protocol, you should document the parts that need to be implemented according to spec (e.g. storage / transmission / time / etc.).
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.
[1]: https://www.rfc-editor.org/rfc/rfc6238#section-5
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.