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

Re: [webauthn] Managing FIDO keys (#1612)

From: Matthew Miller via GitHub <sysbot+gh@w3.org>
Date: Fri, 14 May 2021 18:56:59 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-841439017-1621018617-sysbot+gh@w3.org>
> Assume an RP wants to perform an update like replacing an RSA key with an Ed25519 key. Effectively the current credential management scheme seems to presume that you just add keys.

@cyberphone I think the way to accomplish this is to require the use of resident keys during attestation. Since resident keys are stored internally in the authenticator keyed to `rpID + userHandle`, replacing a key should be as simple as:

1. _Don't_ specify the ID of the credential being replaced in `excludeCredentials`, and require resident keys, in attestation options
2. Make sure `user.id` is the same as was used last time performing attestation
3. Upon successful completion, register the new credential in the DB and delete the "old" one

Internally the authenticator will drop the old resident key and replace it with the new one. The RP just has to make sure to clean up afterwards or else it'll have a bunch of zombie credentials. Is this what you were looking for?

> I have tested several WebAuthn demos (Duo Security, Yubico, StrongKey) and they all seem to pass on deletion of keys which leaves you with lots of "zombie" keys which then makes the selection process unmanageable. The tests were mainly performed on W10 using resident keys (Windows Hello).

When I read this I instantly flashed on the fact that many demos generate random user IDs every time you perform attestation. If resident keys are being required, or if the authenticator chooses to store a resident key on its own (Touch ID on macOS does this...), you can easily end up with a ton of junk credentials 🙃 

![Screen Shot 2021-05-14 at 11 50 31 AM](https://user-images.githubusercontent.com/5166470/118315659-a58f3d00-b4aa-11eb-8191-218b0429660a.png)

I agree it's frustrating that there's no way to delete these until A) Chrome decides it's important enough to make it into their growing selection of security key, and B) platform vendors see fit to add in UI to manage resident keys.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 May 2021 18:57:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC