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.
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.