What to do with KYC Match (and other API's) when a SIM is reported lost/stolen ?

[HuubAppelboom]

In case a SIM is reported lost/stolen, what should be the answer to a KYC Match requests (and other API requests) ?

With Mobile Connect, you could provide an indicator that a SIM is reported lost/stolen (and perhaps the fraudster is using it to open an account somewhere).

The lost or stolen info seems to have disappeared form the CAMARA specifications, or is it somewhere still present ?

Moreover, should all netork APIs still work, or does it make sense to provide with all APIs that a SIM is lost/stolen ?

Especially API's that work in the backend could missing that a SIM is temporarily suspended,

Your thoughts , please

[Kevsy]

HI @HuubAppelboom -

The lost or stolen info seems to have disappeared from the CAMARA specifications, or is it somewhere still present ?

I'm not sure - I guess @ToshiWakayama-KDDI @fernandopradocabrillo @GillesInnov35 are best placed to answer this?

Moreover, should all network APIs still work, or does it make sense to provide with all APIs that a SIM is lost/stolen ?

Good question: I agree we should have a consistent position/response where the identifier is not 'Allowed' (see below). Either, or both, of the SIM and Device may have been reported lost or stolen.

A note on representation: there was a similar discussion regarding the taxonomy of IMEI ownership status. This suggested 'Allowed', "Prohibited' and 'Tracked' as top-level signals, and each would be mapped to a set of reasons. Note this was in the context of the frozen 'IMEI Fraud' API proposal, but the discussion is worth reading.

[rartych]

When Three-Legged Authorization Flow is used (I guess KYC APIs need it) then when SIM is marked as lost/stolen, I think the authorization should fail. Am I right? @jpengar ?

[HuubAppelboom]

@rartych In our case, authorization code flow would not work but not CIBA or private key JWT flows do work. And these later ones are usually run with KYC Match.

[jpengar]

When Three-Legged Authorization Flow is used (I guess KYC APIs need it) then when SIM is marked as lost/stolen, I think the authorization should fail. Am I right? @jpengar ?

@rartych As CAMARA has not specified any particular procedure for handling lost or stolen SIM cards, the behaviour would depend on the internal logic and policies of the API provider/operator. While being unable to issue an access token for a phone number corresponding to a lost/stolen SIM card sounds reasonable to me, this may not always be the case, depending on the authentication flow or the specific internal processes of the API provider/operator.

[HuubAppelboom]

Often the telco will block SMS and Number Verify in case a SIM is lost or stolen, depedning on the policy of the telco.

In some cases it may still be useful to provide an answer in an API (for example with KYC Match or Number Recycling)., so a generic error message that should always be applied may not be a good idea.

What may be better is to provide extra (optional) information with the answer of a number of APIs, on whether a SIM is lost/stolen,
but do this in a common format, so that API Consumers can make their own decision what to do depending on the use case (continue onboarding for example or abort).

For example, this extra information could be added to

• KYC Match
• KYC Fill-In
• Age Verification
• Tenure
• Number Recycling

WDYT ?

[Kevsy]

@HuubAppelboom I think it makes sense to reflect this in a 4xx (client) error, because the client will be unable to make the same request again and expect a different result (unless the operator block has been overturned between requests by an out-of-band process, which seems unlikely).

The taxonomy discussion in the proposed IMEI Fraud API suggested 'Allowed', 'Prohibited' and 'Tracked' as 'top level' reasons. In the case of 'lost' or 'stolen', we are probably only concerned with 'Prohibited', and there is a question as to whether this applies to 'reported lost' (I think it should).

As well as 'prohibited' flags in the operator backend, there may be a case where a channel partner/aggregator has detected suspicious behaviour regarding a particular device/identifier. So it may be possible to cover both with:

            GENERIC_403_PROHIBITED:
              description: Prohibited. The identifier indicates a device or account prohibited by the API provider.
              value:
                status: 403
                code: PROHIBITED
                message: The identifier indicates a device or account prohibited by the API provider.

• 'device or account' therefore covers both device identifiers (IMEI etc.) and accounts identifiers (MSISDN etc.)
• There could be a risk of a malicious API consumer receiving this error, and retrying the request with a different identifier if the first fails (e.g. MSISDN, then IP address) - but I believe that would be mitigated by operators not issuing an IP address to a prohibited device/account/
• Finally I'm not sure if there is any risk in exposing the fact that the account is prohibited, so that needs discussion by security experts. If so it may be that this is more suitable:

            GENERIC_422_SERVICE_NOT_APPLICABLE:
              description: Service not applicable for the provided identifier
              value:
                status: 422
                code: SERVICE_NOT_APPLICABLE
                message: The service is not available for the provided identifier.

...albeit it prevents any 'good' use of the API where knowing a prohibited device/account allows the API consumer to take action.

[HuubAppelboom]

@Kevsy Apart from the taxonomy (which should be aligned), not sure whether a 4xx error is always a good idea. For example, when a device is lost you may want to retrieve its location. And in othercases, you still may want to check someone's identity data, regardless whether the SIM is lost or not. By prescribing an error code you may be frustrating a number of valid use cases, for which the lost/stolen SIM is not blocking to open an account etc. And when you let the API Consumer know the status of the SIM, they can decide for example to not use the phone number (for now) for 2FA, but offer alternative methods.

[PedroDiez]

Hi,

I tend to think that the default behavior when an access token is issued (It may depend on the internal logic and policies of the API provider/operator) is to reflect this in a 4xx (client) error, in line with comment by Kevin. That is the way to have the most aligned behaviour as possible (at least on majority of scenarios). I would say the use 422 - SERVICE_NOT_APPLICABLE fits better in terms of security risk and data minimization.

Nonetheless, I understand the business comment raised by Huub. I think the reasonable way for specific use cases are to discuss them within the API initiative in case other behaviours may be provided instead the default one, first from a business perspective and under which conditions looking for alignment within the API initiative and latter to design the technical solution to address that

[Kevsy]

Hi @HuubAppelboom

For example, when a device is lost you may want to retrieve its location.

Sure - and if it is a device that is simply misplaced (and not confirmed as lost/stolen yet), then the APIs should react as normal to meet the use cases you describe above. But if the device has been reported as lost/stolen, then a lookup should be the role of the operator's customer care team using their internal systems- not an external-facing API exposed to any registered developer.

[HuubAppelboom]

@Kevsy @PedroDiez The main issue I see with always returning a 4xx error, without a proper description what the problem is, it does not help the API Consumer.
Let me give you another example. For example, whatsapp (and other messaging apps) use a phone number as primary account identifier. When a device/SIM is stolen , at KPN we block all traffic (SMS, internet, voice). However, the thief could continue to use the whatsapp account via any wifi network (assuming he has also has the pincode o unlock the device).

So, it could be beneficial to provide a signal to other parties that the SIM is out of order because it is reported lost/stolen. A generic 422 error will not work in this case, because this error is also frequently used in case there is not 100% market coverage in a country.