- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Jul 2023 00:47:46 +0000
- To: public-webauthn@w3.org
@r-jo Ultimately this actually comes down to the RP. In https://github.com/kanidm/webauthn-rs we enforce that the userid is a uuid, and the displayname can be any str input - even blank. This is needed so in a discoverable workflow we have to identify which credential matches to which account. We don't even need to store and PII, but we just need to tie it to the account. The alternate is to have a way to id the user before to know what credential id's to present as valid in the authentication (non-discoverable) where the RP checks the userid/username first. The displayname is *just* for the client side in discoverable to allow the user to ID what user account they are about to use to authenticate, but its NOT transmitted as part of that operation. Finally, RP and challenge *are* mandatory and have extremely critical security implications for how webauthn works. Webauthn does have it's complexities and issues, but "privacy" as you are describing is not one - it's simply up to RP's to implement privacy preserving implementations of webauthn that respect users. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1617061229 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 3 July 2023 00:47:48 UTC