This is far from the best way to do it, but this is a much easier to understand example of how it could be done without having to read about math:

There's a type of token called a JWT that's really common nowadays, which is composed of 3 parts: Metadata describing encryption for the third part, the actual base64-encoded data, and the encrypted signature. The second part would include "is over 18" and "expiration date" to limit reuse/abuse, and is trivially decoded by anyone to confirm there's no personal information in there.

You'd get this token from your government site and copy/paste it into the site needing verification. The government site would provide a standard public key that can be used with the third part of the JWT to confirm it hasn't been tampered with (verification is built-in to JWT libraries). There would only be one public key that rarely changes, allowing the site to cache it, preventing the government site from correlating users based on timestamps - they never see the JWT from the other site (verification is done locally), and the other site would only need to pull the public key once for however many thousands of people use it.

...that said technical issues aside, I kinda feel like this would be the most acceptable version simply because it doesn't require the average user to trust the math - they could go to a JWT-decoding website and look at it themselves.