Rebased onto master.

@akshayku Please review so we can merge this or move it to next WD

AFAIK @agl doesn't have time in the next 30 min to review this, and it was my thought to have him do so, thus I've removed him from reviewer list, and suggest we land this -- can always revise if necessary in the run-up to WD-03, CR, etc.

@agl @leshi @akshayku Please review

I think something like this is valuable but I'm not sure that the current working is quite capturing what I see as the essence. (Or, perhaps nobody else views the essence in the same way, in which case LGTM.)

As currently written, this text emphasises that client and RP enforcement of the RP ID is critical to security. Absolutely agree with this part. Then, in my mind the critical point is that the authenticator (which is the trusted device here, assuming that the phisher controls their own client machine) gets assurances by transmitting over a medium that has limited range. (Direct USB connections have the most limited range, but BLE is still local.)

This ensures that an attacker must have a subverted a device physically close to the authenticator, which is a much higher bar than if the authenticator is willing to communicate across the internet.

I think @agl's concerns are partially addressed by the section that discusses what tradeoffs may be made if the client and the authenticator are not being discussed directly. I still see compelling use cases for authentications where a "proximal" transport isn't possible (and I would argue that proximity is a bandaid, not a guarantee).

It would be reasonable to add some discussion more directly of what the benefits of proximity are; ultimately I think it's a choice that is best left up to implementors equipped with an understanding of the security tradeoffs involved rather than being mandated in any way.

Thanks @agl, that's a very good point and I agree. I've rewritten the section (now much shorter!) with equal focus on both the physical proximity aspect and the direct communication aspect.

on 2020-02-19 call: akshay reports msft looking into using remote SKs to remote desktop and in the desktop do things via webauthn. AGL reports that this use case is supported in chrome remote desktop. threat model remains that an attacker must compromise something nearby the user. Ought to add something to client data when operating in such a scenario. Ie. this PRs language does not preclude remote desktop use cases.