Live data from Hacker News

German implementation of eIDAS will require an Apple/Google account to function

bmi.usercontent.opencode.de

331–340 of 674 posts

Re: German implementation of eIDAS will require an Apple/Google account to function

#331
post #214

German implementer here. We have to use some kind of attestation mechanism per the eIDAS implementing acts. That doesn't work without operating system support. The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS). It is simply a matter of where we focus our energy at the moment, not that we don't see the issues.

German citizen here. So why is an implementation going forward when you already know it will not serve all citizens? Why are we not refusing to implement this until we know we can make it work on all devices? Personally I recently switched from an AOSP based android without Google Play to Ubuntu Touch. In the future with better hardware support I will probably switch to postmarketOS.

> Why are we not refusing to implement this until we know we can make it work on all devices?

Simply put: this will never happen. Way too many devices implementations to make this a reality.

Re: German implementation of eIDAS will require an Apple/Google account to function

#332

German implementer here. We have to use some kind of attestation mechanism per the eIDAS implementing acts. That doesn't work without operating system support. The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS). It is simply a matter of where we focus our energy at the moment, not that we don't see the issues.

Tbh, I feel this is stupid. Banks are giving out QR Tan. Optical TAN devices which work with credit cards and it has been going pretty well. Why can eiDAS not have something similar. Distribute hardware tokens. Get rid of dependency on any OS.

Plenty of EU countries have rolled out SmartCards for this exact purpose, some are now adding NFC functionality. Nothing really stops Germany from continuing like that either.

The issue then becomes the UI/UX. If the legal mandate is not strong enough the solution will not gain enough ground. You can see this if you start comparing those countries with an eID rolled out.

Re: German implementation of eIDAS will require an Apple/Google account to function

#333
post #260

Earlier quoted context omitted.

In light of all of these shortcomings with platform attestation, why go with the eIDAS 2 wallet approach at all? eIDAS 1 already solved this with Mobile-ID (SIM-based, no Google/Apple dependency) and Smart-ID (server-side key management with minimal platform reliance). What does the wallet model give you that justifies this level of dependency on two American corporations’ proprietary backends? Especially considering…

SIM-based solutions are on their way out because phones are starting to lose SIM slots. Certifying eSIM implementations to the same EAL level (as Mobile-ID SIMs are) is way way too difficult. At least for one country doing it alone. Smart-ID sucks. It's not truly hardware-backed, it's proprietary and has fundamental flaws like not having a direct link between the site being authenticated to and the authenticating dev…

Agree on Smart-ID but the answer is to fix those flaws, not to replace the entire approach with one that depends on Google Play Integrity verdicts that even the German architects admit they can’t fully trust.

SIM-based solutions on their way out is a non-issue. For eSIM to support that use case, political will only is needed: the EU got Apple to abandon the lightning cable, this is not any different.

Re: German implementation of eIDAS will require an Apple/Google account to function

#334

German implementer here. We have to use some kind of attestation mechanism per the eIDAS implementing acts. That doesn't work without operating system support. The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS). It is simply a matter of where we focus our energy at the moment, not that we don't see the issues.

This is on the stupid side of lazy (again). You'll still be sovereign only at the pleasure of Apple and Google if you submit to their platform as a service crap.

Re: German implementation of eIDAS will require an Apple/Google account to function

#335

Earlier quoted context omitted.

Just a quick question, and sorry if it might have been answered already... why preventing duplication is so important? I know it’s in the spec probably [1], but I can’t figure out the reason. And a suggestion: add external HSM support at least? (e.g. things like NitroKey/YubiKey) [1]: https://eudi.dev/latest/architecture-and-reference-framework... I suppose?

I’ve just had another, completely stupid but not implausible, idea: > a local internal WSCD, which is a component within the User device, such as a SIM, e-SIM, or embedded Secure Element, So you could issue SIM-cards / eSIM profiles that only do signatures and nothing else. The app then connects to such eSIM (and you keep your main SIM/eSIM in another slot). The less stupid variant is, of course, to get mobile operat…

> The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/

It works great. Just keep in mind that newer phones are starting to deprecate physical SIM slots. At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.

Re: German implementation of eIDAS will require an Apple/Google account to function

#337

Earlier quoted context omitted.

> The ability for us as users to lie to the apps is actually essential to preserving our agency. Without that we're screwed, as now to connect ourselves to the fabric of the society we'll need to find and exploit vulnerabilities that are going to be patched as soon as they become public. The same freedom is being abused by malicious actors. Even on Windows (like BlackLotus), but also on pre-infected phones emptying p…

