Re: [w3ctag/design-reviews] Web Authentication Immediate Mediation (Issue #1092)

martinthomson left a comment (w3ctag/design-reviews#1092)

@kenrb, Can you help us understand the proposal better? We understand that the original design of WebAuthn to have a goal of preventing sites from being able to enumerate the set of tokens that someone might have. They only learn of a token when someone chooses to use that token. Otherwise things time out, revealing no information.

This seems to be a direct repudiation of that design goal, which would not be acceptable. We don't think that the mitigations you list (activation, no allowlist, no private browsing/incognito) are sufficient here.

The fact that one of these mitigations could distinguish a privacy browsing or incognito session from an ordinary session is something [we specifically advise against](https://w3ctag.github.io/design-principles/#do-not-expose-use-of-private-browsing-mode).

The end-user benefits are not listed in the explainer. The use case helps, but that doesn't seem to be comprehensive. We prefer to see explainers that address the question of [what end-users gain](https://w3ctag.github.io/explainer-explainer/#end-user-need), even if the benefit is indirect. In this case, we were unable to identify a benefit, only downsides. Perhaps the goal is to show QR codes less frequently.

The effect on cross-device authenticators is not clear. It seems like there are a few steps missing in the explanation here. Is this because cross-device authenticators won't be immediately available under this system? Do you expect that a site that has been accessed with a cross-device authenticator will create a local (and therefore immediately available) passkey? Does that mean that this flow is generally aimed at re-authentication interactions?

If the primary purpose of this change is to engage a re-authentication flow without bothering users with the whole process if they haven't previously enrolled with a passkey, perhaps there is an approach that will allow that. Consider that an enrolled passkey has an identifier (the public key in the absence of other identifiers) and the site already knows that if it has a cookie or weaker signal like a login/email/phone number that was entered. If the site can demonstrate knowledge of something like the public key, then allowing immediate access to that public key, if it is present and the user permits access, has far less privacy impact. Yes, a site could embark on a guessing game to find a particular person, but that's not a winning strategy given the difficulty of guessing a public key. You could even allow for a short list of public keys to account for the site not being able to pick a single one for an account.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-2978843473
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1092/2978843473@github.com>