How to guarantee created resident key is actually received by RP in adverse networking conditions?

[arianvp]

I've noticed that under adverse network conditions (very common on mobile phones; especially in rural areas) it can happen quite often that the navigator.credentials.create call succeeds but the credential never gets received by the RP and users end up with many "junk" resident keys in their Apple Keychain because of it. There seems to be no way to avoid this happening. excludeCredentials is not an option as the RP isn't even aware that the credential is created. And the user is frustrated because they half of the time select the wrong passkey.

Note this is an issue I have actually observed in the wild. (in this image only one of the two passkeys work. One was created whilst artificially throttling the network in Dev Tools, causing the credential to never be received by the RP)

How are RPs supposed to make this robust? My only solution so far is to drop the whole idea of allowing people to create resident credentials. Instead always opt for using server-side credentials.

There is also no way for the device that stores the credentials to know which credentials are valid and which not; so it can also not be fixed on that side.

Hypothetically I think perhaps a hybrid flow would be nice where a server-side credential can be "upgraded" to a resident one during the first get() call. Anything else seems to be prone to failure.

1. With the initial create() call; the credential is initially stored as a server side credential as credential id cid1
2. The first get() MUST include allowCredentials: [ cid1 ]
3. Only after the first get() call does the authenticator actually store the credential as resident key. And maybe we can signal in the response from get() that the key is now stored as resident
4. subsequent calls to get() can be done without allowCredentials

Originally posted by @arianvp in https://github.com/w3c/webauthn/issues/1569#issuecomment-1871971272