I guess that's the one thing you don't want to be down and yet it's down..

Don't banks have their own id:s as well? At least in another nordic country, you have quite many login possibilities to many services. Banks even provide cross-login.

As I understand it, BankID in Sweden is still run by one organisation co-owned by the big banks, and banks handle verification for issuance. There is still a single point of failure for the operation of the system.

There is technically a second provider, Freja, but that is basically only supported by government agencies, and even that is spotty.

There are talks about a state-provided one coming soon, because of EU E-ID laws.

Well I'm in Finland and seems the system here has multiple independent services and is thus potentially more resilient.

I was under the impression that all of those services and login methods rely on suomi.fi in the end, but I admit that I don't understand the system terribly well.

Same in Norway.

No. As I understand it the previous system, NemID was actually (co?)designed by the banks so this is what they all use. Likewise MitID is another unholy alliance of Nets (a Danish payment provider) and Danish banks.

Given the Swedish version of it is called BankID I assume the situation is nearly the same in Sweden.

Sweden have one other viable alternative that is Freja ID, it does not have at all the coverage as BankID but it's something.

Another one just popped up recently though it does not have a lot of coverage if anywhere yet: https://corporate.e-boks.com/loesninger/e-wallet/e-boks-id/

No. Many/most of them support login through hardware ID on your smartphone (i.e fingerprint/TPM-style pin), but the actual authorization of transfers or any privileged access is entirely MitID

MitID and NemID before it was pretty much bought by the Banks and the government together.

It is to avoid the banks needing their own id for customers, as people would need to go into the banks using their passports etc to register.

Some banks do have their own logins and IDs for various purposes, but you often need MitID somewhere in there simply to verify the actual identity of the person with the account. All the other logins simply give you access to the ID it doesn't actually verify it. MitID does that.

For example Lunar doesn't need MitID during 3D Secure (online payments), but that is only because you used MitID at some point to store your proof on your phone, that you can unlock with a secure enough method, and then do the payment. This is considered enough, as you still use an identity that has been verified by MitID at some point.

And who is the happy monopolistic receiver of this constant and unending stream of taxpayer money?

The french company IN Groupe.

IN Groupe is fully owned by the French state.

Should have stuck with NemID a previous paper alternative or only offered MitID as a digital alternative. The rush to go all digital is coming back to bite them in the .....

One of the flaws of that system was exactly that you didn't know which domains where allowed to issue the requests for a one-time key.

Each service would serve the authenticator snippet from their own domain, with their own certificate. MitID, for all it's centralization flaws, solved that by only being valid under the mitid.dk domain. I doubt that most people check the domain and the certificate, but they could.

How would you use a paper ID online? (Securely, i.e. not the insane thing of taking a selfie holding it or something similarly bizarre in an age of powerful GenAI.)

NemID, the previous national 2-factor solution, used a small card with rows of pre-printed single-use codes. When you logged in to a bank or a public sector website, it would ask for a random code at a specific row and column number. Once the system registered that you had just a handful of codes left, a new card would be sent to you via snailmail. It worked fine for the time.

The current system, MitID, depends on smartphones, though you can get an an external key generator as a backup too.

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.

> 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.

> 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

Yeah but functionally it is the same. If the website is down it doesn't matter if I got the OTP code from a piece of paper or the dongle.

The way it worked before was that you had basically a piece of paper with OTP codes and the website would prompt you for a very specific one.

How that would've prevented this issue: not at all. If the login service is down, having the piece of paper with OTP codes is worthless as the problem is not getting the codes (I can still get MitID codes with the OTP dongle) but the authentication website. The previous system was just as centralized.