First version upload of SubscriptionStatus YAML file

[chinaunicomyangfan]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

First version upload of SubscriptionStatus YAML file

Which issue(s) this PR fixes:

Fixes #6

[davidjmorris]

If a MSISDN is supplied that is in a phone number range allocated to the CSP by the country regulator, but is not currently allocated to a subscriber, will the response be Generic404 ?

[chinaunicomyangfan]

If a MSISDN is supplied that is in a phone number range allocated to the CSP by the country regulator, but is not currently allocated to a subscriber, will the response be Generic404 ?

Yes,I think the response should be GENERIC_404_IDENTIFIER_NOT_FOUND.

[ToshiWakayama-KDDI]

Hi @chinaunicomyangfan ,

Thanks for the yaml proposal.

There are three attributes included, i.e. Voice/SMS Inbound, Voice/SMS Outbound, and Data Service Status. I wonder if these three attributes are most suitable or not. For example, are these three attributes common to three MNOs in China?

Thanks,

[ToshiWakayama-KDDI]

Hi @chinaunicomyangfan ,

Another question, please. In the Introduction section, there are two scenarios, and both show the cases of suspended "Voice/SMS inbound". Is it the correct understanding that both scenarios could have "Voice/SMS Outbound" and "Data Service Status"?

Thanks,

[ToshiWakayama-KDDI]

Hi @chinaunicomyangfan ,

Another question, please. Do you plan to use this API with 2-legged Auth flow, or with 3-legged Auth flow? Why I am asking is that, if 3-legged Auth flow, the phoneNumber input must not be provided under the current commonalities rules.

Thanks,

[chinaunicomyangfan]

Hi @chinaunicomyangfan ,

Thanks for the yaml proposal.

There are three attributes included, i.e. Voice/SMS Inbound, Voice/SMS Outbound, and Data Service Status. I wonder if these three attributes are most suitable or not. For example, are these three attributes common to three MNOs in China?

Thanks,

As far as I know, these three attributes are universal among Chinese MNOs. I would like to know if these three attributes are suitable from the perspective of other MNOs, and if additional subscription statuses need to be added,

[chinaunicomyangfan]

"Voice/SMS Outbound" and "Data Service Status

@ToshiWakayama-KDDI Thank you for your suggestion. I think your suggestion is correct. I have rewritten these two scenarios and added use cases for "Voice/SMS Outbound" and "Data Service Status".

[chinaunicomyangfan]

Hi @chinaunicomyangfan ,

Another question, please. Do you plan to use this API with 2-legged Auth flow, or with 3-legged Auth flow? Why I am asking is that, if 3-legged Auth flow, the phoneNumber input must not be provided under the current commonalities rules.

Thanks,

@ToshiWakayama-KDDI This API is similar to KYC-match and should use both 2-leg and 3-leg. When trying 3-leg, the phone number does not need to be passed in, but is obtained through the access token. Following your suggestion, I reviewed the latest rules of commonalities and the YAML file of KYC-match. Then I modified the identity authentication section in the API description, added examples of input parameters, and modified the error code description of 403,422.

Please review and feel free to contact me if you have any questions.

Thank you again for your suggestion.

[ToshiWakayama-KDDI]

Hi @chinaunicomyangfan ,

Thanks for the reply.

Are you still looking to publicly release this API for Fall'25 Meta-release? If so, as you are aware, M3 cut-off date June 28 is approaching. What you have to do by then is roughly listed in the 2025-06-25 meeting minutes, so, please look at here (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/140968101/2025-06-24+Draft+Minutes+KYC+Match+Fill-in+Age+Veri+Tenure+Number+Rec+Sub+Status#Subscription-Status-API-Repo).

Many thanks,
Toshi

[ChuanyuChen]

looks good.