Age group as an optional alternative to birthdate for age verification (userdb: add ageGroup field to JSON user records)

[schrmh]

Component

systemd

Is your feature request related to a problem? Please describe

Basically an additional alternative to #40954, which might appeal a bit more to adults and some institutions. (Separate issue cause I got asked to rather create an issue.)
Reasoning for consideration and some concerns with only supporting birthDate:
#40954 (comment)
(but especially this:) #40954 (comment)

Describe the solution you'd like

Implemented similar to the PR I mentioned.
"adult" could be stored (or -1 for adults if we support putting in actual age to enable access to age-restricted media and we don't want strings due to ambiguity across regions? Range might also be a consideration however or something to support content descriptions.)
(If both birthDate and ageGroup exist then software reading them may prefer birthDate)

Describe alternatives you've considered

• Could also be named "age", "ageClassification", "ageRating" or "ageAccess" if we only want age and -1 (for adult) in there.
• Potential future other software than systemd for taking part in age verification?

[dylanmtaylor]

For context, the laws referenced in #40954 (California AB-1043, Colorado SB26-051, Brazil Lei 15.211/2025) require platforms to determine whether a user is a minor and apply appropriate protections. They don't prescribe a specific technical mechanism. They require that the determination be made.

A few points on how birthDate in #40954 relates to this:

• systemd's birthDate field is a data source, not an age verification mechanism. The actual verification logic lives in consuming software (e.g., the proposed xdg-desktop-portal age verification portal). systemd just stores the date in the user record, the same way it stores realName or emailAddress.

• A self-reported ageGroup string like "adult" would be less useful for compliance than a birth date, because it can't be used to compute exact age at a specific point in time. Laws with age thresholds (13, 16, 18) need precision — an "adult" flag doesn't tell you when someone turned 18, and a "teen" flag doesn't tell you whether they're 13 or 17.

• Both birthDate and a hypothetical ageGroup are self-reported and stored locally. Neither constitutes "age verification" in the legal sense on its own — that's the responsibility of the application layer. The user record is just the local data store that applications can query.

• Nothing about birthDate prevents a future ageGroup field from being added alongside it if there's a concrete use case. But that's a separate design discussion with different trade-offs, as noted in userdb: add birthDate field to JSON user records #40954.

[schrmh]

Thanks for the additional context.
My concern is basically that this portal (or whatever) basically will use whatever systemd (due to it being so widely used) can store and if there is only birthDate then this is likely going to be used.
However I would disagree that it would be less useful for compliance to store a age or age group of some sort. If only ageGroup existed then it would of course be cumbersome if a device is owned by a minor and the minor became an adult. But if the user is an adult then we would never need to compute anything anyways and a specific age set might be useful for e. g. devices owned by schools or other care taking associations (when users are always below a specific age).

(There is a lot of discussion in the portals proposal so I will need to read that first before deciding if I comment there.)

[dylanmtaylor]

Thanks for the additional context. My concern is basically that this portal (or whatever) basically will use whatever systemd (due to it being so widely used) can store and if there is only birthDate then this is likely going to be used. However I would disagree that it would be less useful for compliance to store a age or age group of some sort. If only ageGroup existed then it would of course be cumbersome if a device is owned by a minor and the minor became an adult. But if the user is an adult then we would never need to compute anything anyways and a specific age set might be useful for e. g. devices owned by schools (when users are always below a specific age).

(There is a lot of discussion in the portals proposal so I will need to read that first before deciding if I comment there.)

The specific ranges are going to be different per geographic region so the true age will need to be known. The CA one specifically requires an accurate signal indicating:

(1) Whether a user is under 13 years of age.
(2) Whether the user is at least 13 years of age and under 16 years of age.
(3) Whether the user is at least 16 years of age and under 18 years of age.
(4) Whether the user is at least 18 years of age.

[YHNdnzj]

I'm pretty sure we should not add something just for the sake of some compliance. The birthDate is a fact/identify associated with the user, which is generic and suitable for addition to user record. ageGroup is up for different interpretation and out of scope for systemd userdb.

[bartiushenko]

In some nations gender also plays role.

Maybe it should be nation-resrticion group or something?

[dylanmtaylor]

In some nations gender also plays role.

Maybe it should be nation-resrticion group or something?

Gender plays a role on whether you could use a computer and what sites you can access? I don't see us entering another new field, gender, as that's a whole can of worms.

[bartiushenko]

Gender plays a role on whether you could use a computer and what sites you can access?

In Afghanistan, all forms of higher education are not permitted for women. Furthermore, the Taliban have a reputation as gentlemen who are not used to repeating themselves.

In Ukraine women are allowed to marry from 16, men - from 18. On another hand, most men are not allowed to go abroad up to 60 years old etc.

My point is actually that there are no limits of restrictions, we could consider that in some regions national/racial minority could have restrictions and so on.

So I'd prefer something like "US-teen" where US is country code and teen is a group legal in that nation rather then just teen.
Or, even, "us-ca-teen" is California and Alabama have different definition of a teen.

So admin will be responsible for his nation rules, for which he is supposed to be aware of.

[keszybz]

The biggest practical problem with "age group" is that it needs to be regularly updated. As users age, but also as the laws change. This applies even to adults — e.g. do you qualify for reduced fares in public transportation, etc. So practically, we'd have to periodically nag the user "did your category change?". This would be terrible UX. Also, the user would generally be subject to multiple overlapping categorizations at the same time: the age groups, permission to vote, permission to drive, permission to buy alcohol, etc. We can hardly present a spreadsheet for the user to fill out. This determination should be done automatically on the basis if a single answer about the birthday. So it seems that the translation of the actual age into categories should be done dynamically, through some interface that does the appropropriate categorization based on the question and location and current rules in that location.

[dylanmtaylor]

The biggest practical problem with "age group" is that it needs to be regularly updated. As users age, but also as the laws change. This applies even to adults — e.g. do you qualify for reduced fares in public transportation, etc. So practically, we'd have to periodically nag the user "did your category change?". This would be terrible UX. Also, the user would generally be subject to multiple overlapping categorizations at the same time: the age groups, permission to vote, permission to drive, permission to buy alcohol, etc. We can hardly present a spreadsheet for the user to fill out. This determination should be done automatically on the basis if a single answer about the birthday. So it seems that the translation of the actual age into categories should be done dynamically, through some interface that does the appropropriate categorization based on the question and location and current rules in that location.

This is a good point. In some jurisdictions you have to be 21+ to buy cigarettes or alcohol, 25+ to rent a car, etc.

[bartiushenko]

The biggest practical problem with "age group" is that it needs to be regularly updated. As users age, but also as the laws change. This applies even to adults — e.g. do you qualify for reduced fares in public transportation, etc. So practically, we'd have to periodically nag the user "did your category change?"

Well, I used to have quite a hack of users. I could write a script to update relevant ones, if legislature changes.

Thus praying that new version of software will be shipped in time is an issue.
If legislature changes in a month from today - what is the probability that relevant services will be patched/packaged/released... , put aside upgraded on user end?

[dylanmtaylor]

The biggest practical problem with "age group" is that it needs to be regularly updated. As users age, but also as the laws change. This applies even to adults — e.g. do you qualify for reduced fares in public transportation, etc. So practically, we'd have to periodically nag the user "did your category change?"

Well, I used to have quite a hack of users. I could write a script to update relevant ones, if legislature changes.

Thus praying that new version of software will be shipped in time is an issue. If legislature changes in a month from today - what is the probability that relevant services will be patched/packaged , put aside upgraded on user end?

I think the way Apple handles this and David Edmundson is trying to implement in flatpak/xdg-desktop-portal#1922 right now has the service in question query "Does a user's age fall in a range between X and Y?" and the portal will reply true/false. That way the implementation is legislation agnostic.