age_under_X might also be interesting (e.g., for buying products with a discount for young people).
+1 because in the absence of those standard and ready to use claims some ppl may be tempted to choose to release the actual age.
In a ideal privacy preserving scenario / trust framework the RPs will only be asking for is_eligible_for_X claims, so only metadata about the subject will be released.
Unfortunately regulations around KYC don’t seem to make use of this possibility. In future this privacy aspect may become a hindrance to applications.
Alberto Pulido Moyano
Since this could potentially bring a whole new topic, I would like to share our line of thoughts (Santander) around assertions claims of this type. Let us review our documentation and extract the pieces that could be relevant to you for further analysis.
Since the discussion in the call developed into a „let’s add a query language“ that I support, we need to keep the user experience in mind. For example, expressing an query over a claim is possible, how is the user ask for consent? How is the OP supposed to translate this into human language?
Alberto Pulido Moyano
Adding on top of my previous comment. In order to preserve the ability to not disclose the users actual data whilst completing the verification process, we have created an assertion language to be used in a special claim in the request object (assertion_claims). This allows the RP to ask for verification of information such as email address/telephone number or verifying that a user is over a certain age.
This is an example of a request object using assertion_claims:
In this id_token, after the customer has completed the consenting section, the OP is verifying to the RP that the email and birthdate supplied by the RP, have successfully matched the OP's data, and that the age has been verified to be over 18 years of age.
If necessary we could also provide details about how the available operations are available via discovery, and what is our approach for complex objects assertions and even the way we propose showing the assertions in the consent screens. Maybe worth considering opening another issue not just related to age claim verification.
What about expanding the ‘above threshold' concept? I am saying this as I do not see a huge use cases for the ‘above 18’ confirmation, but it would be useful to have a ‘cash or financial assets in excess of…(AMOUNT)’ confirmation.
We discussed in the call on 26.23, The topic (a query language) is worth a discussion, we will start it after implementers draft 2.
I like the concept of the query language.
One question, in this scheme, RP will send user's email and birthdate to OP before OP authenticates the user (and get her consent.) Does RP get user consent before making this request?
Alberto Pulido Moyano
That particular example could perfectly represent an escenario where RP already has email and date of birth as part of their enrolment (using an OP or directly provided to the RP).
In a subsequent interaction, the user is presented with the option to further validate those details or ask for more details (no need for this assertions). This could be done with a different OP, one that will be presented with a request to assert some of the details the user has provided so far, and ideally with the relevant legal status to assert the details (that’s another topic related with the core of this WG).
As I see it, we are deriving new claims from existing claims:
birthdate → age less than x, age greater than y, …
number_of_fingers → number_of_fingers less than x, … (to stay with the example from the call )
Therefore, we should introduce a syntax that does just that: Describing how to derive claims depending on other claims.
This is also interesting because multiple, independent queries can be made on a single claim (e.g., less than x but greater than y).
We could therefore encode this query in the claim name (similar to language tags) to generate new binary claims.
Since we are not introducing a new claim, “age”, but relying on “birthdate”, we can be more precise in the request. For example, for some cases it might be important to say “was born in 1970 or later”. This could be expressed as follows:
We would need to be careful with the operators to ensure that a good natural-language representation can be found and presented to the user. I am sure that this can be solved.
User consent screen:
Data to be provided:
The number of your nationalities (2)
Your family name (Einstein)
The precise syntax for the operators and values inside the claim names shown here is just a strawman. It could be a strictly limited subset of some other query language, like JSONata, jq, … (strictly limited to facilitate faithful transformation into natural language).
13 - lowest legal age of consent in terms of GDPR (also PG-13 film content in USA and other countries)
15 - Common film, video and game content classification
16 - General age of consent for many purposes including some aspects of health, driving, film, video and game content classification in a number of jurisdictions
18 - Common age for being considered an adult (person can act wholly without parental permission)
21 - Common higher age for access to restricted or licensed goods in some jurisdictions (alcohol, gambling etc)
25 - An “at least” age used to cover all of the above without needing to be that specific, often used for restricted or licensed goods, e.g. alcohol - they looked at least 25 and therefore unlikely to be caught by one of the other age restrictions
60 - An age where some people become entitled to various benefits, services or discounts
65 - Common age where people become entitled to various benefits, services or discounts
75 - Another age where people become entitled to further benefits, services or discounts
I know it's not major, but 19 and 20 are also legal drinking/smoking ages in some jurisdictions
In Germany, with the age of 17 a person can acquire a drivers license and drive a car when supervised. I propose to have this age added to the list.
Just a note from my side regarding implementation: Even if the claims will be separate “ager_over_X” claims, I would still implement a parser to extract the number at the end and do a minimum age calculation based on that. I would still have the claims separately approved by the end user of course. So maybe it would not be necessary to actually limit the possible number values for that claim. The flipside of this claim set would be when they are expected to be listed as supported claims in the discovery response.
In case the value passed for that claim can be resolved by the OP, it will return the claim with that value. In case it does not resolve the value, the claim could be omitted in the response or maybe even reject the request?? (not sure what the behaviour should be here)
This is just an option for this particular case (age verification), for other claims where possible values can not be easily established before hand, this does not make sense.
In terms of driving age of 17 we discarded that from our list for two reasons:
1) you can get the licence at 16, but you are limited to motorcycles under 125cc until you are 17 so for issuance its the over 16 that counts.
2) we excluded ages where there wasn’t a a number of useful use cases (there aren’t many things in the UK that are over 17 other than the driving a car one) or where the proof of age is redundant because the process would gather the date of birth anyway (e.g. for driving licence application or taking a test they must have your actual date of birth).
I discussed this ticket with @Brian Campbell (who is also one of the designated experts of the JWT Claims registry). He came up with a proposal similar but a bit different to the proposal @Alberto Pulido Moyano made. I create PR #42 based on that feedback.
In this case, we will need to add information to the spec on how an OP should handle requests to that same claim but with different values from the same RP. It should not be stored that user gave consent to the at_least_age claim alone, but with the exact value queried for.
good point - I think the OIDC request syntax would allow two occurrences of the same claim in different containers only, i.e. top level in an ID Token and within one or more verified_claims elements.
Do you think having multiple occurrences with different values is a real use case? Otherwise, we may decide to prohibit multiple occurrences.
Actually, this was not my concern. I was referring to the already mentioned privacy concerns that an RP could consecutively query for the same claim with different values to figure out the exact age (year of birth) of an end-user.