Looks like I spoke too soon. The specification massively contradicts itself. 3.4.2 requires reissuance every three months, and requires that it issue 30 attestations at a time, and that they be single-use.
That part is architecturally correct, though allowing access to only 30 adult sites per three months is dubious.
Those are minimums, not maximums. Devices should request new certs when they get low. Also, the three-month period is driven by expiration times. It sounds like the EU has decided they want to enforce a maximum expiration time of three months, though I think most countries I've talked to were planning monthly expirations.
And, BTW, this structure is inherited from the ISO 18013-5 security design, which I created (others contributed refinements, and the data minimization scheme was inherited from other systems, but the core design was mine). So... I know a little something about it :-)
And if getting a new proof requires a new request at some point, then it becomes possible for the trusted list provider, conspiring with the proof of attestation provider, to cross-correlate the timing of requests and unmask a user with high probability.
If the issuer will collude with the verifier, they can easily and fully unmask the user's identity, because the issuer knows all of the public keys they issued, and to whom. This is a known issue, something we considered for 18013-5 and decided had to be accepted for now. There is cryptography that can solve this problem, but at least back in ~2020 when the design was finalized (a) a lot of it was still too novel and (b) wasn't supported in common hardware. I don't think either of those things have changed, and there's a further complication that there aren't any PQC algorithms with the necessary capabilities, though the existing design can be trivially updated with PQC key agreement and signature algorithms.
So you still have a value that is potentially usable for tracking across multiple websites. It's just a timestamp. I'm not sure if I'm reading what they're saying correctly. If they mean all 30 in a batch have the same value, this is a disaster.
It's really not, because they also have the same value as thousands of others that were issued with the same timestamp. Granted that if the request (as identified by IP) is from a region with low population it will sometimes, maybe, be possible to weakly conclude that two proofs by users with same timestamp might be the same person. But this would be a very weak signal and it still doesn't tell you anything about who that person is. The IP address is a far stronger signal.
It lacks a section on threat models and how it addresses those threats, which is the first thing I'd expect to see.
At this point, I have no idea whether this protects privacy or not. And that's perhaps more disturbing.
At least for 18013-5 there is a detailed threat model, but it's not in the standard because we were told that standards are supposed to say "what", not get bogged down in "why". I'm not sure if the model is published anywhere.