Number recycling subscription API

[gauravji2192]

Problem description
Currently many Apps provide a functionality to login using SMS OTP or Whatsapp OTP only and will also provide login functionality using number verify as an alternative to OTP. This feature enables great user experience for password less login.
Banking and Fintech Apps don’t use OTP as a login option only, but OTP based login in extremely common with many entertainment, shopping, convenience apps. For example: One can register to Tiktok/Netflix/Amazon today with just SMS OTP and nothing else is needed.

The current Number recycling API requires the Application to check if a number was recycled with a specified date. If a number is recycled after 1 year and the Application checks only for last 90 days or 120 days, this API will not give desired result. Application service provider may need to try this API with the longest possible number recycling duration to get the true result.

Possible evolution

Application can use a Number recycling subscription API at first time registration or login of a new user and subscribe for a number recycling notification. CSP will notify the application whenever the number is recycled or abandoned.
CSP would need to implement a notification mechanism towards API consumers whenever a number is recycled.

Advantage of Number recycling subscription API

There is no unnecessary API call per login request. This would reduce network traffic, cost for Application will have simplicity to use.
Application can deactivate and delete their Application user immediately if their number is recycled. This would help applications in getting right visibility why their users are not returning to their application.
Regulators can enforce usage of this API to prevent data breach.
Hence, I propose to introduce a new CAMARA API for number recycling subscription.

[albertoramosmonagas]

Hi @gauravji2192, from TEF, we do not support this proposal. We do not think a subscription-based model makes sense as an evolution of the current Number Recycling API. The existing API is intentionally defined as a synchronous check answering a very specific question: whether a phone number has been reassigned since a given date.

The concern described in this issue is mainly about how the consumer chooses and manages the reference date (specifiedDate), not about the lack of a notification mechanism. Adding subscriptions and notifications would turn this into a fundamentally different API, with different scope, lifecycle, operational and privacy considerations. Also, the proposal mixes different concepts such as number recycling and number abandonment, which should not be merged without a much broader discussion.

[gauravji2192]

Hi @gauravji2192, from TEF, we do not support this proposal. We do not think a subscription-based model makes sense as an evolution of the current Number Recycling API. The existing API is intentionally defined as a synchronous check answering a very specific question: whether a phone number has been reassigned since a given date.

The concern described in this issue is mainly about how the consumer chooses and manages the reference date (specifiedDate), not about the lack of a notification mechanism. Adding subscriptions and notifications would turn this into a fundamentally different API, with different scope, lifecycle, operational and privacy considerations. Also, the proposal mixes different concepts such as number recycling and number abandonment, which should not be merged without a much broader discussion.

Hi @albertoramosmonagas My concern is primarily about number deactivation subscription. An application (such as Whatsapp, Netflix, Amazon etc), allows a new user login with OTP only and without using any CAMARA API, which is really a present situation globally with many convivence apps., In such case, whenever a number is deactivated, application does not have any way to know this and delete user profile. In this case, application may have still has user's privacy data such as credit card details, address, chats etc. Now when a new subscriber is activated with same phone number, number recycle API may help definitely. However, it puts a responsibility on application to check the status and send the right reference date when number is already assigned to a new user. My proposal is to provide a premium number deactivation subscription API for only for enterprise grade apps to send a notification whenever a number is deactivated specifically for subscribed numbers. I am not sure if it is privacy issue in sending this notification as purpose is to prevent account takeover of end user and end user is not the owner of number anymore post number deactivation. By using this information, application can delete or disable their user profile (billing data, address etc). Please suggest with your opinion. If you think, I must raise this in some other API, please let me know.

[albertoramosmonagas]

Hi @gauravji2192, thanks for the clarification. The business case looks promising, but I still feel the same way.

My main concern is that a deactivation subscription would address a different event from number recycling itself. A deactivation notification would be about a status change that happens before recycling, potentially even before quarantine, and in any case before reactivation by a new user. In our view, that is a different lifecycle event and should not be treated as part of the same API scope.

The current Number Recycling design is focused on detecting whether a number has been reassigned to a new user after a given reference date. In other words, what is relevant for Number Recycling is the reactivation/reassignment to a new subscriber after the quarantine period, not the mere deactivation of the line. Also, if the number is already in deactivated status when Number Recycling is queried, the current 3-legged authentication model would fail. So the existing product design already excludes the deactivated state as a basis for this API.

