id_document is too narrow

[Julian White]

Current evidence type of id_document is defined as:

• id_document: Verification based on any kind of government issued identity document.

This is assuming that an identity document is presented for verification, however in some instances an ID document itself is not used, the user provides a unique reference number (like a civil registration number) and the OP gets the identity data directly from an official registrar to use as the basis of the proof. In many cases an ID document is merely a method of exchanging the information from a state register, its not the source of authority in itself.

Suggest this is instead

• id_evidence: An official identity document or identity register.

‌

[Torsten Lodderstedt]

I‘m not sure Id documents and registration number + registry lookup can be compared.

An ID document is a credential in the sense it is bound to the legitimate holder by biometric traits. The verification process checks the binding of those traits to the holder in addition to checking the integrity and authenticity of the document itself.

My feeling is a reference number + registry lookup is a different kind of evidence.

To facilitate discussion about this topic, may I ask you the describe the typical verification process based on reference numbers, especially how a binding is achieved to a certain user.

[Julian White]

To be fair, they are different, but my point is they are both valid means for identification in various jurisdiction and the spec doesn’t seem to cover them. There’s several ways this is used which might result in a different level of identity assurance.

For example:

• they send the authentication (physical) token to the registered address
• they return a biometric (usually face or fingerprint) from the register for the OP to match with
• the OP sends the biometric to the register with the registration number for the register to match with

‌

‌

[Torsten Lodderstedt]

I see why using id document and registries can be considered similar. It’s like by reference vs by value semantics. I would assume the concrete date to be represented in an assertion will differ. Could you please outline an example using the current syntax? That’s more tangible to talk about.

‌

[Julian White]

Here are examples of the evidence types that are used, I've generalised into some types to make it easier to read and noted some UK specific things:

id_document : passports, ID cards, residence cards. Official physical identity documents.
register: birth register, population register. Official registers of people.
licence: driving licence, pilots licence, security industry licence (UK), police warrant card (UK). Official or regulated licences.
statement: utility statement, bank statement, mortgage statement, loan/credit card statement, tax statement, social security statement. Statements from recognised organisations.
certificate: firearms certificate (UK), birth certificate, adoption certificate, marriage certificate, gender recognition certificate, certified deed poll (UK), education certificate of higher educational, criminal record certificate. Certificates from recognised authorities and organisations.
immigration_document: visa, stateless persons document, asylums seekers application registration card (UK). Official immigration documents.
account: bank account, utility account, credit account. Data about accounts, usually from the issuer or authoritative source.

vouch: attestation or confirmation from a responsible and reliable person/organization. A declaration or affidavit from a trusted person that the user is the person described in the claims.

Example use cases :

• id_document
• register
• id_document + visa
• id_document/immigration_document + licence
• id_document/immigration_document/licence/register + statement/certificate/account
• vouch + statement/account/register/certificate

‌

[Nat Sakimura]

Just FYI.

I tend to delineate

1. I.D. or evidence verification
2. validation of such
3. binding of the verified and validated info to the physical being.

Querying the registry kind of falls into the second bucket.

Re: class 1, 2, etc. EoI standard in NZ gives interesting distinction among the types of evidence. For example, a Passport is good for the identification of the person but a driver’s license is not allowed to be taken as the identification document as most of the information in it is not authoritative - it is just a collaborative source. So, it can be treated as the evidence for the identity being used.

‌

[Julian White]

Looking at the things above they would have details like the following:

id_document:

• type
• document number
• personal number
• issue date
• expiry date
• issuer country
• issuer name

‌

register:

• registration number
• personal number
• country
• region/state/province
• name of register
• authority name
• date of entry
• expiry date

licence: 

• licence number
• country
• region/state/province
• authority name
• authority address
• date of entry
• expiry date

‌

statement:

• account/reference number
• issuer name
• Issuer address
• issue date
• expiry date

‌

certificate: 

• certificate/reference number
• issuer name
• Issuer address
• issue date

‌

immigration_document:

• type
• document number
• personal number
• issue date
• expiry date
• issuer country
• issuer name

‌

account: 

• account/reference number
• issuer name
• Issuer address
• enrolment date

‌

vouch:

• name of voucher
• occupation of voucher
• date of birth of voucher
• address of voucher
• issue date

‌

This could probably be abstracted into a few high level elements:

‌

document: physical or electronic evidence that is given by the user

• type
• reference/document number relating to the evidence
• personal number that relates to the person
• issue date
• expiry date

• issuer

  • Name (of issuer)
  • Country (of issuer)
  • Address (of issuer)

record: electronic evidence obtain from an issuing or authoritative source

• type
• reference/personal number (that relates to the record/person)
• country
• date of entry
• expiry date

• source

  • Name (of source)
  • Country (of source)
  • Address (of source)

‌

The thing that doesn’t fit well into those two is a vouch/referee. This could be a thing in its own right since it’s not really from an established source, or we could generalise source and issuer to allow this by adding ‘occupation’ and explain how to use this in the specification.

[Kosuke Koiwai]

Trying to come up with some use cases and apply above criteria:

‌

