Closed jschlyter closed 3 years ago
I just want to clarify the comment I provided to Martin regarding this issue and how this was handled by both IETF and ETSI in the creation of the Qualified Certificates profile RFC 3739 as well as the ETSI certificate profiles EN 319 412 series.
There was an intense debate on whether all people had a family name or not, and the clear conclusion is that not every person have a family name (surname). However, everyone have a given name.
The conclusion in all of these efforts were therefore to make given name mandatory but surname optional in all cases where a real name is provided.
In my view this is quite simpler than to have a choice between name and the pair (givenName, surname).
In the standards 3739 and 319412 we did have a choice however between pseudonym or givenName/surname. But that choice is not relevant for eHealth certificates.
Or wouldn't it be better to skip the choice and make given name mandatory and family name optional. All persons have a given name, but in some cultures you don't use the family name.
Agree.
Also. What about middle names? Don't we want to have the possibility to represent those. For example, the Swedish defender i Manchester United, Victor Lindelöf Nilsson has two "family" names, but only one can be the family name - the other is seen as a middle name.
That is no longer true in Sweden, you can have the familyname="Lindelöf Nilsson" but you can (for legacy registration) also be on file as middlename=Lindelöf familyname=Nilsson. Middlenames are depreacted for new registrations.
Replying to myself.
Or. Why not simply use the “legal name” for all cases. My registered name/passport name is “Hans Martin Lindström”, and would it benefit anyone to have it split into given name and family name?
Or. Why not simply use the “legal name” for all cases. My registered name/passport name is “Hans Martin Lindström”, and would it benefit anyone from having it split into given name and family name
Agreed. So lets just simplify this to exactly that - one field - legal name.
And then it is down to the memberstates as how they want to populate it. With the advice
The 'Name' field is to contain the legal name of the citizen in a format and order that is most conductive to comparision (by a human) to that data in the human readable section of the citizens identity card.
The reason I put 'human readable' is to avoid the issues with transliteration (where the same characters get translitrated differently depending on nationality).
Dw.
I think we may try to do this more complex than is required.
The names here have the purpose of being able to compare the name in a hcert with the name of the holder of an ID-card/passport or similar.
The natural solution is to provide the two components givenName and surname, as are present in 99,99% of all ID cards and passports. However we can make surname optional for the rare cases where no surname exists.
Is there anything more we need?
Bundling all names in one string is less functional. There are people where it is not obvious which name is the given name and which is the surname such as:
So a unified string is less functional for the general case.
Replying to myself.
Or. Why not simply use the “legal name” for all cases. My registered name/passport name is “Hans Martin Lindström”, and would it benefit anyone to have it split into given name and family name?
FWIW, passports has both "full name", "given names" and "name" as fields.
Replying to myself. Or. Why not simply use the “legal name” for all cases. My registered name/passport name is “Hans Martin Lindström”, and would it benefit anyone to have it split into given name and family name?
FWIW, passports has both "full name", "given names" and "name" as fields.
I've just got a new passport. Actually, I can't find my "full name" anywhere, only the surname and given name(s).
FWIW, passports has both "full name", "given names" and "name" as fields.
Passports have givenName and surname. All entry documents when you travel asks for givenName and surname(family name). This division is very much standardised. Why not just stick with that. The only thing you need to cover all corner cases is to make surname optional (i.e allow a null value).
I think we are jumping to conclusions here.
First - it is very common to limit the value to 10 Arabic nummerals and the 26 capital letters with transliterations. For VISAs, etc, the common advice is to only use the first name or the primary name. And agreed - this is a well known problem for people who use their second names (as defined by the order in their passports) as their main name in daily life. E.g. in Scandinavia.
Likewise in Japan, Korea and China - where the family name is usually written in the first field. Or countries with a primary name where either of the names then becomes a dot or empty.
This is solved in the ICAO guidelines in the VIZ section - were you try to stay close to the visual rendition (Section 3 of https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf)
The ICAO guidelines (section 3.4) are for experts; and state:
The name of the holder is generally represented in two parts; the primary identifier and the secondary identifier. The issuing State or organization shall establish which part of the name is the primary identifier. This may be the family name, the maiden name or the married name, the main name, the surname, and in some cases, the entire name where the holder’s name cannot be divided into two parts. This shall be entered in the field for the primary identifier in the VIZ. It is recommended that upper-case characters be used, except in the case of a prefix, e.g. “von,” “Mc” or “de la,” in which case a mixture of upper and lower case is appropriate. The remaining parts of the name are the secondary identifier. These may be the forenames, familiar names, given names, initials, or any other secondary names. These names shall be written in the field for the secondary identifier in the VIZ. It is recommended that upper-case characters be used throughout. If a single field is used for the name, then the secondary identifier should be separated from the primary identifier by a single comma (,). A comma is not needed if multiple fields are used.
Prefixes and suffixes including titles, professional and academic qualifications, honours, awards, and hereditary status, should not be included in the VIZ. However, if an issuing State or organization considers such a prefix or suffix to be legally part of the name, the prefix or suffix can appear in the VIZ. Numeric characters should not be written in the name fields of the VIZ; however, where the use of numeric characters is a legal naming convention in the issuing State, these should be represented in Roman numerals. Any prefixes, suffixes or Roman numerals shall be entered in the secondary identifier field.
National characters may be used in the VIZ. If the national characters are not Latin-based, a transcription or transliteration into Latin characters shall be provided.
This is markedly different from what goes into the Machine readable segment (section 4.6)
So I would suggest we simply go for the flat name field where needed and allow a gn/fn split where this makes sense.
So I would suggest we simply go for the flat name field where needed and allow a gn/fn split where this makes sense.
Dirk,
Thank you for the elaborate information. Names is a complex issue indeed. My question is: What would happen if (in the absence of a surname) the givenName fileld is treated as the flat name field?
Do you really need a separate flat name attribute?
Do you really need a separate flat name attribute?
Good point - no I guess not. All systems I know that need to parse/handle this purely use this for VIZ - and will generally do a 'concatenate' and fuzzy matching from thereon.
Especially if you add a primary name rule such as with the commonly used period.
Do we have consensus for dropping the full name, adding fn (required) and gn (not required)?
Fine with me
In order to keep the changes small, this PR only addresses the split into n and gn/fn.