monitoredPeriod for /check operation

[QaunainM]

Context
A few months ago the team from this CAMARA API agreed on making a monitoredPeriod value that is added into the API response for /retrieve-date operations as seen on Issue 124

Question

What happens on the /check operation if a developer tries to request SIM Swap information for a MaxAge of 744 hours (31 days) if that Telco only supports 30 days due to their privacy rules?

I know for the /retrieve-date operation we will inject the monitoredPeriod into the 200 API response, but I can't remember what logic was decided for the /check operation if the Telco doesn't support the 100 day recommendation that CAMARA have set

Fyi @bigludo7 @hdamker @gregory1g @ToshiWakayama-KDDI

[bigludo7]

For me

In the yaml we mandate the maxAge to be between 1 to 2400.
If the value differ the only option is to send a 400 INVALID_ARGUMENT I guess.
This is challenge-able as commonalities introduced 400 OUT_OF_RANGE and perhaps we should add it.

[QaunainM]

Hi all, @bigludo7 , I see your suggestion to add a 400 with OUT_OF_RANGE in the API response

1. Should the API response also reference the word monitoredPeriod so there is consistency with the approach done for the /retrieve-date operation seen here Add MonitoredPeriod into the API Response if a Telco cannot show the date / data for for Privacy Reasons #124 (comment)

2. I wonder if we can get agreement from other Telcos if they agree to the 400 API response you suggested 'OUT_OF_RANGE' or if we wanted to debate the point I made above. @hdamker @gregory1g @ToshiWakayama-KDDI ?

[hdamker]

@QaunainM I haven't followed the discussion and have no opinion here.

But I suppose there are two cases:

• the value is not within the range of 1 to 2400 ... that must be a 400 response, the message might depend on the used validate
• the value is within the range of 1 to 2400, but beyond the period the network operator is monitoring (so the operator might not know if there was a SimSwap in this maxAge timeframe), you have a valid question about what the API will return (at least that should be desribed)

[jzamoranopriego]

How is a developer supposed to know the allowed range for a specific telco when they receive an OUT_OF_RANGE error? Should Telco add the valid range in the error message?

[bigludo7]

@jzamoranopriego There is is the possibility to provide the information:
In the specification of the API the 'maxAge' could be between 1 hour to 2400 hours. If this delay is not managed due to the operator's own privacy threshold (which in theory would likely be linked to local regulations in the country) and a request is performed with a value inferior to 2400 but superior to operator policy, then, an error `400 OUT_OF_RANGE `is expected with an explicit message to explain the limitation like `Check monitor period could not exceed local regulations (30 days)`.
line 39

[jzamoranopriego]

Thanks, Ludovic, that’s good. It’s not clear to me whether, in those cases, it is mandatory for the /check operation to return the operator policy value in the message (e.g., 30 days), or if that is optional, as the monitoredPeriod is for the /retrieve-date operation.

Is there a reason why it cannot be enforced that an MNO return those values in such circumstances for both SIM Swap operations?

[bigludo7]

As of now this is an expectation and not a hard requirement to provide this information.
We were a bit reluctant to introduce a breaking change only for this in the Fall25 release that why we proposed this proposal.

[jzamoranopriego]

@bigludo7, do you mean you are considering to include in future releases monitoredPeriod value as mandatory in case latestSimChange is null and also enforcing MNO to return the operator policty value (e.g 30 days) in case of OUT_OF_RANGE error?