>...encryption not only can't kill people, it also prevents people from stealing
To be fair, it can also prevent people from being killed in extremely oppressive regimes, just by association with 'x' out-topic (e.g.: the gay community).
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.
To be fair, it can also prevent people from being killed in extremely oppressive regimes, just by association with 'x' out-topic (e.g.: the gay community).