1. A user onboards to an online service with a smartphone via eKYC

   • the eKYC process/method was a convention of:

     • the user scans the nfc chip of her/his national ID card
     • the user takes selfie of her/himself
     • the user takes a picture of a utility bill
     • In the server, a face matching AI algorithm (vendor: ABC company, software: XYZ, version: 1.0) calculated and concluded the person and the mugshot data in the nfc matches by 98.9%
     • a company employee checks the picture of the utility bill and concluded that the document is of the user and genuine.

   • the entire set of verification/validation can be serialized as:

     • document : national ID card / ID# / image file / etc…

     • document : utility bill / XX gas / etc..

       • method : (pipp) document verification by human
       • verifier : employee ID / processed date / target documents / etc

     • document : face picture / taken date / etc.

     • record : face matching by machine / target person / target documents / rate of accuracy / processed date / software version / transaction number / etc.

2. A user visits to a bank branch and opens an account

   • the eKYC process/method was a convention of:

     • the user shows her/his national ID card
     • the bank clerk validates the ID and matches against her/his face
     • the ID document is scanned and stored to the system
     • the system checks against national register and/or AML blacklist
     • the bank manager double checks everything is valid and approves for account opening

   • the entire set of verification/validation can be serialized as:

     • document : national ID card / ID# / image file / etc…

       • method : (pipp) document verification by human
       • verifier : employee ID / processed date / target documents / etc..

     • record : match against national register / checked date / etc..

     • record : lookup in AML blacklist / checked date / data source / etc..
     • record : approval by manager / employee ID / approved date / etc..

Similar to what Julian says, if an evidence of verification/validation of by human or machine itself needs to be recorded, the record can't be an attribute of single document and record data type doesn't seem to fit well either.

‌

[Torsten Lodderstedt]

@Kosuke: thanks for compiling use cases. To me the various documents and records are multiple evidence in the same verification element. Does this match your perspective?

@Jules: document, record, and vouch look good to me. One question: what is the main difference between document and id_document (as we have it in the spec right now)?

[Julian White]

Well, nothing really. I’ve just used document as I have a personal aversion to saying ID document because it creates a mental model of passports/ID cards etc, and doesn’t sound like it would include things like a qualification but moving away from id_document would be a breaking change. Mark and I had a chat about it earlier in the week and I think we’ve decided the elements could be id_document, electronic_record, vouch and we would update the definition of id_document to make it clear it covers all the things.

‌

[Torsten Lodderstedt]

sounds good. I don’t mind having document as an alias of id_document (or visa versa) in the specification (if that helps with the mental model ).

[Julian White]

@Torsten Lodderstedt I’ll go with documentthen and make id_documentand alias for it for backward compatibility. What’s the preferred way to do that in the schema? oneOf?

[Julian White]

Based on the above come up with the following:

Definitions

document: any form of physical or electronic document provided by the user as evidence to support a claim  

electronic_record: data or information obtained electronically from an approved or recognised source which is used as evidence to support a claim

vouch: an attestation or reference given by an approved or recognised person declaring they believe to the best of their knowledge that the claim(s) are genuine and true.

‌

Types of evidence

document: 

• type: the type of document that was used, e.g. passport, driving licence, statement, utility bill, etc
• document_number: an identifier/number that uniquely identifies a document that was issued to a person. This is used on one document and will change if it is reissued, e.g. a passport number, certificate number, etc
• personal_number: an identifier that is assigned to the person and is not limited to being used in one document, for example a national identification number, personal identity number, citizen number, social security number, driver number, account number, licensee number, etc
• serial_number: an identifier/number that identifies the document irrespective of any personalisation information (this usually only applies to physical artefacts and is present before personalisation)
• date_of_issuance: the date the evidence was issued
• date_of_expiry: the date the evidence will expire

• issuer:

  • name: name of the entity that issued the evidence
  • address: address of the entity that issued the evidence
  • country: country where the issuer is based
  • region: the name of the region / state / province / municipality that issuer has jurisdiction over (if it’s not national)

‌

electronic_record:

• type: the type of record that was used, e.g. national population register, birth register, banking API, etc
• personal_number: an identifier that is assigned to the person and is not limited to being used in one document, for example a national identification number, personal identity number, citizen number, social security number, driver number, account number, licensee number, etc
• date_of_entry: the date the record was created
• date_of_expiry: the date the record will expire

• source:

  • name: name of the source
  • address: address of the source
  • country: country where the source is based
  • region: the name of the region / state / province / municipality that the source has jurisdiction over (if it’s not national)

‌

vouch:

• type: vouch
• reference_number: an identifier/number that uniquely identifies the evidence. 
• date_of_issuance: the date the vouch was issued
• date_of_expiry: the date the vouch will expire

• voucher:

  • name: name of the person giving the vouch/reference
  • birthdate: birthdate of the person giving the vouch/reference
  • address: address of the person giving the vouch/reference
  • occupation: occupation or other authority of the person giving the vouch/reference
  • organization: name of the organization the voucher is representing

‌

[Torsten Lodderstedt]

👍

[Mark Haine]

resolved by PR #63