A lot of other freedoms are being abused and always have been, but somehow we don't go and ban kitchen knives, as having them around is valuable. This is a false dichotomy. Systems can be secure and trusted by the user without having to cede control, and some risks are just not worth eliminating. Most importantly - it's the user who needs to know whether their system has been tampered with, not apps.

> but somehow we don't go and ban kitchen knives, as having them around is valuable

Some countries do :) Though I think physical analogies are misleading in a lot of ways here.

> Systems can be secure and trusted by the user without having to cede control, and some risks are just not worth eliminating.

Secure, yes, trustworthy to a random developer looking at your device, no. They're entirely separate concepts.

> Most importantly - it's the user who needs to know whether their system has been tampered with, not apps.

Expecting users to know things does a lot of heavy lifting here.

Re: German implementation of eIDAS will require an Apple/Google account to function

#338
post #333

Earlier quoted context omitted.

SIM-based solutions are on their way out because phones are starting to lose SIM slots. Certifying eSIM implementations to the same EAL level (as Mobile-ID SIMs are) is way way too difficult. At least for one country doing it alone. Smart-ID sucks. It's not truly hardware-backed, it's proprietary and has fundamental flaws like not having a direct link between the site being authenticated to and the authenticating dev…

Agree on Smart-ID but the answer is to fix those flaws, not to replace the entire approach with one that depends on Google Play Integrity verdicts that even the German architects admit they can’t fully trust. SIM-based solutions on their way out is a non-issue. For eSIM to support that use case, political will only is needed: the EU got Apple to abandon the lightning cable, this is not any different.

> Agree on Smart-ID but the answer is to fix those flaws

Fundamentally can't be, it'd be a whole new solution.

> For eSIM to support that use case, political will only is needed: the EU got Apple to abandon the lightning cable, this is not any different.

Mandate every phone vendor to EAL4(+) certify their eSIMs? I'd love to see that, but I'm not sure that's a viable approach to take.

Re: German implementation of eIDAS will require an Apple/Google account to function

#339
post #266
post #260

Earlier quoted context omitted.

In light of all of these shortcomings with platform attestation, why go with the eIDAS 2 wallet approach at all? eIDAS 1 already solved this with Mobile-ID (SIM-based, no Google/Apple dependency) and Smart-ID (server-side key management with minimal platform reliance). What does the wallet model give you that justifies this level of dependency on two American corporations’ proprietary backends? Especially considering…

I’m sorry to lash out at you but I keep getting disappointed in European countries (more precisely the ever disappointing EU commission) all suffering of the NIH syndrome instead of collaborating and learning from each other

There is mothing to be gained politically by doing this. You think you look good if you say “hey, the Poles had this really good idea, how about we do the same”?

Plus, the process is something like:

- we want to do $something

- hire consultants to help us define $something and produce a document

- hire other consultants to write the specs for the project

- launch an RFP

- select a winner

- wait for the implementation to finish

All the proposed solutions will be something paid, ideally made by a really large company to lend it credibility, and with maintenance costs that justify hiring dedicated people for it.

In the end no one gets what they want.

You think if there was any will wouldn’t the whole EU use whatever the Estonians are doing very well?

Re: German implementation of eIDAS will require an Apple/Google account to function

#340

Earlier quoted context omitted.

Look at reference implementation. Maintainers resist removing google dependency for no good apparent reason. An if there is persistence without reason - there is a reason. https://github.com/eu-digital-identity-wallet/eudi-app-andro...

Operate European tech infrastructure without a dependency on America challenge (Impossible) For 99% of smartphone users, you can't get apps onto their phones without Apple and Google signing the app and letting you into their store, and users can't install the app without an Apple/Google account. Why remove a dependency on Google, when you'll still be 100% dependent on Google? Anybody working on "Digital ID" has alre…

Why adding an additional, unnecessary, superficial requirement?

It's not necessary to provide the functionality and enforces the dependency onto he potentially hostile actor (case in point: Microsoft disabling email account of Chief Prosecutor of ICC because US requested so).

It stifles innovation in the future and hurts GrapheneOS right now.

Let me turn the question back at you: why do you think adding unnecessary dependency is better than not adding it?

Does it serve users, governments, service?

Does it anything good for the interested parties or does it only serve Apple, Goggle and the US government?

Post reply on HN