Proposal for transversal exception for phoneNumber/device mismatch with other API identifiers

[PedroDiez]

Problem description
Coming from Customer Insights WG discussion, there is an scenario where a phoneNumber is not related to idDocument provided.
This is some kind of analogous scenario of "IDENTIFIERS_MISMATCH" in the context of device object.

The aim for this issue is to propose a model to reflect that phoneNumber/device provided within a request is not related to other kind of identifier provided.

Also the model tries to be agnostic enough to avoid/address security considerations.

Other APIs could benefit of this transversal Error (e.g. KYC match)

Possible evolution
Define a transversal error for phoneNumber/device mismatch with other "identifier" concept in an API.

            GENERIC_422_INVALID_IDENTIFIERS:
              description: The request contains invalid data identifying customer
              value:
                status: 422
                code: INVALID_IDENTIFIERS
                message: The request contains invalid data.

Alternative solution
N/A

Additional context

CustomerInsights/pull/51 comment

[PedroDiez]

cc @rartych

[eric-murray]

Hi @PedroDiez

Why do APIs requiring an idDocument as an input also require the phone number as an input? The idDocument should uniquely identify the end user, and so also requiring the phone number is then essentially a test that the API consumer knows it. If the API consumer is sure of the idDocument, then there is no way to hide that they have given the wrong phone number.

If the only reason for requiring phoneNumber is that idDocument is not a valid login_hint (for CIBA), then why not propose instead that idDocument be a valid login_hint? Then the phone number would not have to be provided, and there could be no mismatch.

[PedroDiez]

Hi @eric-murray,

The reason for some APIs optionally requiring an idDocument in addition to the 'subscription identification' performed via regular CAMARA procedures (access token in 3-legged mode, phoneNumber in 2-legged mode) is just due to business procedures that also need such information. So the use of idDocument is not related to 'subscription identification' process but to backend business procedures in some Telco Operators that may need it.

[PedroDiez]

Other point, that we have been warned by our busines is the use of this exception within customer insights behaviour as we could be offering/exposing KYC Match feature -> HTTP 403 - KNOW_YOUR_CUSTOMER.ID_DOCUMENT_MISMATCH. (i.e. an analogous topic as identified in #259).

We have also to discuss this scenario in Customer Insights SubProject

[eric-murray]

Thanks @PedroDiez

So the use of idDocument is not related to 'subscription identification' process but to backend business procedures in some Telco Operators that may need it.

In other words, "some Telco Operators" have not implemented phone number lookup given the idDocument, and so require the phone number to be provided independently

[PedroDiez]

Thanks @PedroDiez

So the use of idDocument is not related to 'subscription identification' process but to backend business procedures in some Telco Operators that may need it.

In other words, "some Telco Operators" have not implemented phone number lookup given the idDocument, and so require the phone number to be provided independently

In our case (TEF) is due to a business enforcement in some Telco Operators, where idDocument is required.