For that reason, I do not see number deactivation subscription as a natural evolution of Number Recycling, but if the group believes there is value in a proactive notification capability for number deactivation or number status changes, then we think this should be discussed as a separate API or separate work item, with its own scope, semantics, privacy and operational model.

[gauravji2192]

@albertoramosmonagas I agree with your point. It may not be natural evolution of number recycling however a separate API for this usecase, would be a worth idea to explore in my opinion.

[HuubAppelboom]

@gauravji2192 See also the discussion here on how to correctly use the Number Recycling api #90

API Consumer should always make sure they concatenate the events in such a way that the specifiedDate alway point to a previous Number Recycling API call (with result false), or to a previous event at which they concluded the phone number was still in use by the same user.

A subscription model is much more difficult to manage, both on the side of the API Consumer and the API Provider. Presumably a subscription model will work with a monthly fee, so on both sides you will need to take care of managing events like when either the subcriber stops with his mobile subscription, or cancels his account with the API Consumer, or for example changes phone number, or when the subscriber ports the number to another provider. Also, when you have these events causing signals back and forth, this may give raise to privacy discussions (like should porting information be pushed to API Consumers, or should it only be shared when it becomes relevant etc).

[GillesInnov35]

@gauravji2192 , @HuubAppelboom @albertoramosmonagas , we also had such a request for a notification flows service but we haven't discussed internally yet.
My feeling is that Number Recycling should not cover this kind of service, it must focus on number recycling event by requesting a specific date (atomic API). But we could have a discussion.
Perhaps a new API study ? Subscription to phone number status change notifications (event type notifications ? dpv:purpose ? privacy aspects ?)

[HuubAppelboom]

@GillesInnov35 @gauravji2192 @albertoramosmonagas The problem with such notification services is that you can have many events that can have impact on whether you should notify the API consumer, and if some cases it may also cause privacy problems., because you are sharing information that may not be relevant at that time, because there is no fraud risk.

For example the events you can have:

• a SIM Swap
• a change in phone number
• a line can be suspended (when it is reported lost or stolen)
• a line can reactivated
• you can have a contract takeover
• a subcription may be terminated
• a migration from postpaid to prepaid or vice versa
• a port-in or port-out
• the user may be blocked because he has not paid the bill (or has resumed paying the bill)

I think we have covered quite a few now with the Number Recycling API, but still it can perhaps be done better.

The main problem that complicates the matter is that the API Consumer is used to refer to the customer based on his MSISDN. But yeah, this can change due to all events listed above. We try to fix that by describing how to use the specifiedDate.

Another apporach could be is to work with a user specific identifier (for a given API Consumer). And let the API Consumer once he knows that identifier, always use that when aksing for information about a certain phone number.
That user identifier is already present in the sub claim of the ID token: Pairwise Pseudonymous Identifier (PPID).

So, if you would for example combine the msisdn and the sub field in a CIBA request as the login_hint, both parties will be referring to exactly the same user. That can solve a lot of the ambiguity, and make implementation for the API Consumer a bit simpler, because he does not need to keep track of the date the user was confirmed to be the right user.

[GillesInnov35]

thanks @HuubAppelboom , it looks like a Phone Number lifecycle API based on events notification; it is far from an atomic API, isn't it ?

[HuubAppelboom]

@GillesInnov35 Yes, far from atomic, and much too complex.
It may be simpler to work with the Number Recycling API as it is today, and get some more experience first.

[gauravji2192]

@gauravji2192 See also the discussion here on how to correctly use the Number Recycling api #90

API Consumer should always make sure they concatenate the events in such a way that the specifiedDate alway point to a previous Number Recycling API call (with result false), or to a previous event at which they concluded the phone number was still in use by the same user.

A subscription model is much more difficult to manage, both on the side of the API Consumer and the API Provider. Presumably a subscription model will work with a monthly fee, so on both sides you will need to take care of managing events like when either the subcriber stops with his mobile subscription, or cancels his account with the API Consumer, or for example changes phone number, or when the subscriber ports the number to another provider. Also, when you have these events causing signals back and forth, this may give raise to privacy discussions (like should porting information be pushed to API Consumers, or should it only be shared when it becomes relevant etc).

