W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2021

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

From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Feb 2021 16:20:43 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-776060172-1612887601-sysbot+gh@w3.org>
> In that case, the RP cannot create a new registration without the risk of silently invalidating old registration.

Don't understand. Why would existing registration will not suffice? And if a new credential is created somehow, then that credential will work. 

> The RP can avoid this by including all security key registrations in excludeCredentials when calling create for a new passwordless/usernameless registration. 

Yes, that would be my recommendation.

> 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:

Sorry, don't understand the need for it. Once a credential is created, RP should check for `uv` bit to figure out whether that credential can be used for passwordless flows. And in .get() call you pass all the credentials which are `uv` capable to the authenticator if you are doing the with-username flows. 

> Windows Hello and Safari might change their implementations to avoid overwriting security keys. 

Windows only supports resident keys for some releases and will follow the behavior of overwriting the existing credential if exclude list doesn't contain that credential. 

> But if Windows Hello/Safari can't tell which existing registrations were created with requireResidentKey: true (I don't know, but they might be able to?)

Windows don't store the request details, so we don't know. 

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 16:20:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 9 February 2021 16:20:46 UTC