The big drawback of one time passwords is that it doesn't protect against man-in-the-middle attacks such as phishing, which is in practice one of the most common attacks on systems of this scale.

The logistics operation involved in distributing codes is also very expensive and inflexible. You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

Given all this, a good old public key infrastructure makes sense. But that is unfortunately also usually the first step to a complexity explosion.

> The logistics operation involved in distributing codes is also very expensive and inflexible. You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

Neither of the scenarios you describe would require you to authenticate using MitID: Peer-to-peer payments in Denmark are typically done using the app MobilePay, which only requires MitID authentication during setup. And you never need MitID authentication when paying in person, at most you'll need your card's pin-code

> You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

It's very unlikely people would need to mess about with MittId/BankID if they can't use card payments at a market. Firstly, if they're doing the almost-unheard-of clunky approach of using their mobile banking app to make a bank transfer, it would probably be authorised using their touch/face ID instead of BankID/MittID. But far more likely, they'd use one of the ubiquitous mobile payment apps: Vipps (Norway), Swish (Sweden) or MobilePay (Denmark).

> The big drawback of one time passwords is that it doesn't protect against man-in-the-middle attacks such as phishing, which is in practice one of the most common attacks on systems of this scale.

This is true and was definitely a criticism of the old system, where websites would open the NemID iframe and ask you for your username, password and a specific indexed OTP code, without providing any authentication to you. You only notice something weird if it asks you for an the index of a code that is not on your card but maybe the scammer is lucky and guesses an index that you have and then they can use that phished username/password/OTP triple to perform an unauthorized action.

The new system is slightly different, because if you use the mobile phone authentication it will send you a notification to your phone, but if you use the (bespoke, non-standard) OTP dongle it still does not authenticate itself towards the user. However the codes are now time-based so if they collect an OTP code they can only use it in a ~30s window, so the phished credentials have to be used immediately.