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

After discovering this issue last week I brought it up with a colleague. After some discussion we ended up agreeing that the ability to overwrite credentials (and the current abstraction of how a credential might be persisted internally within an authenticator) is actually a _good idea_. If there's a reason a user needs to re-enroll an authenticator then it's as simple as a second `navigator.credentials.create()` call without the existing credential's ID in `excludeCredentials` to get the authenticator to generate a fresh credential (and internally overwrite the existing discoverable credential that isn't wanted anymore anyway).

> But if the RP wants to detect an existing registration and let the user (re-)register it, here is the simplest "safe" way I can think of...

Is there something wrong with allowing a user to log in with an existing-credential-that-should-be-re-registered, then forcing the user to re-register it during login? Here's a flow we imagined for re-registering a credential:

1. RP requests assertion as usual w/existing Touch ID credential which is flagged for re-registration
2. User successfully generates **assertion** response via Touch ID
3. RP sees that returned credential ID corresponds to a credential flagged for re-registration
4. RP requests attestation **without the existing Touch ID credential ID in `excludeCredentials`**
5. User successfully generates **attestation** response via Touch ID
    1. Touch ID overwrites existing discoverable credential
6. RP saves new Touch ID credential
7. RP deletes old Touch ID credential that was flagged for re-registration

This seemed to us to be a straightforward re-registration flow that would work with the current release of the spec without the introduction of any new APIs. Is there something "unsafe" about this flow?

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


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

Received on Thursday, 15 April 2021 00:09:24 UTC