- From: Mitar via GitHub <noreply@w3.org>
- Date: Thu, 10 Jul 2025 18:36:02 +0000
- To: public-webauthn@w3.org
> Leaking internal user IDs on every call to WebAuthn would have massive user privacy implications... I do not follow. For prior proposals like `exists()` have counter-arguments that they would enable RP to get too much information about credentials/users the user has authenticated with. This proposal solves this problem by requiring RP to know the user ID but does not know for sure if that credential really existed or not. It just prevents a new one from being created. In the use case I am interested in RP is using a constant user ID for all users anyway. So there is no leakage at all. So what is the threat model you have in mind and which leakage of what to whom you are worried about? Of leaking of user IDs RP knows about to clients? I hope RPs would not be doing that but use `excludeUsers` only for user IDs it has some additional information that the client potentially already knows about. Similar to how it is done with `excludeCredentials`. You also do not list all known credentials known to RPs in `excludeCredentials` and you would not list all known users known to RPs in `excludeUsers`. That would be silly. -- GitHub Notification of comment by mitar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2309#issuecomment-3058515061 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 July 2025 18:36:03 UTC