• PracticeOnNames

• To CAcert.org Education & Training - To CAcert.org Education & Training Overview

• To Assurance Policy - To Assurance Handbook

česky | english

Practice on Names

Currently this is an interpretation based on the Assurance Policy at http://www.cacert.org/policy/AssurancePolicy.php#2.1 to specify more clearly how to match names found in official ID documents with names stored in CAcert accounts.

It is intended to be a bit on the safe side and might be more restrictive as the policy itself. Also the interpretation concentrates on "western names". Though some thought has been given to other regions, it might be not suited well to special situations. If you encounter such a situation, feel free to explain it on the Education mailing list.

Non-policy Notes:

• This probably belongs in the Assurance Policy.

• This needs a linkage from Assurance Handbook that clearly explains what are the rules, how much we can rely on this document. I.e., either this document is acceptable and approved practice in Names variations as per AP, or it is ... not!

• There were some discussions on -policy about this during April which should be considered first. [samj]

• There needs to be a linking into the CPS on how the Names are used.

• This document is now part and included in the Assurance Handbook

General Standard

It is preferred that the name used in the account can be matched exactly to the name as written in at least one government-issued Identity document.

For several reasons some deviations of this preferred standard are accepted.

Basic, Simple, Strict Rules

1. We assure only names, that we can find in at least one ID document.

   • • We assure only names, that we can find in at least one ID document.

2. Its allowed to reduce information, but its prohibited to add information. (The data of the ID documents does not have to be used completely, that is not all given names have to be used and names may be abbreviated under certain circumstances.)

   • • Its allowed to reduce information, but its prohibited to add information.

3. Always document missing names on the CAP. (A person may have multiple names as long as they are verifiable with official ID documents)

   • • Document missing names on the CAP.

4. Transliterations are accepted because of technical reasons (8bit to 7bit conversions)

   • • Transliterations are accepted

5. We use Case-Insensitive

   • • Case-Insensitive

Clarifications

• It is always preferred to have the name(s) in the account exactly like the name(s) in the ID documents.

• Translations of names (Matthew <-> Matthias) are not accepted (Reason: it is too complicated to verify translations)

