camaraproject / KnowYourCustomer

Repository to describe, develop, document and test the KnowYourCustomer API family
Apache License 2.0
7 stars 5 forks source link

Add initials to the attribute list #77

Open HuubAppelboom opened 2 months ago

HuubAppelboom commented 2 months ago

At KPN (and maybe at other telco's as well) we ony store our customers initials, not the givenName and middleNames in full.

For example my data is stored as HM Appelboom, where HM are my initials, and Appelboom is my familyName. (Hubertus is my givenName and Mattheus my middleName).

We considered using the givenName and middleNames field, but this may give a faulty impression to the API consumer that there is a full match on givenName and middleNames, while in reality there is only a match being done on the initials.

We therefore propose to add an attribute which contains the initials of givenName and middleNames.

I suggest to call this initialsGivenMiddleNames (to make sure people don't add the initial of the family name as well).

KevScarr commented 2 months ago

@HuubAppelboom Is this common practice for all operators in your market? I'm wondering how an Aggregator would know to use initial letter of full name, or should they be providing both, otherwise proposal looks practical to me.

HuubAppelboom commented 2 months ago

@KevScarr With the current Mobile Connect product we agreed in the NL market to work only with initials, because some Telco's only store the initials, and several of our customers have the same issue.

For the CAMARA version we are proposing to support both in the specification, so we don't need to make country specific adaptations. API cosumers can then decide what they want to supply, and the answer can also be tailored to what the MNO can support.

HuubAppelboom commented 1 month ago

Alternatively, we can also call this field initials, as long as the description is 100% clear what the initials cover (first name and middle names)

KevScarr commented 1 month ago

@HuubAppelboom Thanks for the info; I personally like your explicit approach (initialsGivenMiddleNames) it's clean and obvious for both API consumer and implementor what behavior to expect.

HuubAppelboom commented 1 month ago

All, as discussed in todays meeting, it may be better in stead of using a seperate attribute for initials, to provide an answer "initials" next to the current "true" or "false" for the match response for givenName and middleNames, to indicate that only initials are available for matching, and that these match