camaraproject / KnowYourCustomer

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

Small release v0.1.1 to fix country example #79

Closed fernandopradocabrillo closed 2 weeks ago

fernandopradocabrillo commented 1 month ago

Problem description

The current specification of the API has a simple "string" as type for the country property and the example indicates "Japan" as value. This is creating an issue for us in the implementation so, as there is already an agreement to use alpha-2, we would like to release a small fix version reflecting this.

Expected behavior

A new versión of the API updating the documentation to reflect the agreement

ToshiWakayama-KDDI commented 1 month ago

Meeting on 14th May: Generally agreed to keep 'country' attribute and use Alpha-2 code, with any comments to be input within 24 hours, i.e. by 10am CEST on 15th May.

Thanks.

ToshiWakayama-KDDI commented 1 month ago

Hi @fernandopradocabrillo , @GillesInnov35 , all,

During the meeting yesterday, there was a comment on Chat from my colleague, which I missed: In OpenID Connect Core spec, country is for country names, and in OpenID for Identity Assurance Spec, country_code is for 2digit codes. I would suggest at least avoid country for 2 digit codes.

Generally alignemnt with OIDC should be considered to be important, I understand, but alignment with other CAMARA APIs is also important.

Device Status uses 'countryName' for 2 digit codes and 'countryCode' for Mobile Country Codes (MCC).

It seems a bit complicated, but I would suggest use 'countryName' instead of 'country' for 2 digit codes, so that we can avoid the conflict with OIDC's attribute for 2 digit codes and align with Device Status's attribute for 2 digit codes.

Would it be acceptable to you, Fernando and also all?

Best regards, Toshi KDDI

GillesInnov35 commented 1 month ago

hi @ToshiWakayama-KDDI, in my opinion we could not use countryName valued with a countryCode. I agreed with @fernandopradocabrillo to keep the attribute country valued with a code to make it simplier and to have a design compliant with version 0.1.0. If we decide to change the naming, countryName is not the right one. As mentioned in a previous issue https://github.com/camaraproject/KnowYourCustomer/issues/66, TMF proposes recently a object countryCode (format, value). I'm not sure we should choose right now this option of a complex object because I know that a study will start soon to see how align GSMA propositions with TMF recommandations for KYC API.

For the decision to make today, I think that if we mofify the name of the country attribute, countryName may not be the right one if valued with a code (ISO 3166 ALPHA-2).

BR Gilles

ToshiWakayama-KDDI commented 1 month ago

Hi @GillesInnov35 , Hi @fernandopradocabrillo ,

Thanks, Gilles, for your opinion, which helped me understand the matter.

We have completed Match/Fill-in v0.1.0, where 'country' attribute is defined as: country: type: string description: Country of the customer's address

This does not specify any formats to be used, e.g. country names or ISO country codes. Telefonica (and potentially some compnaies) has implemented v0.1.0 with Alpha-2 codes for country, so, it is preferrable to have it (Alpha-2 code) as an example for 'country', although we should revisit specific format(s) for 'country' in future releases (as Issue #66). For now, modification in example only.

Is my understanding correct?

BR Toshi

GillesInnov35 commented 1 month ago

thanks @ToshiWakayama-KDDI, yes that's what I think also. BR Gilles

fernandopradocabrillo commented 1 month ago

hi @GillesInnov35 @ToshiWakayama-KDDI,

Sorry I missed this conversation last week. Yes, Toshi, your understanding is correct. This modification won't change the functionality itself and this way the API would still be compliant with v0.1.0 which would be really helpful in this state of the implementation.

We are open to explore other options for future versions, maybe even bring this topic to commonalities to see if this is something we should align across CAMARA/TMF/GSMA or maybe there is a better or standard way to tackle the issue. But for now, I think this is the easiest and fastest way to solve it.

Thanks!

ToshiWakayama-KDDI commented 1 month ago

Hi @fernandopradocabrillo , @GillesInnov35 ,

OK. Thanks. There is no other comment, so, please let me check PR #80.

Best regards, Toshi KDDI