KYC Match/Fill-in v0.1.0 leftover issues, new features, functional enhancement for next versions

[ToshiWakayama-KDDI]

For KYC Match/Fill-in APIs v0.1.0, leftover issues, new features and functional enhancement for next versions were listed at the meeting 2024/01/09:

Note: This Issue is just a memo for us to not forget. It is expected to issue separete issues for each item to discuss for a API version.

1. Match: Scoring

2. Match: Hash and some additional parameters (e.g. initials)

3. Match: Normlisation

4. Match: Second Level Validation?

5. Match: Name attribute and Address attribute; coexisting of one consolidated attribute and attributes composed of separate parts?

6. Match: Country/market specific attributes; how to handle in a better way
   • dataType used as a discriminator would be useful to avoid duplication of concerned attributes
   • polymorphism should help us to define new specific schemas inheriting from this first base and perhaps targeting specific countries's requirements
   ->Issue Proposition of design evolution #38 and Issue Polymorphism and discriminator for specific requirements  #39 were created

7. (Closed) Match: responses Y, N-NA, N-AV, N-AD are needed? Or the current version is enough, as those responses can be covered by the current true, false, not_available, and Error Response Access Denied
   ->At the meeting on January 23rd, DT mentioned that this is not an issue. No need for this.

8. Match / Fill-in: Subscriber/contractor and User concept

9. Match / Fill-in: Gender attribute should be specially treated?

10. Fill-in: in addition to the current 'none in the request body', Phone Number?, 3rdPartyId?, attributes which the 3rdParty wants to receive.

11. OpenID Foundation (OIDF) collaboration
    -> Presentation on their eKYC-IDA was made on February 6th, then an Issue is to be created.

Note: This Issue is for AI # 06.04.

Best regards,
Toshi

[GillesInnov35]

hi @ToshiWakayama-KDDI , thanks a lot for this summarize. Many points to address.
Could you please help me to see what do you mean by

3 - Match: Normalisation

BR
Gilles

[ToshiWakayama-KDDI]

Hi all,

As per AI #13.03, I have created some issues for each listed item. Please look at them, and if anything wrong or no longer needed or not needed at this stage, please comment and point it out.

BR

[ToshiWakayama-KDDI]

hi @ToshiWakayama-KDDI , thanks a lot for this summarize. Many points to address. Could you please help me to see what do you mean by

3 - Match: Normalisation

BR Gilles

Hi @GillesInnov35 ,

Sorry for the delay in responding. During past KYC Match discussion, I think there was some discussion about Normalisation process, which, I understand, is that values of some attributes should be 'normalized' before comparing them with values the MNO has, for better matching results.

I have not created an Issue for this yet. If you think we do not need this, please let me know. Well, Japan (and some other countries/markets) do not need 'normalization' process.

BR

[GillesInnov35]

thanks @ToshiWakayama-KDDI, if 'normalization' means how to normalize values of attributes before comparison, I think also we do not need to create a dedicated issue. This processing before match result calculation is the responsability of the operator's backend service.
Gilles