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)

[fernandopradocabrillo]

I already included it in the Release PR just to advance with the topic, but I can update if we decide otherwise 😄

[QaunainM]

Hi @fernandopradocabrillo , thanks and it looks good.

Just an idea, for this scenario (/check requests failing when the period is outside of the monitoredPeriod)

What is your opinion on making it something like OUT_OF_RANGE_MONITORED_PERIOD

[bigludo7]

Hello
Changing the code will be a breaking change right?
As we are preparing a new release (for end of aug) with no breaking change I'm a bit uncomfortable to reprocess the release management for this subtle evolution. I suggest to keep the idea for future consideration and in particular for new major version.

[fernandopradocabrillo]

I agree. It would be a breaking change and we would have to go to a v3...

[QaunainM]

@fernandopradocabrillo and all,

Just an idea, for this scenario (/check requests failing when the period is outside of the monitoredPeriod)

What is your opinion on making it something like OUT_OF_RANGE_MONITORED_PERIOD