There's an easy fix for that: use as an intermediary a service that already knows who you are.
Age verification should involve three parties: you ("the User"), the site that wants to know that you are past a certain age ("the Site"), and the service that actually checks your age by looking at your documents or whatever ("the Service").
Using protocols based on zero-knowledge proofs or blind signatures it is possible to design a protocol whereby (1) all that the Service learns when the User uses them to verify for some site is that the User has asked to verify for somebody but they don't know who, (2) all the Site learns is that the User passed the age check and used the Service to do it, and (3) someone how obtains complete logs of both the Site's age verification communications and the Service's age verification communications cannot figure out how to match them up except by timing.
To elaborate on matching records from the Site and the Service, if for example the Site only had one user sign up in the last month who used the Service for verification and the Service was only asked to participate in one verification that month then you can infer the User's identity.
If the Service is doing lots of verifications for a large number of sites, so during the few seconds that your signup or login at the Site is being processed at the Service there are dozens of other verifications also going on there involving dozens of other sites, then someone who gets records from the Site and the Service gets dozens of people who might have been the one who actually used the Site.
We can make it even harder for someone to match things up. First, we can add random delays between the the User initiating a signup at the Site and the User initiating verification with the Service and between the Service's finishing of that and the User using that result to complete signup. So now someone who obtains signup records from the Site and tries to use timing to match them up to users of the Service will need to look at Service records from a wider interval.
Second, the User's client can make random dummy verification requests at random times. That increases traffic to the Service which helps make it harder in general for timing analysis to work. It also makes it so if someone is trying to figure out who signed up at the Site on a specific time and they find you did a verification in the right timeframe and ask you what you were verifying for you can say you weren't...it must have been one of the random dummy verifications.
Third, there should only be a few providers of the ID checking side of this (the Service). It would probably make the most sense for this to be handled by government, probably be the same departments that issue the ID documents you will be using to prove identity. This helps ensure that they are dealing with a large number of verifications, which is the key to protection against timing attacks.
Age verification should involve three parties: you ("the User"), the site that wants to know that you are past a certain age ("the Site"), and the service that actually checks your age by looking at your documents or whatever ("the Service").
Using protocols based on zero-knowledge proofs or blind signatures it is possible to design a protocol whereby (1) all that the Service learns when the User uses them to verify for some site is that the User has asked to verify for somebody but they don't know who, (2) all the Site learns is that the User passed the age check and used the Service to do it, and (3) someone how obtains complete logs of both the Site's age verification communications and the Service's age verification communications cannot figure out how to match them up except by timing.
To elaborate on matching records from the Site and the Service, if for example the Site only had one user sign up in the last month who used the Service for verification and the Service was only asked to participate in one verification that month then you can infer the User's identity.
If the Service is doing lots of verifications for a large number of sites, so during the few seconds that your signup or login at the Site is being processed at the Service there are dozens of other verifications also going on there involving dozens of other sites, then someone who gets records from the Site and the Service gets dozens of people who might have been the one who actually used the Site.
We can make it even harder for someone to match things up. First, we can add random delays between the the User initiating a signup at the Site and the User initiating verification with the Service and between the Service's finishing of that and the User using that result to complete signup. So now someone who obtains signup records from the Site and tries to use timing to match them up to users of the Service will need to look at Service records from a wider interval.
Second, the User's client can make random dummy verification requests at random times. That increases traffic to the Service which helps make it harder in general for timing analysis to work. It also makes it so if someone is trying to figure out who signed up at the Site on a specific time and they find you did a verification in the right timeframe and ask you what you were verifying for you can say you weren't...it must have been one of the random dummy verifications.
Third, there should only be a few providers of the ID checking side of this (the Service). It would probably make the most sense for this to be handled by government, probably be the same departments that issue the ID documents you will be using to prove identity. This helps ensure that they are dealing with a large number of verifications, which is the key to protection against timing attacks.