They don't solve the technical issue, that's the thing. Once you can match the public key to a legal person with their tax number, it's more or less a weekend of coding to get 80% there.

But to get there you first need to have access to the government API giving you information about a person with certain tax number (name, DOB, address) so you can send them a letter with the code, for which you likely need to be inside their security perimeter. Then you have to actually send the code and have the app generate the key. Then sure, you can expose oauth2 provider and authenticate user with an HOTP you enrolled after they entered the binding key from mail. That's about the whole thing if you don't count bells and whistles.

Bells and whistles include:

- talking to the physical id card so you can mark the key as high trust;

- keeping the session open so second login during 15 minutes would be confirmed with one tap in the app;

- backup authentication method with sms-otp;

- all the nasty stuff that happens with fraud and blocking access but you can't just block the customer and tell them to go somewhere else;

- antidebugging and obfuscation nonsence in mobile apps because CyBErsEcUritTy (second level scam);

- fancy paper to print one time codes that come by mail (not sure DigID does this, but banks do)

You want an idp who verified that the account belongs to a specific citizen. There needs to be some loop closing between your bsn (akin to a social security number) and user accounts. That in itself is not something you can just handoff to auth0 or that you want different departments to self select and self-host.

Digid is used to submit taxes and for getting benefits from the government.