> If there is a move in this area, I predict it will come from something like EU regulations on interoperability (we already have rules on Open Banking to some extent) - something to bear in mind next time the EU's approach to regulation is criticised as "anti-tech".
This would actually be really cool! Over here in the Baltics most banks expect you to use SmartID, which admittedly is fine and has some source up on GitHub, even some nice documentation: https://github.com/SK-EID/smart-id-documentation
But more implementations and support for less vendor lock-in is nice, except that in the case of confirming bank authentication/transactions, there's probably a rather serious matter of trust and security at play (made harder by all of the complexity that you have to deal with). That said, if there was a large community effort, I'm sure that the end result would still be good for creating something like that.
> What about my bank? They have >100M users, and with an app/service portal, they'll be required to be "interoperable".
Banks around here (Norway) are required to provide API access because of Eu regulations (yeay EU, sometimes you are a great idea even if I'm happy that we aren't a member) and I can already see accounts from other banks I have used before.
> I also don't want my bank to have an interoperability interface; as an internet plumber, I fully realize the first thing you need to have a blockage is a pipe with something in it.
Couldn't this be used as an argument against every standardization effort?
> This is also why I can’t imagine ever using Plaid/Mint/etc that require my bank credentials just to do minor stuff like make payments or read transactions.
That's the fault of banks. We need open banking, with APIs using OAuth or similar with scopes or some way for per-action/item access.
> with the new security standards (which are good), banks insist on having you install their proprietary app
since you say this, I assume you are in the EU or UK? I've heard that several EU banks offer a second 2FA method besides the app, such as hardware code generator[1]. In the UK, banks are actually required by the regulator to offer at least one method that doesn't require a mobile phone [2].
You could tell your bank "I can't use a smartphone" and they will probably be able to assist you (or, worst case scenario, you could find a bank that can)
> 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.
The downside is that they don't mandate properly secure 2FA, so we have a mishmash of SMS, time-based tokens and whatever else passes for various banks under the regulations.[ß]
> Say for example they do in fact mandate 2FA for all banks. But then all banks rush out various implementations to meet the requirements. Some provide SMS-based solutions which have known security risks, some provide codes that don't lock out, some do everything right but now people who can't get a 2FA app (those who don't have smartphones for example) can't access online banking any more. There are accessibility concerns.
I'm not qualified to speak on this subject, but these are excellent points. Could you expand on any other implementations that sound like a great idea on the surface, but would have limitations? It sounds like accessibility is just one of many concerns. I'm itching to hear more.
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.
> Now, I agree in theory that bank accounts for example may be regarded as “identities”, and it follows that banks could be regarded as “identity providers” (IdPs). But these conceptual models have proved sterile. How many banks in fact see themselves as “identity providers”?
In Poland if you want anything from your government online you need to prove who you are. Easiest way to do that is to get redirected from government website to your bank website and login there then be bounced back to gov website.
Not sure how the system came to be but I'm very glad it's in place.
> Because in the EU [apps] are required after the PSD2 directive mandated "strong" auth requirements.
No. I recently set up an elderly neighbours online banking access. She has a laptop for some clerical work and email, but uses a dumbphone only.
All the bigger banks I have been using offer a hardware device to generate authentication codes. These usually come with some sort of camera (there are multiple systems) that reads a code of the screen and they require a your bank card.
I am sure not all the banks offer this, but it's so much better than some stupid app.
> Do you mean you expect me to give my banking site/app credentials to X?
No no. Over here (Poland), the way this works is that you get a big list of banks, you click on one, get redirected to their site, log in there, complete any 2FA they need you to complete, are given the typical oAuth "this application wants to access this sort of data" consent screen, and then are redirected back if you consent.
This is mostly used for fast online bank transfers, which we often use for online payments instead of credit cards, but there's also a system to use this for ID verification.
> The other aspect is that banks are really good at physical security, but not so great at data security [..snip...] but at least they're modern technology companies that probably hold themselves to higher data security standards than your bank.
Except this doesn't actually improve your banks' security at all, it's only adding another (attractive and high-value) attack surface in addition to any potential vulnerabilities that your financial providers may have.
Maybe the friction would be too much for most users, but I'd be way more likely to try something like this if there was an option to handle the data myself with an export/import process from my financial providers and not have any account credentials shared at all.
> Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode.
I think this is a good authentication model, but it costs money. There is the upfront cost of the physical card, and then the higher cost of lost account recovery. I think that's the turn-off to most banks; they will have to staff a call center that can verify your ID, issue a new card, and then deal with your immediate concerns because you can't access the website. Passwords + security questions are often free, "oh you don't know your password? we'll just email you another one if you remember your first elementary school's name".
At the end of the day, they are allowed to cut costs on critical infrastructure (everyone's money!!) because we have a strong victim blaming culture in the US. If your password is guessed, it's because you're bad at picking passwords, not because passwords are an intrinsically flawed technology. If your money is lost, it's because "it's really cool to have transactions that can't be reversed, you should have done your due diligence". It surprises me that everyone is OK with this.
(Incidentally, the only place where I've seen the option to use cryptographic authentication is on Vanguard. They added it right about the time we were testing security keys / U2F at Google, and they were the administrator of our 401k plans. I think Google strong-armed them into implementing it! Would love it if they did this to some banks ;)
> In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
I have yet to see a bank use login restrictions to make itself more secure. I've been trying to get my bank to offer actual 2FA for years, and their response is that they moved from offering SMS/Email codes to only offering SMS codes.
A bank should not have control over what authenticator app I'm using. Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app. In practice, this is just a way to make it so that DeGoogled devices, Linux devices, etc... won't be able to interact with normal services because they're "less secure". And the companies saying that will be the same ones asking me for authentication over the phone via my mother's maiden name. They don't need this, they're not technically qualified enough to have this level of control over what devices I use.
I honestly don't think attestation should have been part of the spec at all. There is an extremely narrow range of instances where knowing what client/hardware/OS someone is using is justifiable, and in almost all of those instances you should probably be directly controlling the hardware itself (providing a phone for your employees, installing a kernel module, etc...)
And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.
At least today these services all offer websites so I can still log on and use them without installing an app. But with attestation we're moving towards a future where you won't be able to log into your bank unless you own a "supported" Android device or an iPhone, and rooting those devices will mean that you don't have access to online banking services all of the sudden.
The most important thing about a government-level identity system is extreme difficulty of obtaining any identity other than the one you were born with. It seems inevitable in a web of trust that fraud rings would emerge to manufacture identities for those looking to escape debts, criminal convictions, etc by some combination of tricking and bribing people to sign authentications.
>You should be able to use any compatible product/software you like to sign orders to your bank with your private key
I'm not sure you should be able to use, say, a poorly written IE extension on your unpatched Windows XP machine. Something federated would be great, where any manufacturer can technically make something compatible, but it has to meet a FIPS standard or something.
Keys could be generated onboard, and then you upload your public key or something.
We're getting way ahead of ourselves - banks are extremely hesitant to use anything better than secret numbers. I'd rather a shitty 2FA implementation than that.
> Do you mean you expect me to give my banking site/app credentials to X?
In Finland it is common for many online shops to handle payment, and authentication, using a banking account.
You never hand over your actual banking credentials, instead it is something akin to OAUTH2 - so you're at a merchant site and you'll see "Pay with Online BanK" with logos to click for whichever bank you have an account with. Exactly the same as "Login with Google/Github/Facebook/etc".
I changed my name last year, and due to other integrated services many companies automatically updated their records when the change became legal. These kind of integrations seem common and thus far "secure".
> Last time I needed a new token issuer dongle, I had to actually visit the bank and sign stuff.
I'm glad UK banks try to avoid physical dongles because having to go to the bank and sign stuff to get one is not always convenient, not to mention you need to carry around the dongle everywhere, and if you lose it while you're in vacation it's yet more troubles.
Phone 2FA would be good but a bit pointless because the 2FA app is on the phone, and so is the banking app. Personally I'm satisfied with the way UK banks handle security - it's secure, they block suspicious transactions, etc. yet it doesn't get too much in your way.
I don't think UK banks are less competent, it's just a fine balance between usability and security.
In most of my banks in Europe, all but one, I cannot log without using an actual physical 2FA device the bank sent me. One of them, Deutsche Bank, sent me a specific hardware 2FA which works "by itself" (and is protected by a PIN). No password to log in: only the user account ID and that 2FA device.
The others require my Java SmartCard / national ID card to be inserted in a 2FA reader they sent me (it's a standalone reader with its own display: it is not a Java SmartCard reader hooked to the computer).
Do you guys hand out your customers physical 2FA devices?
This would actually be really cool! Over here in the Baltics most banks expect you to use SmartID, which admittedly is fine and has some source up on GitHub, even some nice documentation: https://github.com/SK-EID/smart-id-documentation
But more implementations and support for less vendor lock-in is nice, except that in the case of confirming bank authentication/transactions, there's probably a rather serious matter of trust and security at play (made harder by all of the complexity that you have to deal with). That said, if there was a large community effort, I'm sure that the end result would still be good for creating something like that.
reply