@warm@kbin.earth @Ladislawgrowlo@lemy.lol @asklemmy@lemmy.ml @SirHaxalot@nord.pub

Depends if the wallet records data of what site required verification.

They have to.

Otherwise, the wallet wouldn't be able to verify whether the website is authorized to request age check (say, if a website asks the wallet's API "Hey, please hand me the age checking token for the email foo@bar.baz which you checked for me some time ago, they're trying to access the gatekept sections of my website again", the wallet needs to be sure that this website did request it previously and is not trying to exfiltrate someone else's data), or the person wouldn't be able to know which sites previously got their age checking data (eventually the users will have lots of websites where they previously had to check their age, and as part of GDPR's "Right to be forgotten", they'd need to be sure which ones they would want to revoke previously handled data).

The Age check authn+authz flow isn't unidirectional (i.e only the wallet handing out the result of age check to a website). In a nutshell, it works this way (at least, it's how I think, as a DevOps formerly accustomed with building APIs for websites, how it would work):

1. User requests to access sensitive ("adult") content from a website.
2. Website requests the user to check their age.
3. User agrees to proceed with age check.
4. Website redirects the user to the governmental wallet
5. The wallet asks for user authentication and/or 2FA ("open the gov app" or something)
6. After authentication and/or 2FA flow within the gov app, the gov app redirects the user to an OAuth endpoint within the original website, alongside a unique token
7. The Oauth endpoint will be invoked by user's browser's request, then the website will check the wallet API if this token is valid.
8. Gov wallet will check if this website previously went through a flow, then will check the requested token and answer "yes" to the website's endpoint.
9. Website redirects the user to the walled-garden they requested initially, storing the token both server-side and, indirectly, in the client-side via the framework session id (things such as PHPID cookie key-value pair which identifies a session_start() for PHP websites)

Notice how both the website and the wallet need to communicate in order to establish the authorization needed for the user to access the website.

Any amount of privacy being eroded is bad.

Yeah... Fully agree. And, sadly, this is becoming "normalcy"... ☹