Closed duaneellissd closed 4 years ago
No, the goal is not to automate the 2FA process. The goal is to allow service providers to annotate their one-time code messages with an origin, so that user agents can only assist with providing the code to websites when there’s an origin match.
That sounds some what like a variation of case (B) - where the user might choose to stop/abandon the process, and/or the user agent is a bit “too helpful” or “more helpful” then the user wants.
B) What if the remote site sends an authentication request unexpectedly (or even maliciously) to the mobile device and the user does not want, or explicitly changes their mind and does not want to continue with the 2FA login request, or needs to abandon the process for some reason.
This can happen today, and this proposal has no effect on that possibility.
@rmondello wrote:
this proposal has no effect on that possibility.
I agree. I don't think we need to change anything in the explainer here. I'm closing this issue; please let me know if we've missed something.
Is the goal of this to automate the SMS 2FA process?
What happens in these situations:
A) The 2FA code appears on my cellphone, but the 2FA must be entered on my laptop and my laptop, or some other computer that does not communicate with my cellphone.
Do you expect, or suggest the cellphone browser to launch and visit the website to complete the authentication? Would that “eat-or-consume” the one time code? How could I stop this and go into a ‘manual mode’ so that I can enter the code some where else “the old fashion way”
B) What if the remote site sends an authentication request unexpectedly (or even maliciously) to the mobile device and the user does not want, or explicitly changes their mind and does not want to continue with the 2FA login request, or needs to abandon the process for some reason.
C) How would the mobile device know which browser to launch? And which mode (ie: Private, or not private) to launch or use?