I’ll start off by saying I’m not super familiar with the EU proposal for digital IDs (other than looking at a few articles here and there), but
I’m not in the EU. The EU proposal is tied specifically to the EU. And without documents that establish physical presence in the EU it makes it hard to interact with EU services. A cert with an email doesn’t have this problem.
There are more problematic cases than “non-EU citizen outside of the EU want to access EU services”. There are always edge cases where there’s a piece of document that establishes the person is legally allowed to be here but is glossed over as an “ID”. Usually, you can present these in person and a human would be able to check it. It’s much harder to convince an automated machine to do so, especially when it isn’t in a drop down list. Which means no digital ID for this person (since the system can’t verify). This is not hypothetical. I have actually encountered this myself outside of the EU. Impossible to submit rental applications, trade-ins at Best buy, rent cloud servers, etc. A verification system backed by multiple non-government entities can alleviate this by 1) only verifying age and 2) verifying age through different methods, sometimes even through human vetting.
Data protection is governed by policy in the EU proposal. Policy can change. It’s a lot harder when something is technically impossible by design. A cert with only an email cannot produce a name in it, even if storage was implemented incorrectly.
My understanding is that while the digital id wallet is supposed to be open source, currently it depends on Google attestation framework and can’t even work on GraphineOS. You don’t run into this problem with a file.
1 & 2: it would work the same as all other EU specific things. You don’t need to comply with GDPR for people outside EU, you wouldn’t need to verify users outside the EU.
3: I don’t know what you mean. It could be easy to modify spec of those certs to include names.
4 You don’t know how this proposition is supposed to work.
In short:
There’re officially approved apps (you can’t just create you implementation arbitrary, but if you implementation meets all standards, you can work to have it approved). Using those apps, your credentials are secured with one (or many, I don’t understand that part) of:
Hardware secure element
Software secure element
External device
Server HSM operated by the provider
Those apps must also use some defined encryption standards.
When you create your app, it needs to be approved by one of the member states.
The app can store all kinds of personal governmental things such as your ID, bank account number, drivers license, etc.
When a service wants to know whether you are 18 or more, you can give them your wallet. The wallet app will show who demands what informations and a reason they put in the request. You can approve or reject the request.
It doesn’t have to be tied to google or anyone other.
Yes, those apps won’t be libre, but (and you don’t need to agree with me) in my opinion this is better than letting people create any implementation they want.
GrapheneOS can create thier implementation, that relies on hardware security chip. Linux distros can create a joint implementation reliant on yubikeys and alternatives.
Response to 1: funny thing is that one of the ID verification issues I specifically had is with Hetzner. They need to do a ID verification, recognizes my address is from Country A outside of the EU, so it goes through a Country A specific verification. Then rejects my ID because it’s a rare form of ID in Country A. I also have an ID for Country B but they won’t recognize it with a Country A address.
Response to 2: I’m specifically referring to people residing in the EU for this one. People in the EU that “slip through the gaps” since their ID is somewhat uncommon, thus getting locked out of digital services since they can’t validate and obtain a digital ID easily.
Response to 3: the counterpoint here is network transport protocols, such as TCP and UDP. At this point, it is no longer possible to build new protocols or modify these protocols because of how entrenched the infrastructure hacks surrounding these protocols are, such that no new protocol header would be possible to get through the Internet without it being dropped by middleboxes. I’m suggesting utilizing this technical moat as a feature here: have a simple proposal spread so wide that it becomes almost impossible or economically unfeasible to switch to something invasive.
My issue with 4 is more about current implementation rather than the proposal. So far, the main (or only functional implementation, I’m not sure) is the one that depends on Google attestation. While this could change, I’m not the biggest fan of trusting something to “policy/proposals”. X509 is robust, has key management sorted out, and doesn’t have this specific issue. While anyone can create a cert, that doesn’t mean the cert is useful if it’s not signed by an approved CA.
I’ll start off by saying I’m not super familiar with the EU proposal for digital IDs (other than looking at a few articles here and there), but
I’m not in the EU. The EU proposal is tied specifically to the EU. And without documents that establish physical presence in the EU it makes it hard to interact with EU services. A cert with an email doesn’t have this problem.
There are more problematic cases than “non-EU citizen outside of the EU want to access EU services”. There are always edge cases where there’s a piece of document that establishes the person is legally allowed to be here but is glossed over as an “ID”. Usually, you can present these in person and a human would be able to check it. It’s much harder to convince an automated machine to do so, especially when it isn’t in a drop down list. Which means no digital ID for this person (since the system can’t verify). This is not hypothetical. I have actually encountered this myself outside of the EU. Impossible to submit rental applications, trade-ins at Best buy, rent cloud servers, etc. A verification system backed by multiple non-government entities can alleviate this by 1) only verifying age and 2) verifying age through different methods, sometimes even through human vetting.
Data protection is governed by policy in the EU proposal. Policy can change. It’s a lot harder when something is technically impossible by design. A cert with only an email cannot produce a name in it, even if storage was implemented incorrectly.
My understanding is that while the digital id wallet is supposed to be open source, currently it depends on Google attestation framework and can’t even work on GraphineOS. You don’t run into this problem with a file.
1 & 2: it would work the same as all other EU specific things. You don’t need to comply with GDPR for people outside EU, you wouldn’t need to verify users outside the EU.
3: I don’t know what you mean. It could be easy to modify spec of those certs to include names.
4 You don’t know how this proposition is supposed to work.
In short:
There’re officially approved apps (you can’t just create you implementation arbitrary, but if you implementation meets all standards, you can work to have it approved). Using those apps, your credentials are secured with one (or many, I don’t understand that part) of:
Those apps must also use some defined encryption standards.
When you create your app, it needs to be approved by one of the member states.
The app can store all kinds of personal governmental things such as your ID, bank account number, drivers license, etc.
When a service wants to know whether you are 18 or more, you can give them your wallet. The wallet app will show who demands what informations and a reason they put in the request. You can approve or reject the request.
It doesn’t have to be tied to google or anyone other.
Yes, those apps won’t be libre, but (and you don’t need to agree with me) in my opinion this is better than letting people create any implementation they want.
GrapheneOS can create thier implementation, that relies on hardware security chip. Linux distros can create a joint implementation reliant on yubikeys and alternatives.
Also, alternatives must remain.
Response to 1: funny thing is that one of the ID verification issues I specifically had is with Hetzner. They need to do a ID verification, recognizes my address is from Country A outside of the EU, so it goes through a Country A specific verification. Then rejects my ID because it’s a rare form of ID in Country A. I also have an ID for Country B but they won’t recognize it with a Country A address.
Response to 2: I’m specifically referring to people residing in the EU for this one. People in the EU that “slip through the gaps” since their ID is somewhat uncommon, thus getting locked out of digital services since they can’t validate and obtain a digital ID easily.
Response to 3: the counterpoint here is network transport protocols, such as TCP and UDP. At this point, it is no longer possible to build new protocols or modify these protocols because of how entrenched the infrastructure hacks surrounding these protocols are, such that no new protocol header would be possible to get through the Internet without it being dropped by middleboxes. I’m suggesting utilizing this technical moat as a feature here: have a simple proposal spread so wide that it becomes almost impossible or economically unfeasible to switch to something invasive.
My issue with 4 is more about current implementation rather than the proposal. So far, the main (or only functional implementation, I’m not sure) is the one that depends on Google attestation. While this could change, I’m not the biggest fan of trusting something to “policy/proposals”. X509 is robust, has key management sorted out, and doesn’t have this specific issue. While anyone can create a cert, that doesn’t mean the cert is useful if it’s not signed by an approved CA.