I don't think the main concern is spatial proximity, but rather that the communication with the authenticator must be mediated by the user's client so that it can enforce origin restrictions. The example brought up on yesterday's WG call was using network-based transports to communicate with the authenticator, much like using a mobile push notification as 2nd factor.

Consider an authentication flow like this:

1. Alice goes to log in on example.com.
2. example.com sees that Alice has 2FA enabled, and sends a push notification to Alice's mobile phone.
3. Alice's phone prompts for confirmation to log in to example.com, Alice confirms.
4. The phone signs the challenge in the notification and returns the signature to the server.
5. example.com receives the challenge signature and allows Alice to log in.

This architecture is vulnerable to phishing:

1. A phishing attack lures Alice to try to log in on evil.com.
2. evil.com uses Alice's username and password to start login on example.com.
3. example.com sees that Alice has 2FA enabled, and sends a push notification to Alice's mobile phone.
4. Alice's phone prompts for confirmation to log in to example.com, Alice confirms.
5. The phone signs the challenge in the notification and returns the signature to the server.
6. example.com receives the challenge signature and allows Alice to log in.
7. evil.com receives Alice's session cookie and now has control over her account.

example.com could thwart this attack by requiring a cookie-based secret in addition to the mobile push, but that won't work for initial sign-in with no pre-existing state. The push notification can of course include some details (e.g., geo-IP) about the client that initiated it, but the strength of WebAuthn's phishing protection is that it doesn't rely on the user noticing something wrong. That protection only works if the client can tell the authenticator what domain the user is currently visiting.

I'm guessing browser extensions like Krypton can get around this during installation by setting up a long-lived session between the extension and Krypton's server, so that their server can refuse to send the push notification if initiated from anywhere else than the user's registered browser, so that the browser can enforce the origin restrictions.

I'm definitely curious to hear if folks feel that proximity is a factor that provides phishing resistance properties. I've heard that reasoning more than once, but I'm not sure I understand the claim.

The architecture @emlun describes above is definitely vulnerable to phishing. I would assume that, in the case of a network-based transport, the WebAuthn client would still be required to do the domain checking that it does with the other transports. In my mind the browser would still act as the client in such a case, rather than push notifications being triggered by the RP.

Concerns about phishing can be mitigated by some sort of channel binding between the browser and the authenticator, or by placing trust in the cloud service that manages the push notifications. Both approaches have their own advantages and drawbacks.

@emlun's analysis of the phishability of the architecture outlined in his #1257 (comment) seems overall correct (on quick skim)

The original thrust of this issue is "authnr & client platform proximity" which is a not-so-clear way to say "authnr & client secure channel establishment via a non-MITM-able non-evesdropable channel, e.g., one requiring physical proximity, eg the authnr scanning a local-client-displayed QR code containing iniital key seeds/shares, or, the client and authnr communicating over physical USB connection (and sharing keys), or over NFC (and sharing keys)." I.e., this is how caBLE's handshake's security guarantees are established.