[markkum]

First; the user does not have to care about OS, browser, ip address or location. Though those can be shown to a user if the service provider wants.

Authorization requests can only be initiated at the back-end by authorized service providers and only for users who have linked their MePIN app with that specific provider. Though of course login verification could be initiated with stolen username/password, which would then alert the user for verification.

Now the added benefit here is that with MePIN the user would immediately know that her username and password is at wrong hands if she receives a login verification request while not actually performing a login.

So obviously the user should not authorize unexpected requests. You would not authorize a login if you are not actually performing a login, etc. Concerned users can additionally set up a personal PIN code in the app.

Lack of good usability is currently hampering 2FA adoption, we are working hard to fix that.

[davis_m]

In this model, all you have to do is time the authorization request appropriately. If an attacker can time their authorization at the same time that the user is logging in, a large number of users are simply going to authorize both requests thinking that it is some sort of glitch.

With the standard OTP model, a user physically can not enter their code for another user.

[markkum]

Unfortunately there are several cases where users have entered an OTP code for another user. The recent high profile case was with World of Warcraft's OTP.