There's an issue with the flow you described; the party requesting verification shouldn't directly interact with the verifying agent (the state) as this leaks to the state the identity of the requesting 3rd party.
The correct flow for preserving anonymity is: the requesting party issues a challenge token to the user -- the token header describes the type of request (>=18yo?) and the token body is completely random(). The user then takes this token and has the challenge verified (signed) on their side, the signed token is then returned to the requester.
This way the state never knows the identity of the challenge issuer.
() Note that this scheme requires good faith on the part of the challenge issuer that the token body is actually random, although it would seem that a simple DH-key mechanism would patch this vulnerability.
I think it is a tradeoff between "everybody can request age verification" and "only state-licensed parties can request age verification". I don't think everybody's ID card should tell anyone if the holder is adult or not, especially wirelessly
The correct flow for preserving anonymity is: the requesting party issues a challenge token to the user -- the token header describes the type of request (>=18yo?) and the token body is completely random(). The user then takes this token and has the challenge verified (signed) on their side, the signed token is then returned to the requester.
This way the state never knows the identity of the challenge issuer.
() Note that this scheme requires good faith on the part of the challenge issuer that the token body is actually random, although it would seem that a simple DH-key mechanism would patch this vulnerability.