> Just as an informational point, it is not one passkey per domain. It is one passkey per user handle (e.g. account) per RP ID (domain).
Good point. I didn't test the distinction and I appreciate the clarification.
Thank you for this link, I'll keep tabs on it.
> If you do that authentication *prior to* the call to navigator.credentials.create for new passkey registration, rather than after, then this wouldn’t be a problem.
Yes, we will be reworking that flow to minimize the chances it not completing. We hadn't realized this was an issue until recently so the flow was created without that risk in mind.
> Is the root of this problem that `navigator.credentials.create` also saves the passkey on the device at the same time as it's generated regardless of whether it's submitted or not? In other words, is there any intermediary step between the passkey getting created and saved where the system would wait for a callback or event that the RP could throw on successful registration?
I'm not sure how that would work in practice since the user's device would need to save the passkey but in some sort of temporary(?) state and then move it to a permanent state once persist is called but there's a chance the user removed the USB key or something else happens which leaves it stuck in the wrong state. I'd welcome this sort of change though if it could be figured out.
> I suppose with multiple passkeys allowed per-account per-domain that might not be as much of a problem since as long as it's not replacing an existing passkey; the new passkey could be deleted without any ill effects if the RP encountered an error saving it.
Even if the existing passkey is deleted, we've at least 2 users create multiple passkeys on accident in their Google account and then be confused later which one is the right one. It's not obvious (besides trial and error) and even harder to identify the extraneous ones to delete once you've found the one that worked.
Thank you for all the quick and helpful replies!