@ominouslemon@sh.itjust.works @linux@lemmy.ml

The git PR specifically mentions a birthDate, a data struct that feels like it could easily be tampered with (therefore, far from “confiável” (trustworthy) as explicitly required by “deverão ser adotados mecanismos confiáveis de verificação de idade” (“trustworthy age checking mechanisms must be adopted”)).

Thinking of age checking as some kind of OAuth flow, one would ideally store the authz token from whatever age checking provider validated the user’s age, instead of some plain data which, depending on the provider, wouldn’t even be handed to the application.

I can sort of imagine the following, hypothetical flow:

1. Human tries to access the system for the first time
2. System asks for human consent to proceed with age checking
3. Human (is compelled to) accept going through age checking shenanigans
4. System redirects human to 3rd-party age checking provider interface (e.g. Persona).
5. Provider proceeds with whatever means necessary for the human to upload ID and/or selfie, who does whatever is required from them by the provider interface.
6. In case of IDs, the provider talks with gov databases (e.g. Receita Federal do Brasil for CPF “Cadastro de Pessoa Física”) in order to attest the validity of the ID. In case of selfie, provider communicates with a facial recognition model/algorithm/platform.
7. Provider gets the information necessary for age-bracketing, appends it to their own DB with a signing hash, then returns the digest of said hash as a token to the system.
8. System receives the authorization payload and confirms with the provider whether it’s a valid token.
9. Provider replies positively, perhaps with some kind of checksum, regarding validity of the token.
10. System stores the token to hand it to whatever subsystem (for OSes, a software; for online platforms such as social media, a module/route) requesting age info.
11. Subsystem allows or denies human access.

Some age checking models (such as EU) seems to be doing a similar thing to what I hypothesized above: the EU Digital Wallet returns a token, instead of PII. A token that can be checked against the Digital Wallet API for validity (theoretically) without disclosing who the user is (in practice, it’d be another, pretty reliable piece of traceable data despite any “anonymity”)

I’m not sure whether a similar thing will be implemented here in Brazil (we got an official gov app, gov.br, which can already be used for “social log-in” by 3rd-party platforms, but I don’t know whether it’s ready for age check provisioning).

As far as I know Brazil and Brazilians, it’s highly likely we’d end up with dependencies on Microsoft or Google services because Brazilian gov can’t help but handing its own sovereignty to US tech corps, which adds to the dystopia.

I must make something very clear: I’m far from agreeing with this dystopia, I deeply despise this whole “age check” thing going on worldwide; I’m just thinking as a DevOps would.