Re: [webauthn] Prevent browsers from deleting credentials that the RP wanted to be server-side (#1569)

I have a follow-up question on this that seems related:

I've noticed that under adverse network conditions (very common on mobile phones!)  it can happen quite often that the `navigator.credentials.create` call succeeds but the credential never gets received by the RP and our 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 field.

Combined with this behaviour of replacing the existing server-side key this can also completely lock out a user due to a bad network!  This sounds extremely fragile.

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.  

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 prone to failure.

1.  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`

-- 
GitHub Notification of comment by arianvp
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1569#issuecomment-1871971272 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 29 December 2023 11:28:54 UTC