Right now, the kyc-fill-in API includes the property "phoneNumber" as part of the response. I opened this concern in a discussion thread, but I think we should discuss it as an issue and in the WG meetings.
First I would like to clarify what phoneNumber should be returned in the response, in my understanding it is the one used in the request associated with the access token.
But then, we are allowing to mimic the Number Verification's /device-phone-number endpoint that returns the phoneNumber associated with the access token used in the request. It is less of a problem if the API uses CIBA, but if it is used with AuthCode + network_auth we are exactly replicating this functionality.
I'd like to know what was the original purpose and use case to include it in the spec and how the operators that proposed it have solve these issues.
In my opinion we should remove it from the response since it doesn't actually improve the functionality. The API is very likely going to be used with a 3-legged token so the client will already know the msisdn used for the request and if authcode is used then we are giving a way to transform ips into msisdns.
Right now, the kyc-fill-in API includes the property "phoneNumber" as part of the response. I opened this concern in a discussion thread, but I think we should discuss it as an issue and in the WG meetings.
First I would like to clarify what phoneNumber should be returned in the response, in my understanding it is the one used in the request associated with the access token.
But then, we are allowing to mimic the Number Verification's /device-phone-number endpoint that returns the phoneNumber associated with the access token used in the request. It is less of a problem if the API uses CIBA, but if it is used with AuthCode + network_auth we are exactly replicating this functionality.
I'd like to know what was the original purpose and use case to include it in the spec and how the operators that proposed it have solve these issues.
In my opinion we should remove it from the response since it doesn't actually improve the functionality. The API is very likely going to be used with a 3-legged token so the client will already know the msisdn used for the request and if authcode is used then we are giving a way to transform ips into msisdns.