FWIW, for me docker compose works just fine with podman. I am not sure what kind of additional configuration is needed these days, make sure you are running podman with the socket thing and perhaps set DOCKER_HOST. It's just a client / frontend to an API that podman provides.
I'm not affiliated with the project, just curious.
So there's demo app in the eu-digital-identity-wallet/av-app-android-wallet-ui github repo, I believe this is what's being tested. This is obviously not an app for an end user, it looks more like a template, to be implemented / integrated on the national level.
There's also this controversial requirement for attestation / google play integrity / tpm on the device. That's not implemented in the demo app, in fact the twitter video linked in the article clearly shows security researcher launching a total commander android app with super user privileges.
IMO selling this as an "EU age verification app" by the commission is dishonest.
edit: so in the linked twitter thread, the security researcher is aware that this is demo app. So not only commission here is being dishonest...
> just put Excel inside Winboat or something, but they won't have it
Just curious, is it about different tools / workflow / the new thing to learn (and those are valid reasons!) or are there some technical issues with for example Winboat?
> someone can set up a token-as-a-service to sell tokens on the black market
They can! Singing requires either PIN or finger on the fingerprint, and signed "proof" is valid for like 60 seconds. This whole end-to-end attestation with play integrity is supposed to make setting up token-as-a-service things impractical.
> What's going to stop the government from keeping all the salts they're issuing and then mandating that site operators add the salts to their existing logs?
> How does the math say no
BBS+ signatures. Hashes you receive from the government and hashes you send to the site operator are different and not correlated.
It is literally TLS in a trench coat with some json sprinkled on top.
Where I think we are not in agreement the question of "who to trust" and "for what purposes".
Are you going to trust me when I tell you that I'm over 18 if I provide you with the document signed by my cousin, Honest Ahmed?
Are you going to trust me when I show you the document signed by my government?
(this is the trick question, you don't have a choice, law says you must; there's a list of who you need to trust and for what purposes; like a certificate root store in your browser)
Yes, something in the document is tied to my ID. There's my name in there for example :). I don't have to share that information, because what government signed is a uniquely salted hash of my name and passed the salt to me.
If I choose to share that salt, and provide my name, someone could hash all that information and compare it to the government-issued document to verify if my name really is john smith (or if my claim "I'm over 18" is valid).
If I don't, they have no way of knowing.
> no "routing through the government"
> government is the one providing the documents
I'm also lost. I mean, this is the government issued ID we are talking about, right? How are you expected to get it if not from the government? "Are you over 18" claim is part of that government issued ID.
They don't have to know which sites or when you are visiting, but they do have to issue you the document.
(To be clear, there are also other options, it doesn't have strictly to be government; for example banks around here can provide ID documents - for their clients. There's a list of who is trusted for what https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/...).
> However there's obviously a reason that those are only valid for 30 days instead of indefinitely.
It's the same reason why we prefer tls certificates with short lifespans.
That's where the google play integrity / attestation comes into the effect.
In theory you cannot export your private key from the device (from the secure element), so for each $2 someone would have to quickly unlock their phone, scan code via the app and so on.
Yes we are still talking about attestation from the government for the specific privilege part.
You get your document with fields like "can drive", "is over 18" and so on. It's valid for some time; physical ID is valid for like 10 years and then you have to get a new document, this digital one is valid for lets say 30 days and if it expires you get a new one.
Then you present only those fields you want, when you want, without anyone talking to the government at all. All the other party needs to check is "is the document valid" and "do presented fields match the document". Like checking a tls certificate for a given domain name or purpose.
Strictly speaking there is no "routing through the government" of any information. The government just "issues a certificate" valid for X days without knowledge with whom, how or when you are using it.
> A true zero knowledge ID check with blind signatures
That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.
So someone's id leaks. It happens. In EUDI there are things called "cryptographic accumulators of non-revocation proofs". If your ID leaks it goes into the accumulator. Similar to the certificate revocation lists. During check, you include claims "im over 18" and "my id is not in the accumulator".
This is included in the standard.
This is also (I can only assume) one of the reasons why EUDI wallets require play integrity / attestation / secure element on the device. So your private key won't be easily leaked and no one can steal your ID.
> EU's planned system requires highly invasive age verification
EUDI wallets are connected to your government issued ID. There is no "highly invasive age verification".
We are literally sending a request to our government's server to sign, with their private key, message "this john smith born on 1970-01-01 is aged over 18" + jwt iat. There are 3 claims in there. They are hashed with different salts. This all is signed by the government.
You get it with the salts. When you want to prove you are 18+ you include salt for the "is aged over 18" claim, and the signed document with all the salts and the other side can validate if the document is signed and if your claim matches the document.
No face scanning, no driver license uploading to god-knows-where, no anything.
> to obtain 30 single use, easily trackable tokens that expire after 3 months
This is the fallback mechanism. You are supposed to use bbs+ signatures that are zero knowledge, are computed on the device and so on. It is supposed to provide the "unlinkability". I don't feel competent enough to explain how those work.
> jailbreaking / "prevent tampering"
This is true. The eidas directive requires that secret material lives in a dedicated hardware / secure element. It's really not much different than what a banking app would require.
> You have to blindly trust that the tokens will not be tracked
This is not true, the law requires core apps to be opensource. Polish EUDI wallet has been even decompiled by a youtuber to compare it with sources and check if the rumors about spying are true. So you can check yourself if the app tracks you.
Also we can't have a meaningful discussion without expanding on definition of "tracking".
Can the site owner track you when you verify if you are 18+? Not really, each token is unique, there should be no correlation here.
Can the government track you? No, not alone.
Can the site owner and the government collude to track you? Yes they can! Government can track all salts for your tokens, site can collect all salts, they can compare notes. There are so called policy mitigations currently: audits and requirements for governments to remove salts from memory the moment stuff is issued.
Can they lie? Sure.
Can the site owner and the government collude to track you if you are using bbs+? No. Math says no.
OK so those processes are launched not by systemd, but by dbus itself.
There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.
There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.
> I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.