This is a reflection of the fact that we have no good way for someone to digitally prove their identity. Some countries are getting close-ish - Denmark's NemID system, for example, is used by a lot of financial institutions.
However, there remains no easy way to make ad-hoc verifiable statements like 'I am John Smith and I authorise you to send this data to xyz@example.org'.
Governments, please solve this problem! Essentially: combine NemID with Keybase and build a UI that normal citizens can understand.
Italy's "PEC"[1] (Posta Elettronica Certificata, or Certified Electronic Mail) comes pretty close.
There's even an RFC[2] for it.
In order to get one, an individual has to prove their identity via a government-issued ID (ID card or passport), and that email address can henceforth be used to send emails for all official correspondence as if it were certified/verified mail, with the added bonus that both parties "know" the identity of the other party (i.e. the company knows it was very likely me who sent it, as they trust that the people in charge of having verified my ID did their job) and with the added bonus of the _contents_ of the email also being certified to have been sent from that recipient to that destination address, and not to have been tampered with (great thing to have for lawsuit reasons), unlike "standard" registered mail, who only certified that a letter has been sent and picked up.
Estonia's ASICe containers have solved signing any electronic files/documents. Italy is reinventing the wheel a bit. ASICe as such is actually an official EU standard since 2016 and EU law¹ enforces that such digital signatures have to be accepted in every EU member state. Estonian digital signatures have used another standards before though, first Estonian digital signature was given in 2002.
The ID-card also provides S/MIME should someone want to use it but people usually just use ASICe.
Denmark has a similar service called eBoks, but it's a proprietary SaaS product rather than an open standard. What's the user experience like with the Italian system? Does every company support it?
> This is a reflection of the fact that we have no good way for someone to digitally prove their identity.
Centralized identity isn't a solution, it's the problem. Once you implement something like that, it requires everyone to track everything using it in order for it to be used to authenticate access to the information. Which means everybody has to store the ID number as a field in every database and it becomes a de facto primary key that allows all information to be correlated by every blackhat that compromises more than one data set.
Meanwhile there will be the "just make it work" people who are bad at security, who will do whatever is necessary to compromise their own security because the attacker told them to. And then we would then be giving attackers the capacity to take over their entire lives instead of only one relationship with one entity.
Moreover, the scope of the damage if someone were to compromise the central identity system in general rather than only for a specific person is horrifying. It would become a single point of compromise for the whole country. And the worst kind on top of that, because everything would hook into it which would cause it to become ossified and difficult to update. If the system was then publicly compromised, how long does it take for everyone everywhere to update every piece of code to use the replacement? Which thing do you do in the meantime, continue using the compromised system as all hell breaks loose, or shut down your entire country?
There is a better solution. If you have an account with someone, you make requests by authenticating in the same way you do with your account. And if you don't have an account, you should be able to request deletion of the data associated with e.g. your IP address, but not request to download it -- because there is no way to to verify your identity for that. Even with centralized ID an IP address can be used by multiple people who shouldn't be able to give consent for one another and may not be mutually distinguishable by the party receiving the request, and the same for most other global data (e.g. many people share full names with other people). The only way to make centralized ID work in that context is to tag everything with it to begin with, compromising all anonymity and pseudonymity -- which can't possibly be the right trade off for what is supposed to be privacy legislation.
Fun fact, the EU has made a law that should force countries to implement their PKIs for people to be able to digitally sign documents and that those signatures are equivalent to hand written ones.
Latvia's ID cards support e-signing of digital documents, so I could have a pdf "I authorise you to send this data to xyz@example.org" and sign it so that the recipient can securely verify that this was signed by Name Surname ID123.
Estonia has it quite similar, I'm not certain if it's technically the same standard or something slightly different.
The Netherlands uses DigID, which is effectively a federated identity provider. Problem is that it was originally intended for government use only (recently it's been expanded to include health insurance providers), and it's not accessible for commercial entities.
It was also marred by very bureaucratic policies, for example to get information on account usage (e.g. how many times was my account used, from which IP, to access which site) you would need to file a police report first, and it supported 2FA very early (through SMS service, now via mobile app as well) but the end user could not forcibly enable 2FA, only the target service could determine if they wanted two-factor authentication on their site. Luckily, those have been fixed.
Would be nice if they supported open standards like OAuth though.
I gather the Dutch company behind DigID, digidentity, is also one of the companies behind UK's "Verify" (used on gov.uk).
Barclays, Post Office Ltd, and Experian are the other options -- if memory serves these 3 all had major security breaches.
I recently had to apply for a criminal records check ("DBS") and the government's DBS (Disclosure and Barring Service) required me to give up all my ID to one of those companies "to identify me" before I could apply; in case someone who was not me was applying for the information.
Aside, it seems they could have allowed anyone to apply (and pay the £25 fee) but only sent the response to a known address, which they could cross check from my tax record and driving license, and ... which details have to be kept current by law.
I would prefer governments to solve it with competent Software Engineers in the mix and maybe other professionals from the finances and IT security industries, but never one single large entity.
I didn't take that as he wanted legislative representatives and the like to solve it, so much as to make it a matter of focus to enlist the kinds of people you're recommending to provide a solution like this.
Personally, I really feel we need a private/public-key kind of system in place for certain things like Social Security Numbers (SSNs) in the US. Such that if a leak also includes an SSN (essentially a public key), it could then be regenerated and some apparatus to manage filtering it to the parties it was assigned to prevent needing to redistribute it manually as a consumer/user (like using your Google, Facebook, or whatever OpenID as credentials for another site and it is stored in the account showing that it is being used as such). If they could automatically detect said public keys being exposed and automate the resetting and distribution process, even better (users should still be able to manually do it if they feel it is compromised though).
SSN should be just an unique number per person, nothing more, nothing less, never used for identification, only for having an unique number per person. It's impossible to ensure such a number doesn't leak so there also must be 0 consequences in that happening. That would require major legislative change.
Of course. There are plenty of different ways to build such a platform (or contract it out) - I'm not advocating any in particular.
The UK has a rather interesting example in the GOV.UK Verify service, which federates the identity verification and authentication out to third parties. The user can then choose which provider (e.g. Barclays, Post Office) they want to prove their identity through. Experian is also one of the providers, which perhaps illustrates some of the flaws with this design...
In this case, the solution is easy. The user most likely already has an account, so just ask for the account password. If the users claims they lost the password, then do a classic password recovery via email.
Of course it's tricky for organizations storing data about users without an account. (eg. Facebook or Google, not sure how they could handle that at all, even with government ids)
The only way to do what most people want here is to bake this digital identity into humans, which is beyond our present technology and also feels potentially rather like a recipe for authoritarianism. For one thing, if you can lose it, people will. They'll destroy them on purpose, they'll be stolen by crooks, they will forget them at airports or in hotel safes. That's not a problem for baked in things, people don't leave their hearts behind (outside of Country songs) or (outside of maybe China) get them stolen by crooks but any conceivable device, card, key, or document will have this problem.
Greg Egan's "Orphanogensis" (http://www.gregegan.net/DIASPORA/01/Orphanogenesis.html a short story setting up the protagonist for his novel "Diaspora") describes making Polis Citizens (people who exist only as software, the other branches of humanity have given themselves bodies suitable for long term existence in space, the Gleisner Robots, or given up on consciousness altogether, the Dream Apes) with a cypherclerk, a component that does public key crypto. Once the system achieves confidence that the process of making a new citizen has been successful and has produced a conscious person, the cypherclerk is initialised and the new citizen has a unique and impossible to fake proof of ID. This plays no major role in the story, it's just there because presumably Greg agrees with you that it'd sure be convenient if there was actually digital ID. But there isn't.
Here's a central conflict: I would like to be able to prove that I'm who I say I am, but without being stuck with that identity. This makes the identity disclaimable. You will find plenty of people who feel the same way, and some of them have very concrete practical reasons (e.g. people with stalkers or who ratted on a crime boss). But for a bunch of things people, and especially governments want to do with a digital ID that's no good.
A disclaimable ID can work for a driving license. Barry Shitpeas is licensed to drive an HGV, you can either prove you're Barry Shitpeas, or you can get a new license to drive the HGV with the identity you do want to use.
But if Barry drink drives, taking away his license, knowing he can just get a new one as Jerry Poocabbage tomorrow, well that's a rubbish outcome, isn't it? We want a way to _stop_ Barry from driving even if he changes identity. And we can't do that with disclaimable ID.
In my opinion, we need an open protocol for this. Every government having a separate digital identification tool is a poor solution.
The simplest solution I can imagine is to mimic the solution used to digitally identify companies via HTTPS (certificate authorities), but modified with the intent of identifying a person rather than a company.
I have never used it, but I do get the impression that Estonia is pretty far ahead of everyone else. I don't know if this particular use case is natively supported (but would be interested to know). I suppose it would be possible for a third party to build it.
Latvia also has ID cards with embedded certificates that can be used to sign documents/login. These cards are optional (passport is mandatory, ID card can be requested) for now but will be required from 2023. Estonia/Latvia/Lithuania also have SmartID (although this is a private company service) which is an app on your mobile device and is used for logging in banks. SmartID account is issued by the bank (lowest level, can only log in issuer bank) or by yourself using your ID card (highest level, can log in any service that supports SmartID as well as document signing).
The person you replied to is pretty much right, Estonian ID-card has solved 99.99% of authentication and signing problems for it's citizens, the support is mandated by law and very widespread. There are a few flaws but those are minor compared to the softly put clusterfuck rest of the world is dealing with.
I'd rather not start compiling a list of password-username database thefts, credential stuffings, identity thefts, forged paper signatures, the time lost to inefficient paper procedures, secrets stolen due to how hard it is to encrypt things etc. etc. etc.
Of course we have to be disciplined, but other things can't even remotely reach the security such a solution provides. Your comment has very FUD-y undertones, rising concern about a very minor thing if you actually look at how much it solves and how much better it is compared to other widespread applications.
I'm extremely enthusiastic about smartcards, even trying to build a startup around making it easier to deploy and build services around smartcard-based authentication and key management. I agree that in terms of overall security they're incomparable to the existing mess. But, fair point--I flubbed attempting to articulate a tangentially related concern.
Yes. A lot of Estonians use it daily to log in to their bank accounts, give digital signatures, deal with government business, check their health data etc. All you need is your ID card and your PIN codes.
It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5.
It also doesn't support anyway to delegate access, either to people ("my partner should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").
Not to mention that all providers of Mobile Bank ID (which, as you mentioned, is by far the most widely supported one) are private companies, mostly banks, which have no duty to take you on as a customer.
If you for whatever reason can't or won't get an account with a Swedish bank, you're effectively cut out from large parts of online services.
I really think the government needs to realize they should provide ID issuance digitally to ensure that no one is left out.
The rest of your post does not back up this claim IMO.
> It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5.
At least here in Norway you can get a standalone hardware 2-factor key.
> It also doesn't support anyway to delegate access, either to people ("my partner should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").
I will happily admit banks aren't too good with this, but it isn't BankIDs fault.
BankID only handles authentication. Once I'm logged in I can easily delegate access to my account using my banks self service feature. If your bank doesn't let you it is their fault.
As for why it cannot be used by a machine I guess the reason is that use of BankID is considered the same as signature. So signing with someone elses BankID is considere forgery.
> You can get the key embedded on a smartcard, but it's still coupled to their proprietary driver (which only works on Windows or macOS, of course).
Maybe it is different where you live but the standalone hardware key I mention is standalone: You open the website, enter your national id, find your token generator, enter pin code for hardware token, read your token, type it into the bank web site, and enter your password ib a different field.
Nothing of this is linked to Windows or Mac, only to a reasonably modern browser.
And the thing you describe seems to be very very different and I'm confident there's only one BankID product in the Nordic countries, so either it is implemented in a very different way with your bank or we aren't talking about the same thing.
> It's also a separate API and not as widely supported as Mobile BankID.
Around here hardware tokens were supported before mobile BankID was even a thing. They are still available everywhere I log in.
---
As for why I care, I find that BankID is a good idea, reasonably implemented, so I don't think it is OK to trash it - unless I'm misunderstanding something, in which case I want to learn.
> Maybe it is different where you live but the standalone hardware key I mention is standalone: You open the website, enter your national id, find your token generator, enter pin code for hardware token, read your token, type it into the bank web site, and enter your password ib a different field.
That sounds completely different. "BankID På Kort" is basically the same experience as using an OpenPGP smartcard: it prompts you to insert the card, enter your PIN, and everything else is handled in the background.
Many banks here (and at least Nordea used the CC for this) also support manual challenge/response auth like you describe, but this is unrelated to BankID and seems to generally be considered deprecated.
> And the thing you describe seems to be very very different and I'm confident there's only one BankID product in the Nordic countries, so either it is implemented in a very different way with your bank or we aren't talking about the same thing.
From what I can tell, Swedish and Norwegian BankID are completely separate. NorBankID seems to be operated by Vipps[0] (a consortium of norwegian banks) and have existed since 2004, while SweBankID is owned by Finansiell ID-Teknik[1] (a consortium of swedish banks) since 2002.
They also don't share the logo, or seem to have any ties between their websites.
> Around here hardware tokens were supported before mobile BankID was even a thing. They are still available everywhere I log in.
Each bank generally had their own hardware tokens since before BankID (and still do).
Government services usually also support Telia's NetID (which is similar to BankID På Kort, but at least seems to provide a Linux driver).
However, BankID is also starting to become popular for services that would otherwise have been fine with plain old username/password authentication, rather than implementing U2F or TOTP. These services usually don't put a lot of thought into their implementation, and don't tend to implement alternative auth methods. Older services will support username/password for existing users, but expect it to be considered deprecated. Examples of this category would be Hallon (mobile network), Hemfrid (home cleaning service), or Kivra (crappy email without the federation).
> As for why I care, I find that BankID is a good idea, reasonably implemented, so I don't think it is OK to trash it
> That sounds completely different. "BankID På Kort" is basically the same experience as using an OpenPGP smartcard: it prompts you to insert the card, enter your PIN, and everything else is handled in the background.
Agreed, sounds completely different. We had some smartcard id system here as well, but last time I saw any of that in practical use for banking was 10 or so years ago, and even then it was standalone (battery driven, small enough to fit in my pocket) and not dependent on a PC with proprietary OS.
> Many banks here (and at least Nordea used the CC for this) also support manual challenge/response auth like you describe, but this is unrelated to BankID and seems to generally be considered deprecated.
I see. Around here this is official from BankID and it seems you need a "proper" physical BankID to even log into hour bank to issue a mobile BankID[0].
> From what I can tell, Swedish and Norwegian BankID are completely separate. NorBankID seems to be operated by Vipps [...] and have existed since 2004, while SweBankID is owned by Finansiell ID-Teknik[...]since 2002.
The Vipps situation might be a bit confusing, Vipps wasnt created until a few years ago but it is more or less universally loved by everyone, so it seems they have used that name to cover everything.
>They also don't share the logo, or seem to have any ties between their websites.
You are right. Good point. I'm not sure anymore that they are related.
> Government services usually also support Telia's NetID (which is similar to BankID På Kort, but at least seems to provide a Linux driver).
Around here the government have their own (MinID), but yu can also use buypass, COMMFIDES, or Norwegian BankID. I never see anyone using anything except MinID or BankID though.
> However, BankID is also starting to become popular for services that would otherwise have been fine with plain old username/password authentication, rather than implementing U2F or TOTP. These services usually don't put a lot of thought into their implementation, and don't tend to implement alternative auth methods. Older services will support username/password for existing users, but expect it to be considered deprecated. Examples of this category would be Hallon (mobile network), Hemfrid (home cleaning service), or Kivra (crappy email without the federation).
With a broken system that by design isn't cross platform like you describe this seems like a bad idea, yes.
>Don't let decent be the enemy of good.
Agree. That said I find the Norwegian implementation is good now after they got rid of the applets a few years ago, and even back then I was able to somehow get it to work - and it was about as broken on Windows as well ;-)
Today it Just Works across alll devices I use for work as well as at home: Linux laptops, Windows laptops, iPad, Android phone and probably whatever else as long as it has a any modern browser (I use FF mostly, but it seems to work in everything from IE and Edge to Opera and Chrome).
Summarized I guess the Norwegian BankID is good, and the Swedish one is bad?
Ugh, my Austrian bank is currently trying to force me into using a system like this. The "standard" way is via an Android or iOS app, the "alternative" is via a smartcard reader thing that seems to work with Windows only.
They claim that this is mandatory due to some EU regulation, but they conveniently forget to say what regulation that is supposed to be.
> It's the Payment Services Directive (PSD2). Username+PW is obsolete and insecure at least 20 years now.
That does not imply that banks must implement 2FA with their proprietary applications.
Banks could just implement TOTP (Time-based One-time Passwords, RFC 6238) or HOTP (HMAC-based One-time Passwords, RFC 4226) and let me choose how I generate my OTP. For example with an hardware OTP generator or an open source application.
Most banks are using PSD2 as a occasion to force their privacy-invading apps on their users.
Absolutely not, I heavily dislike SmartID and similar proprietary spyware as well. A TOTP HW token would be in my opinion more secure. The reason banks use it though is the convenience, having some identity tied to the apps is just a bonus for them.
You can install it on your PC or Mac instead if you want, and it is not the only e-ID in Sweden (alas the others aren't so widely adopted, but that should change if/when the new government ID happens).
Access delegation not being part of BankID itself is a feature not a deficiency, it would undermine the concept of secure digital ID if someone else could digitally impersonate you with it. Instead, services can choose whether they let you allow someone to log in for you.
> You can install it on your PC or Mac if you want.
1. Same problem. There is still no Linux client, for example.
2. It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there.
3. Many applications are only useful on the go, such as Swish.
> Access delegation not being part of BankID itself is a feature not a deficiency, it would undermine the concept of secure digital ID if someone else could digitally impersonate you with it.
Different kinds of services have different security requirements. If multiple people live together then it makes sense that any of them should be able to send requests to their cleaning service.
There is also already a clear precedent to allow delegation of access that require strong authentication IRL. For example, PostNord allows you to retrieve someone else's mail as long as you provide ID for both yourself and the recipient. You can issue a Fullmakt which authorizes someone to take legally binding actions on your behalf. Hell, you can even vote by delegate.[0]
Why should those rights not extend into the digital world?
> Instead, services can choose whether they let you allow someone to log in for you.
And they don't, because they are lazy and think BankID has magically solved all of their authentication woes.
> It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there.
I'm not sure which point you're referring to with the mention of differing API. Mobile BankID is the same API as regular BankID (but services can choose which they accept); as for other Swedish e-ID services, there are aggregator services.
Re: most, really? There are some that don't accept non-mobile BankID, but it is uncommon in my experience.
> There is also already a clear precedent to allow delegation of access that require strong authentication IRL.
Sure, but what does that have to do with BankID itself? Both in-person and online, it is the service that decides whether someone else can act for you. And various services do offer this: I can let others access my tax records or prescription medicine records online.
I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
> I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
BankID could have designed their API such that "person performing the action" and "subject the action applies to" are different fields.
But even that is unnecesary. Who actually requested the action only concerns the subject, not the third party carrying it out. BankID could simply log "Delegate A requested entity B to perform action C on behalf of subject D" and show it to D, while keeping B completely in the dark.
It would likely be very problematic for the security model as it is crucial that you only sign your own requests that you understand what they do. I guess you can technically sign someone else's request made with your identification number today as most service don't use QR codes for presence verification. In general I am also not sure that further expanding, and blurring the line, of what you can do with BankID is a good idea. If anything I would like more limits.
> There is also already a clear precedent to allow delegation of access that require strong authentication IRL. For example, PostNord allows you to retrieve someone else's mail as long as you provide ID for both yourself and the recipient.
They have the same service in their app with BankID + QR code (at least for packages).
It wouldn't work, because services using BankID want a (presumably contractually-obligated) assurance that only that particular person is using the service. If someone else can be authorised use your ID, it undermines that.
They could still add such a feature of course, but they would need to inform and have the co-operation of services when someone else is using the ID, so it wouldn't be widely supported.
Person A initiates and signs request to delegate for Person B. Person B receives the delegation request and signs it, which produces a positive response. The response (containing Person B's signature= is then 'wrapped' in Person A's request and is only sent on the to destination.
>Same problem. There is still no Linux client, for example.
There was[0]. Maybe you can revive it, since it is a pain-point?
>It's a different API.
Having read the BankId specs, they're "different" APIs in only in how the session is initiated. You're still challenged to enter the PIN for the certificate, which prompts the response to the authentication request. In other words, BankId and Mobile Bank Id are presenting the same exact set of data back to the session initiator.
>Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there.
I have, as of yet, to run into anything that would not take BankId or Mobile Bank Id.
> There was[0]. Maybe you can revive it, since it is a pain-point?
No. This is a problem that was intentionally caused by Finansiell ID-teknik, and I'm not going to get into cat-and-mouse game to fix their for-profit product.
> Having read the BankId specs, they're "different" APIs in only in how the session is initiated. You're still challenged to enter the PIN for the certificate, which prompts the response to the authentication request. In other words, BankId and Mobile Bank Id are presenting the same exact set of data back to the session initiator.
They're different in that a service that takes Mobile BankID does not automatically support the desktop version, or vice versa. Whether the API is similar after that doesn't matter.
> I have, as of yet, to run into anything that would not take BankId or Mobile Bank Id.
Off the top of my head, Swish and Hemfrid only accept Mobile BankID, with no alternate authentication options. Swedbank accepts Mobile BankID or their custom OTP hardware token, but not desktop BankID.
>No. This is a problem that was intentionally caused by Finansiell ID-teknik, and I'm not going to get into cat-and-mouse game to fix their for-profit product.
You're - literally - on "Hacker News" complaining about the lack of a product. You were given one that you could easily fix to suit your aforementioned needs/demands and was a principal complaint against BankId but, instead, you want BankId to write the Linux app for you because... ...profits? This makes no sense; especially, when you would already have a hefty baseline of code to work with.
>They're different in that a service that takes Mobile BankID does not automatically support the desktop version, or vice versa.
Does not automatically doesn't - implicitly - mean that it's disallowed. You seem to be confusing the two concepts, here.
>Whether the API is similar after that doesn't matter.
We're - literally - talking about the API being the same because you made it a point that it was different. Either it matters or it doesn't. Pick one.
>Off the top of my head, Swish and Hemfrid only accept Mobile BankID, with no alternate authentication options. Swedbank accepts Mobile BankID or their custom OTP hardware token, but not desktop BankID.
O.k.? We're still in the swamplands of those are problems created by the app developers and not BankId, correct..? I'm not sure I'm following how the app designers' decisions are the fault of BankId...
> You're - literally - on "Hacker News" complaining about the lack of a product. You were given one that you could easily fix to suit your aforementioned needs/demands and was a principal complaint against BankId but, instead, you want BankId to write the Linux app for you because... ...profits? This makes no sense; especially, when you would already have a hefty baseline of code to work with.
That's like saying jailbreaking makes iOS respect the consumer. It's a temporary hack that makes it tolerable to use... for a few days until the next mandatory update comes out and breaks everything again.
You won't get lasting improvement without changing the mindset of the powers that be.
> Does not automatically doesn't - implicitly - mean that it's disallowed. You seem to be confusing the two concepts, here.
You're saying service developers can put in the work to support both desktop and mobile BankID. I'm saying most of them are lazy and don't bother. Those two statements are not incompatible.
> We're - literally - talking about the API being the same because you made it a point that it was different. Either it matters or it doesn't. Pick one.
Similar and compatible are very different things.
Then again, this whole subdiscussion is irrelevant anyway, because desktop BankID is still crap for the same reasons as Mobile BankID.
> O.k.? We're still in the swamplands of those are problems created by the app developers and not BankId, correct..? I'm not sure I'm following how the app designers' decisions are the fault of BankId...
If BankID had spent more than two seconds designing their API boundaries then the app developers wouldn't have had to care about supporting both in the first place.
>You won't get lasting improvement without changing the mindset of the powers that be.
I'm confused: Do you believe that whining about it on HN will accomplish that?
>You're saying service developers can put in the work to support both desktop and mobile BankID. I'm saying most of them are lazy and don't bother. Those two statements are not incompatible.
I am, am I? I thought I was saying that you're being assumptive because that's actually what I was saying: You're equating a potential to an emphatic and it doesn't work that way.
>Similar and compatible are very different things.
Now you're just being obtuse and ignoring the entire premise that they're the same - much less have you decidedly chosen whether it matters or not.
>Then again, this whole subdiscussion is irrelevant anyway...
Then why are you replying to it? I think she doth protest too much!
>If BankID had spent more than two seconds designing their API boundaries then the app developers wouldn't have had to care about supporting both in the first place.
According to you, they did design their API boundaries because they're "different APIs". As a byproduct, they must've spent more than two-second designing it to accomplish that, yeah?
The mental gymnastics you're performing must be tiring. I feel for you, I really do.
I do have to concede that you are correct in one point: The whole sub-discussion is irrelevant, namely because your opinion is obviously in the minority and you can't maintain a static viewpoint on anything so far - except to say "bankid sucks"; which isn't substantive.
If you ever change your mind about fixing your problem, I believe this might help in that endeavour:
Nordea requires Mobile BankID to log into their online banking, but they also let you log in with a card reader and do the challenge/response codes thing. I assume desktops/laptops aren't secure enough for their taste.
Handelsbanken allows both. I think the mobile app is pretty static, however, after you sign in with Mobile Bank Id. I still wouldn't call that a "disallow", more of an intentional UI convenience for users that want #easyMode.
However, there remains no easy way to make ad-hoc verifiable statements like 'I am John Smith and I authorise you to send this data to xyz@example.org'.
Governments, please solve this problem! Essentially: combine NemID with Keybase and build a UI that normal citizens can understand.