@HuubAppelboom On the operator side, it will just a rule in GSMA OP to notify to subscribed applications whenever a BSS triggers number deactivation.
Rule could be sometime like below:
subscriber MSISDN --> application subscribed (App X, App Y) --> App subscribed for number deactivation notification --> deactivation endpoint

I understand that this is going to be a huge DB. I agree it may be difficult to manage on Operator side, and it can come with a premium monthly fee.

To be honest, I believe that we must restrict the API usage only limited to number deactivation case. Porting means that number is still active on another operator. For example, Netflix can subscribe to number deactivation notification API, and they just disable the user whenever a number is deactivated and notification is provided by Telecom Operator.

I feel this usecase has huge business potential as I see there are many quick commerce apps which are allowing login only based on number and does not maintain any deactivation record of the user. Please refer to my article on this https://www.linkedin.com/pulse/why-telco-industry-needs-number-deactivation-api-gaurav-agarwal-mmddc/?trackingId=zXzxiUdpR16lWTgeJqx79Q%3D%3D

[gauravji2192]

@gauravji2192 See also the discussion here on how to correctly use the Number Recycling api #90

API Consumer should always make sure they concatenate the events in such a way that the specifiedDate alway point to a previous Number Recycling API call (with result false), or to a previous event at which they concluded the phone number was still in use by the same user.

A subscription model is much more difficult to manage, both on the side of the API Consumer and the API Provider. Presumably a subscription model will work with a monthly fee, so on both sides you will need to take care of managing events like when either the subcriber stops with his mobile subscription, or cancels his account with the API Consumer, or for example changes phone number, or when the subscriber ports the number to another provider. Also, when you have these events causing signals back and forth, this may give raise to privacy discussions (like should porting information be pushed to API Consumers, or should it only be shared when it becomes relevant etc).

My suggestion is to provide notification only when there is number deactivation.

[gauravji2192]

@GillesInnov35 Yes, far from atomic, and much too complex. It may be simpler to work with the Number Recycling API as it is today, and get some more experience first.

My idea is as following:

a) Number deactivation API subscribing application exposes an endpoint where it would listen such event. They will also provide input for the numbers that they would like to listen these events
b) Operator will configure rules based on the input provided by API subscriber.
c) Whenever there is a number deactivated in the network (triggered by BSS domain), this event goes to GSMA OP where it checks against the rule and subscription.
d) If there a match found, send a notification to API subscribing application. Notification is very simple -> number +911111111 is deactivated. I dont think it is a privacy issue as it is trying to misuse of a user profile in an app post deactivation of their number. Also, number does not belong to user anymore.
e) API subscribing application delete or disables the user profile in their application.

Billing lifecycle:
An API subscribing application purchases this subscription service on a monthly or annual fee for a quota of number of subscriber base. For example: 10K subscribers will be monitored against this service.

[HuubAppelboom]

@gauravji2192 The problem is that you will get a huge database at the telco, and that if the application can only subscribe you will get a lot of contamination of users in the database that are not using the application anymore. So, you will nee to have a mechanism that works both ways, so by which you can also cancel a subscription and which is strictly enforced.

Sooner or later you will get some contamination, or loss of synchronsation, so you probably will need some mechanism for re-synchronisation as well. And finally, when a user decides to port to another telco, you will need to port all the associated susbcription information as well.

[albertoramosmonagas]

Hi @gauravji2192,

Thanks for the further clarifications. From Telefónica’s side, this additional discussion confirms our view that this should not be part of Number Recycling.

What is being described here is an event-driven number deactivation notification service, with subscription management, matching rules, endpoint lifecycle, cancellation, re-synchronisation and related operational considerations. That is clearly different in scope and nature from the current Number Recycling API, which is designed as an atomic synchronous check on whether the subscriber associated with a phone number has changed after a given specifiedDate.

So our position remains unchanged: we do not support this as an evolution of Number Recycling. If the group sees enough value in this use case, we think it should be explored separately as a new API study/work item, with its own scope, semantics, privacy and operational model.