I fail to see how that solves the problem? That's what I'm saying my service would provide. Unless the eID has some kind of client side rate limiting built in I can generate as many of them as I want. And assuming they are completely privacy preserving no one can tell they were all generated by the same ID.
petu|18 days ago
> Since Proof of Age Attestations are designed for single use, the system must support the issuance of attestations in batches. It is recommended that each batch consist of thirty (30) attestations.
It sounds like application would request batch of time-limited proofs from government server. Proofs gets burned after single use. Whether or not you've used any, app just requests another batch at a set interval (e.g. 30 once a month). So you're rate limited on the backend.
Edit: seems like issuing proofs is not limited to the government, e.g. banks you're client of also can supply you with proofs? (if they want to partake for some reason). I guess that would multiply numbers of proof available to you.
unknown|18 days ago
[deleted]
voxic11|18 days ago
> Relying Party SHALL implement the protocols specified in Annex A for Proof of Age attestation presentation.
> A Relying Party SHOULD implement the Zero-Knowledge Proof verification mechanism specified in Annex A
ongy|18 days ago
If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.
hparadiz|18 days ago