• Initials of first and middle names are depreciated but accepted (Reason: Rule #2, but this may be open for discussion. Maybe at least one given name should be used completely?)
• Middle names and academic titles may be omitted (Reason: Rule #2)
• Diacritical marks (accents and similar things) may be omitted (Reason: Rule #4)
• If transliteration is used it has to be used on the whole name, result must be 7-bit ASCII (Reason: Otherwise technical reasons are not plausible)
• In general names are handled case insensitively. If usage of different cases is very unusual or could indicate abuse, a dispute should be filed to clarify the specific case.

Examples

Allowed Variations

Forbidden variants

Note: If ID documents for other alphabets also contain the name(s) in Latin characters, like many passports do, these would be acceptable even if not conforming to ISO transliteration rules, because they are contained in official documents.

Practice on Suffix

see Wikipedia Suffix (name)

Suffixes are often a problem and leads into arbitrations, as suffixes mostly not added into ID docs. But this isn't noticed onto the join form

Despite the fact there is a link on the join form, most suffixes cannot be accepted, 'cause they are not listed in any ID docs. So the simple rule here is: prevent adding suffixes and only accept suffixes you may find in at least one ID doc.

If you find a suffix in the online account, ask the assuree, to correct his name in the online account or if once received assurance points, ask Assuree to file a dispute.

• read also: Potential precedent case: a20110119.1 (... to process name change requests which are transitions satisfying the requirements of PracticeOnNames.)

Relaxed Rules

The relaxed rules follows the general strategy as defined at PracticeOnIDChecking - CCA/AP requirements

• Hence, the Assurance Statement goes some distance to detune or soften the need for pure identity documents ... as long as we can reliably get the guy to Arbitration, the precise Name and Documents matter less.

Top Down Procedure to handle Strict and Relaxed Rules

• 1.	First check on Strict Rules	Can case be handled under Strict Rules?	Pass, otherwise continue 2.
  2.	Second, check on Relaxed Rules	Can case be handled under Relaxed Rules?	Pass, otherwise continue 3.
  3.	File Dispute	Bring case before an Arbitrator	Await ruling

Relaxed Rules: Extended Assurers task

All cases that ends with Not Passed have to be passed to Arbitration or to the Assurance team for a review. Follow the simple rule: document all Names you've read an ID doc, and all names of all the ID docs you've get presented (e.g. use backside of the CAP form)

• One of the requirement to allow relaxed rules is the quality in documentation by the assurers. In case of an arbitration, the Arbitrator can request required infos from the Assurer. If documentation is missing or is incomplete, the Assurer and CAcert has a problem.

Hyphen Rule

For the purposes of checking the Name against PoN, a hyphen in given names is to be treated as OPTIONAL.

The reasons for this are detailed in the Arbitration Precedents Case a20100302.1.

Since, in contrary to other countries, German custom and practice considers the hyphen as an essential part which connects two given names to one single name, German members are advised to use names in their account accordingly.

But since it is not possible for Assurers to verify every aspect of name customs it is considered acceptable to leave out the hyphen and treat two hyphenated names as different names if the member insists on it.

So acceptable variants are:

Note: CAcert can not and will not enforce every aspects of national laws and customs.

• (from a20100302.1)

Further I rule, to add this sample into the PracticeOnNames as a default rule, to make the usage of hyphen in Givennames optional:

• For the purposes of checking the Name against PoN, a hyphen in given names is to be treated as optional.
  
  Although under some codes of law and naming customs the hyphen is considered non-optional,
  it is optional under common-law tradition (cacert's family of law), and our global
  community has many customs. These influences push us to be more inclusive than
  restrictive in naming practices. 

Principle regarding Assurance Statement is:

• a) select the law under which Assuree / Assurer agrees to check the name local law or common law
  b) dependent on the law, the Assurer has to give his Assurance Statement
     Assurer has to accept Assuree's decision but Assurer gives his
     Assurance Statement. In mind, that the full name as seen in users
     IdDoxs is documented onto the CAP form, it doesn't causes to decrease
     Assurance points as it fulfills the requirements for AP and Arbitration
     if the Assurer has confidence into the members identity.

So acceptable variants are:

Note: CAcert can not and will not enforce every aspects of national laws and customs.

Country variations

Note the Arbitration precedent set in a20120115.2 allows for most, if not all, of the known country variations listed below - however that listing is retained as it contains useful reference material for those from outside the countries concerned.

regarding AP 2.2. Multiple Names and variations

The Known Country Variations section gives advice to the Assurers, how they can handle Names according to the descriptions given in each individual section

Known Country Variations:

• NL

  • Tussenvoegsels

  • a20090618.12 Abbreviations on given names are allowed under the given circumstances (read ruling of case a20090618.12) advanced by ruling a20091128.2

  • Nederlandse Voornamen Databank

    • • To the Assurers:

      • Starting 2009 with the ATE's Assurers learned to allow only such names in Account that match the ID docs (strictly). However, as the name rules are in flux, the Dutch "roepnaam" problem hasn't been investigated deeply before the first dispute filings started. Since the ruling of precedents case a20090618.12 new infos received the Assurance Officer and also the Arbitrators about an existing Nederlandse Voornamen Databank. So on any doubt also international Assurers can check Dutch common short name variations against the name found in the ID doc. But consider, this rule is no clearance for general Nicknames. Like me, my given name is Ulrich. This is every time a problem for people from Anglo-American culture to speak, so I moved to the "Rufname" or "roepnaam": Uli. This is to read as a Nickname, because

        1. it doesn't follow the Dutch common short name variation (country variation, that is allowed under AP 2.2), from the Nederlandse Voornamen Databank: Ulrich relates to Oldrik

        2. I'm not a citizen from the Netherlands, so the Dutch country variation doesn't apply

  • ij vs. y (digraph) - Y is a known common substitution in the dutch language for IJ (see references Netherlands Language and Languages (Alphabetical Order) and http://en.wikipedia.org/wiki/IJ_(digraph)) (added 2011-02-07 by AO).

    • Definition: In the Dutch language, the letter combination ij is considered a single letter. It has the same value as y, and it is usually alphabetized as if it were a y.

    • (see also: Indonesian place name spelling issues)

• BE

  • As Belgium is bilingual you have to decide whether you are dealing with a Flemish firstname "roepnaam" then see the Netherland country variations. If you are dealing with French first names see the French country variations.
    Please contact Assurance Officer if you have further details so we can update these infos.

• China

  • Personal names in Chinese culture follow a number of conventions different from those of personal names in Western cultures. Most noticeably, a Chinese name is written with the family name first and the given name next, therefore "John-Paul Smith" as a Chinese name would be "Smith John-Paul". For instance, the basketball player Yao Ming should be addressed as "Mr. Yao", not "Mr. Ming".

  • To prevent missusage, a Chinese name has to be entered into the online system as defined:
    • Givenname(s) into the Givenname and/or Middlenames field(s)
    • Lastname / Surname into the Lastname field
  • Please mark on your CAP form, which Name part is the Givenname and which Name part is the Lastname as read in an ID doc
  • The resulting Names line has to be read: Givenname(s) Lastname
  • If this doesn't happen in the online form, you cannot finish the Assurance, and the Assuree has to correct his name in the Online Account
  • By transferring the Assurance from the CAP form to the Online form, and you read the names switched around, ask the Assuree to correct his name in his Online account or file a dispute for name correction (Givenname / Lastname switched around case)

  • Further readings about Chinese names: http://en.wikipedia.org/wiki/Chinese_name

• Spain

  • Naming System in Spain (also covers hyphenations)

    • Nominal conjunctions are optional. Nominal conjunctions are for better identification of surnames from other name parts. ID docs probably drops nominal conjunctions.

      • The particle “de” (from)
      • The particle “y” (and) (also i, e)
    • Though Spanish people generally have two surnames, one surname (generally the paternal) is sufficient. Portuguese people have up to four surnames, here again one is sufficient.
• FR
  • In French culture, the fullname is often written

    •     LASTNAME, Givenname1, Givenname2, .., GivennameN

  • To prevent missusage, a French name has to be entered into the online system as defined:
    • Givenname(s) into the Givenname and/or Middlenames field(s)
    • Lastname / Surname into the Lastname field
  • The resulting Names line has to be read: Givenname(s) Lastname
  • If this doesn't happen in the online form, you cannot finish the Assurance, and the Assuree has to correct his name in the Online Account
  • If a name is written as LASTNAME, Givenname on the CAP form, the Givenname and Lastname part are identifiable as this is a known definition on writing names.
  • But this format is prohibited in the Online form
  • By transferring the Assurance from the CAP form to the Online form, and you read the LASTNAME, Givenname variant, ask the Assuree to correct his name in his Online account or file a dispute for name correction (Givenname / Lastname switched around case)
• GR

  • Deliberations on Greek givenname variations can be found under a20091231.2

  • So there is a known list (may be incomplete) of common Greek givenname variations that are optional

    1. Γεώργιος/Γιώργος -> Geōrgios/George

       • Greek version of Wikipedia: Geōrgios/George

    2. Ιωάννης/Γιάννης -> Ioannis/Giannis/John

       • Greek version of Wikipedia: Ioannis/Giannis/John

       • http://en.wikipedia.org/wiki/John_%28given_name%29

    3. Μιχαήλ/Μιχάλης -> Michael/Michalis

       • Greek version of Wikipedia: Michael/Michalis

       • http://en.wikipedia.org/wiki/Michael

    4. Ηρακλής -> Iraklis/Hercules

    5. Θεόδωρος -> Theodoros/Theodore

       • http://en.wikipedia.org/wiki/Theodore_%28name%29

    6. Αλέξανδρος -> Alexandros/Alexander

       • http://en.wikipedia.org/wiki/Alexander

       • and I am sure there are many more examples...Γεώργιος and Ιωάννης are the two most common greek male names though.

    7. Νικόλαος -> Nikolaos/Nicholas/Nikolas

       • http://en.wikipedia.org/wiki/Nicholas

• Indonesia

  • http://en.wikipedia.org/wiki/Indonesian_names

  • There are a couple of Indonesian name variations known. However mononyms cannot be entered into the online system yet, as the system requires givenname + lastname to be entered and prevents mononyms (givenname or lastname only)

  • This issue is currently WIP in Software-Assessment and Policy Group
  • Please contact Assurance team until this problem is solved for further directions

Discussion

CPS / CN

This discussion is about Assurance: matching ID documents with the names recorded in a CAcert account. What it is not about, or is less about, is what Name (if any) goes into the CN of certificates.

We will need a linking statement in the CPS that states how the names are used. Something like:

• Any Name assured to 50 points by the Assurance process may be issued in the CN of a member's certificate
• Assurance Policy may provide methods for variations for Names in the CN, such as transliterations and short forms.

Just a suggestion.

Irish Country Variation

• 3 potential variants for one name
  1. O'Reilly
  2. O Reilly
  3. OReilly

     • source: The OReilly Factor

English Language short forms of names

Applies to UK, US, AU, NZ, CA and possibly others
There is a whole set of commonly used and standard "short forms" of English forenames. Examples include "Bill" for "William" and "Dick" for "Richard". (see http://en.wiktionary.org/wiki/Appendix:English_given_names and http://www2.elc.polyu.edu.hk/CILL/namesmatching.htm.) These names are often used by an individual in preference to their formal names (eg "Bill Gates". At least one example is currently awaiting arbiration and a past arbitration has ruled that short forms of names are allowable under AP 2.2 a20090618.2

I believe that it is worth adding a (non-exclusive) list of names and associated short forms that are allowable under relaxed rules for name matching purposes. Currently the example "Bill Gates" for "William Gates" is specifically not allowed under "Strict" rules but it is not clear whether this would (or should!) be allowable under "relaxed" rules x¹)- I personally believe that it should be allowable but (particularly for people who are not native English speakers) clarification would help! Alex Robertson

• u60 - x¹) read "Top Down Procedure to handle Strict and Relaxed Rules"

Advantages and Disadvantages

From former discussion about Relaxed or Strict Rules

• Ruleset	Advantages:	Disadvantages:
  Strict	* supports possible objective of exporting identity documents to net * supports possible objective of asserting a "r.i.g.h.t" to a name	* Does not reflect current practice, therefore: * handling of legacy accounts has to be defined * problem to educate existing assurers, because it is stricter than some government-standard practices (e.g., Germany) * Many problems in details have to be addressed
  Ruleset	Advantages:	Disadvantages:
  Relaxed	* supports possible objective of helping members to use certs	* Simplifies creation of multiple assured accounts for the same user * Assurers have to be educated about "official CAcert" rules of transliteration * Rules are more complicated (at least at first glance...)

Further readings

http://en.wikipedia.org/wiki/Transliteration

http://en.wikipedia.org/wiki/List_of_personal_naming_conventions and http://en.wikipedia.org/wiki/Family_name for some background about personal names.

Arbitration Case a20090618.12: An example of an accepted country variation.

• CategoryAssurance