Noticed some minor typos in annexes 2 and 3.01
and made two changes that affect semantics. Everything is in separate commits, which can be easily squashed/dropped/refactored.
Changes that affect meaning:
Notes:
- The value of the age_over_18, age_over_NN and age_in_years
- attributes, if present, changes whenever the PID User has a
+ attributes, if present, may change whenever the PID User has a
birthday. The value of many other attributes will also change over
time. It is up to the PID Provider to ensure that the above
requirement is complied with.
While age_in_years changes at every birthday, the age_over_NN attributes should not, as that would imply they contain the exact age in years, which would reveal more information than intended.
@@ -194,7 +194,7 @@ Table 1 contains the following information:
| birth_date | Day, month, and year on which the PID User was born. | M | full-date |
| | Please note that the current specification does not yet foresee a solution for the situation when the date of birth of the User is incomplete or unknown. Work is ongoing to find a solution to this scenario, in alignment with current implementation of eIDAS nodes. | | |
| age_over_18 | Attesting whether the PID User is currently an adult (true) or a minor (false). | M | bool |
-| age_over_NN | Additional current age attestations, NN < 18. | O | bool |
+| age_over_NN | Additional current age attestations, NN ≠ 18. | O | bool |
| age_in_years | The current age of the PID User in years. | O | uint |
| age_birth_year | The year when the PID User was born. | O | uint |
| | Please note that the current specification does not yet foresee a solution for the situation when the birth year of the User is unknown. Work is ongoing to find a solution to this scenario, in alignment with current implementation of eIDAS nodes. | | |
@@ -239,7 +239,7 @@ birth of the PID User:
- age_over_18 (mandatory)
-- age_over_NN, NN \<\> 18 (optional)
+- age_over_NN, NN ≠ 18 (optional)
Having multiple attributes instead of only one allows having different
levels of granularity for requests and responses, and thus allows PID
In my opinion age_over_NN can make sense for values of NN both less and greater than 18, hence "≠ 18". This is why I interpreted the second NN <> 18 as the not-equals operator from some programming languages. The intent may however have been both less than OR greater than, which is functionally the same meaning but could be an intentional difference in presentation.
Noticed some minor typos in annexes 2 and 3.01 and made two changes that affect semantics. Everything is in separate commits, which can be easily squashed/dropped/refactored.
Changes that affect meaning:
While age_in_years changes at every birthday, the age_over_NN attributes should not, as that would imply they contain the exact age in years, which would reveal more information than intended.
In my opinion
age_over_NN
can make sense for values of NN both less and greater than 18, hence "≠ 18". This is why I interpreted the secondNN <> 18
as the not-equals operator from some programming languages. The intent may however have been both less than OR greater than, which is functionally the same meaning but could be an intentional difference in presentation.