Analyse Difference/Deviation from ICAO 93.3 (part 3)

[Torsten Lodderstedt]

Are there any deviations from ICAO?

[Torsten Lodderstedt]

Kosuke will conduct the analysis

[Kosuke Koiwai]

I checked how each claim in the OIDC specs ([OpenID]/[OpenID-IDA]) is expressed in

• [ICAO-Doc9303-3] - “Doc 9303 Machine Readable Travel Documents Seventh Edition, 2015 Part 3: Specifications Common to all MRTDs” 

  • https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf

• [ICAO-Doc9303-4] - “Doc 9303 Machine Readable Travel Documents Seventh Edition, 2015 Part 4: Specifications for Machine Readable Passports (MRPs) and other TD3 Size MRTDs”

  • https://www.icao.int/publications/Documents/9303_p4_cons_en.pdf

Please note I refer to mainly “VIZ” (Visual Inspection Zone) instead of “MRZ” (Machine Readable Zone).

‌

• Names

  • [OpenID]: given_name, family_name and middle_name

  • [ICAO-Doc9303-3]: Primary Identifier and Secondary Identifier (p4)

    • Primary Identifier “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.”
    • Secondary Identifier “may be the forenames, familiar names, given names, initials, or any other secondary names.”
    • 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.

  • On actual passports in US, DE, GB, JP, CN (from Wikipedia):

    • US, DE, GB: Surname and Given names
    • JP: Surname and Given name (singular)
    • CN: Name (Surname and Given names before biometric passport)

• Nationalities

  • [OpenID-IDA]: nationalities

    • string array representing the user’s nationalities in ICAO 2-letter codes [ICAO-Doc9303], e.g. "US" or "DE". 3-letter codes MAY be used when there is no corresponding ISO 2-letter code, such as "EUE".

  • [ICAO-Doc9303-3]: nationality (p5)

    • shall be represented either by the three-letter code (see Section 5) or in full at the discretion of the issuing State.

• Place of Birth

  • [OpenID-IDA]: place_of_birth

    • country: REQUIRED. [ISO3166-1] Alpha-2 (e.g., DE) or [ISO3166-3]
    • region: State, province, prefecture, or region component. This field might be required in some jurisdictions.
    • locality: REQUIRED. city or other locality

  • [ICAO-Doc9303-3]: Place of Birth (p5)

    • it may be represented by the town, the city, the suburb and/or the state.
    • If the State is included it shall be represented by its ICAO three-letter code (see Section 5) except where no code for the State of Birth exists, in which case the name shall be written in full,

• Salutation

  • [OpenID-IDA]: salutation, title
  • [ICAO-Doc9303-3]: 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. Any prefixes, suffixes or Roman numerals shall be entered in the secondary identifier field. (p4)

• Date of Birth

  • [OpenID]/[OpenID-IDA]: birthdate

    • The year MAY be 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates.

  • [ICAO-Doc9303-4]: Date of birth (p19)

  • cf. [ICAO-Doc9303-3] Unknown date of birth. (p8)

    • Where a date of birth is completely unknown, that data element shall appear in the date format used for dates of birth by the issuing State or organization but with Xs representing unknown elements (numbers and/or letters) of the date.
    • If only part of the date of birth is unknown, only that part (day, month, year) of the date shall be represented by Xs as per the date format used by the issuing State or organization.

• Gender

  • [OpenID]: gender

    • Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.

  • [ICAO-Doc9303-4]: Sex (p19)

    • Sex of the holder, to be specified by use of the single initial commonly used in the language of the State where the document is issued and, if translation into English, French or Spanish is necessary, followed by an oblique and the capital letter F for female, M for male, or X for unspecified.

• Issuer

  • [OpenID-IDA]: issuer
  • [ICAO-Doc9303-3]: Issuing State or organization

• Date of issuance / expiry

  • [OpenID-IDA]: date_of_issuance / date_of_expiry
  • [ICAO-Doc9303-4]: Date of issue / Date of expiry (p15)

• Number

  • [OpenID-IDA]: number
  • [ICAO-Doc9303-4]: Passport Number (p13)

‌

[Torsten Lodderstedt]

Here is my resolution proposal:

• place_of_birth: to be consistent from a RPs perspective, we either need to change birthdate to date_of_birth or place_of_birth to birthplace. Given birthdate is in the market for quite some time, using birthplace seems to be the reasonable choice. This is inline with the feedback in https://bitbucket.org/openid/ekyc-ida/issues/1119/place_of_birth-birthplace
• given_name, family_name and middle_name: replacing this by Primary Identifier and Secondary Identifier seems too drastic and not necessary given the current claims can be used to represent names across countries. It seems the claim “name” could be useful in some countries.
• salutation, title: I would stick to the more fine grain representation then adding this to the secondary identifier/given_name
• gender: value range should be extended to cover unspecified/X as well.
• nationalities: I think we should align with ICAO and change this to nationality (again). I cannot imagine a case where an OP would attest multiple nationalities in the same verified_claims element. I think an OP would have multiple verified_claims objects for different nationalities, since it would need to check different evidence.

‌

[Achim Schlosser]

Feedback in same order:

• place_of_birth: Fully agree, as suggested in #1119
• name-…..: Fully agree, name is already existing claim in OIDC Core - no need to do anything (End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.)
• salutation: Fully agree, to my understanding the inclusion of titles as official part of a name is also very country specific
• Gender - OIDC core currently allows for further extension if needed (“Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.“), so using undefined/X would be no problem. Defining within the standard might be tricky as my gut-feeling would be that this differentiates largely with individual countries. In Germany the formal definition is female/make/divers, might be quite different in other countries.
• nationalities - Its a fair assumption, if a person would have multiple nationalities in terms of eKYC the attestation would be bound to a single one

‌

‌

[Mark Haine]

It seems likely this could now be dealt with by a PR - any volunteers?

‌

[Mark Haine]

Co-chairs decided that this should be closed for two reasons:

1. this is a breaking change and there are implementations already
2. there were no strong opions voiced at WG meetings objecting to this being closed