KYC-Match: IdDocument type

[sfnuser]

Problem description
Should there be a type field associated with the IdDocument? For e.g. what if the id stored by the MNO is a Biometric card number and the API consumer uses Passport number?

Expected behavior
Comparison of id should be of the same type for meaningful interpretation of the response

[HuubAppelboom]

@sfnuser In the Netherlands, we have about 6-7 ID document types that we accept, and probably in other countries you have the same. You will need to define a complete list of possible ID Documents, which can become quite long, and is quite a bit of work to maintain.

In addition, you will need to now the date the document was issued (because the MNO may have for example data for an old passport, but the end user has a newer passport and shared this with the developer).

I would also recommend to include the expiry date as an optional feature, because it makes sens to know whether the document is still valid. This could be a Match attribute comparin the expiry dates provided, or you could as a developer ask whether an ID Document is still valid today.

[AxelNennker]

The OpenId Foundation's eKYC-Identity-Assurance working group has a list of id documents.
https://bitbucket.org/openid/ekyc-ida/wiki/identifiers

There is no "official" registry of id document types though.
https://bitbucket.org/openid/ekyc-ida/issues/1390/document-type-nowhere-defined

OIDF does not want to "run" a registry. Nobody approached IANA to create a registry of id documents, I think.

To answer the question from this issue. Yes, I think there should be a list. I think it does not have to include all possible document types. The list in the "Documents" section of https://bitbucket.org/openid/ekyc-ida/wiki/identifiers covers a lot already. Even with a subset like idcard, passport, driving_permit and residence_permit we would cover a lot.
I view these document identifiers like OIDC standard claims. Standard claims cover a lot and are good for interoperability and common libraries and OIDC-SKDs. So, I think Camara KYC could define "Standard id document identifiers" and make progress.

Answer to the second question: Yes, the document id is likely depending on the document type and can depend on the method of reading the document.

Example: If you electronically read the German idcard using NFC then the document id is a pairwise identifier (restricted id) and that is different to the document id printed on the plastic card. The pairswise identifier must be different from the printed document id because otherwise it would not be pairwise. The document id printed on the plastic card cannot be electronically read - that information is not on the chip. Neither is the issuing authority's identifier data in the chip. So, even if the document type is "idcard" some data exists or not, and is different.

[sfnuser]

@HuubAppelboom, @AxelNennker: Both of you shared valid points. The reference links were quite useful. I think we are in agreement to introduce a standard set of document identifiers. This list will grow and we may have to include country specific additions. Depending on the id document type, the validation methods also need to be introduced.

For the short term, what is the consensus on response for this field?

[HuubAppelboom]

It also depends very much on what the mobile providers accept as valid identity documents for a subscriber, and how the data is stored. For example, what we use at KPN is the following list:

• NL Driving license
• NL Passport
• EU Passport
• Diplomacy Passport
• Residency Permit W
• Dutch ID card
• Residency Permit I
• Residency Permit II
• Residency Permit III
• Residency Permit IV
• Residency Permit EU/EER

The objective we have is to provide sufficient insight in case there is a document number mismatch. You want to make a distinction for example between cases where one party has a driver license number and the other has a passport number, and cases where it is bot the same type of document (and the persons are not the same), and case where the document type is the same, but one document is much older than the other one.

What probably is sufficient is a classification like

• passport
• driver license
• id card
• other (which includes residency permits, diplomacy passport, etc)

and combine this with both issuance date and expiry date.

In case you also want to tackle the issue that people can have 2 passports (from different countries), you may want to add a country code for the issueing country as well as an optional feature.

In any case, this kind of information can be privacy sensitive, so providing this kind of checks should be evaluated on a case by case basis if you ask me.

To reduce privacy risk , whats you can also do is only return on idDocument answers like:
true, false, document_type_mismatch, issueing_date mismatch, issueing_country_mismatch

or if you want to be more restrictive with respect to the details:
true, false, document_mismatch

[ToshiWakayama-KDDI]

As there has been no further comment, can we close this issue?

[HuubAppelboom]

@ToshiWakayama-KDDI As far as KPN is concerned this can be closed. Let's wait and see first how broad the support for ID Document numbers is going to be.

[ToshiWakayama-KDDI]

To be transferred to the new kyc-match repository, as agreed in 2025-09-30 meeting.

[GillesInnov35]

@ToshiWakayama-KDDI , are you OK to close this issue as it has been addressed ?

[GillesInnov35]

idDocumentType has been added to the kyc-match properties, issue could be close.