- From: Mitar via GitHub <sysbot+gh@w3.org>
- Date: Sun, 26 Nov 2023 07:03:09 +0000
- To: public-webauthn@w3.org
> for example, crypto.getRandomValues(new Uint8Array(64)) With residential keys, that would mean that for hardware security keys you would quickly run out of them. > Setting user.id = new Uint8Array([0]) for all account creations causes any existing credential to be overwritten, locking the user out of the previously created account. That is true. This is why one would need [getOrCreate](https://github.com/w3c/webauthn/issues/1568) call so that you do not create new accounts unnecessarily. I think those two issues are intertwined. To me it is a bit surprising to have residential/discoverable keys with username at all. If you have username then you can also ask the server for the certificate ID and can have non-residental key. If you do not have username, then you should be able to call `getOrCreate`. But having a username requirement AND no `getOrCreate` to me makes residential keys unnecessary/incomplete feature. I understand that it is useful for user to be able to have some metadata to differentiate between multiple residential keys per site, but that should be asked for by the browser when site calls `getOrCreate` without username. So site calls `getOrCreate` and user picks in the browser an existing key or choose to do a new one (and pick some name for it). Site does not need to know anything about it. (Even passing the name to the site should be optional.) But having username known to the site in my view defeats the purpose of residential/discoverable keys (unless you set the field to a constant, but then we still miss `getOrCreate`). -- GitHub Notification of comment by mitar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1942#issuecomment-1826684581 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 26 November 2023 07:03:11 UTC