consider implications of `birth_date` definition from OIDCC

[Joseph Heenan]

The OIDCC definition for birthdate( https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) says:

To represent only the year, YYYY format is allowed. 

I think there’s various implications for ekyc if an OP decides to return this form of birthday without the day/month.

[Mark Haine]

maybe something to highlight for implementers if thay wish to do things like age verification using TC. I guess an implementation copuld clearly state that it is only going to use YYYY-MM-DD. Definitely worth thinking through though.

‌

[Mark Haine]

Options to consider may include:

• State in OIDC4IDA that YYYY format is not permitted
• Use a different claim name with a tighter definition
• Raise an issue against OIDCC and get it changed
• Advise IDP implementers that they may wish to state that they do not support YYYY

‌

[Mark Haine]

suggestion create a new specific birthdate attribiute perhaps birth_day?

suggestion to add birth_year, birth_month, birth_day_of_month

… and maybe raise an issue against OIDCCore just for review if OIDCC is going to be updated at some point

[Kosuke Koiwai]

Although I am leaning towards mandating birthdate be YYYY-MM-DD when used within verified claims, we should note that there are some people who don’t have exact birthdate records.

[Peter Bainbridge-Clayton]

I’d caution against specific attributes for indivual components, as there is then an argument for the same for any other type of date. But there is another aspect to this where the validating source may not have/publish the full date. E.g. there are UK sources where only the year and month are supplied. In such cases is a partial validation ok - and so how is that represented - or is that down to the implementer?

[Mark Haine]

Suggestion from Kai that we need the flexibility inspired thought that writing some implementer considerations might be the best option