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

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

Thank you for the feedback. I have made a couple of updates to the explainer to try to help clarify some things, and have responses below.

> [@kenrb](https://github.com/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.

This proposal would not allow enumeration of tokens, and it does not repudiate [the stated privacy design goals of WebAuthn authentication ceremonies](https://w3c.github.io/webauthn/#sctn-assertion-privacy). We tried to be explicit about this in the privacy section: `It would not learn any information about the credentials until the assertion is returned, but the single bit available from the API returning immediately with a NotAllowedError, or having a long delay due to UI being shown to the user, represents a relaxation of WebAuthn privacy protections.`

By prohibiting non-empty `allowCredentials` lists in these calls, the credentials are not named credentials as defined in the spec.

When invoking this method results in the showing of UI, the site would be able to infer that at least one credential is present, but it learns nothing about the credential itself. When the method returns immediately without showing UI to the user, the site learns that the user either does not have any credentials available, or else some factor is true that is preventing them from being shown (such as the authenticator having too-high latency, and the call timing out).

Does this address your concerns?

> 
> 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).
> 

We acknowledged this in the explainer: `To avoid incognito fingerprinting, this response can be delayed by the browser to simulate the browser fetching credential metadata from the system.`

The intention is that when this call is made in an incognito session, it should be indistinguishable to the site from being in a normal session but no credentials being available. We think there are benefits to disabling the feature in incognito, but this could be discussed if there are concerns that it would leak the incognito state.

> 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.
> 

I have now added [a new section to the explainer](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation#goal) that addresses more directly the intended effect on user experiences. Please let me know if that still doesn't make it sufficiently clear.

> 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?
> 

I have now expanded [that section with some clarifications](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation#supporting-cross-device-authenticators). We expect that this will not change the experience for security key users, who will see the same sign-in flow that they use today.

> If the primary purpose of this change is to engage a re-authentication flow...

We do not envision this being used for re-authentication flows. When a site knows the identity of the user from a cookie and wishes to re-authenticate them with a passkey, the existing modal WebAuthn UI is sufficient. The targeted situation is one in which a site does not know the identity of the user, and therefore doesn't know which authentication mechanism they are likely to use. Where a user has a locally available credential for the site, they would see a see a confirmation UI from the user agent to use that credential, and then be signed in. If not, the user is presented with the usual array of sign-in options from the site.

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

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