I think Tim was referring to discoverable credentials in passkeys which are not the same as resident credentials. * correct me if I'm wrong Tim
"as we start moving to a passkey-centric world"??? Really, I think that's a little bit of a stretch. I know GAMA would like that but I don't think that's a near term goal or a solution for everyone.
I really don't want my bank supporting passkeys just like I didn't want them supporting Google sign-on.
You haven't described your environment for a solid answer so I'll wing it a bit.
My first question would be is your user base enterprise or consumer?
The exploit described on that document I feel would come from a nation state attacker or is targeting a very high value target. Getting close to someone to get a security key to retrieve credential ids is a huge risk for someone and they payoff needs to be worth it.
The customers I've worked with have mostly deployed username/password/security key. They did this because users were mostly okay adding the security key but when you totally switch them away from a password they seem to have more questions. They realize this is a journey to passwordless and just because the tools are available doesn't require you to implement them.
Also, they were able to relax the password policy since they were adding strong authentication with a security key.
If they had specific users they were concerned about for this type of attack they would deploy out security keys that could only be registered with their service, yes those keys exists and I'm not sure you would get that control with passkeys.
The way I deployed on my own app is the following.
username/password -> submit
Server checks if username/password are valid
if yes, send fido auth with associated user creds
if no, send fido auth with random credid that is invalid
Final result would either by successful login for valid username/password/security key
Invalid login. Nothing mentioned about security key or password or even username
Hope this helps and enjoy your journey,