Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add management of monitoredPeriod in sim swap for retrieve-date operation #153

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 32 additions & 3 deletions code/API_definitions/sim-swap.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,11 @@ info:

The API provides 2 operations:

- POST retrieve-date : Provides timestamp of latest SIM swap, if any, for a given phone number. If no swap has been performed, the API will return the SIM activation date (the timestamp of the first time that the sim connected to the network) by default, unless this is not possible due to local regulations preventing the safekeeping of the information for longer than the stated period of time. If this is the case, a `null` value will be returned.
- POST retrieve-date : Provides timestamp of latest SIM swap, if any, for a given phone number.

- If no swap has been performed and the MNO supports unlimited SimSwap monitoring timeframe, the API will return the SIM activation date (the timestamp of the first time that the SIM connected to the network).
bigludo7 marked this conversation as resolved.
Show resolved Hide resolved

- If the latest SIM swap date (or the activation date if no SIM swap) cannot be communicated due to local regulations (or MNO internal privacy policies) preventing the safekeeping of the information for longer than the stated period, a `null` value will be returned. Optionally, a `monitoredPeriod` could be provided to indicate monitored time frame (in days) supported by the MNO. In this case the response must be treated as "there was no sim swap events during 'monitoredPeriod'. Either the parameter is optional, it is recommended to support it in SimSwap implementations.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"there was no sim swap events" -> "there were no sim swap events"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed


- POST check: Checks if SIM swap has been performed during a past period (defined in the request with 'maxAge' attribute) for a given phone number.

Expand Down Expand Up @@ -73,13 +77,13 @@ info:
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.0
version: wip
x-camara-commonalities: 0.4.0
externalDocs:
description: Product documentation at Camara
url: https://github.com/camaraproject/SimSwap
servers:
- url: "{apiRoot}/sim-swap/v1"
- url: "{apiRoot}/sim-swap/wip"
bigludo7 marked this conversation as resolved.
Show resolved Hide resolved
variables:
apiRoot:
default: http://localhost:9091
Expand Down Expand Up @@ -116,6 +120,13 @@ paths:
application/json:
schema:
$ref: "#/components/schemas/SimSwapInfo"
examples:
RETRIEVE_DATE:
$ref: "#/components/examples/RETRIEVE_DATE"
RETRIEVE_MONITORED_PERIOD:
$ref: "#/components/examples/RETRIEVE_MONITORED_PERIOD"
RETRIEVE_MONITORED_NULL:
$ref: "#/components/examples/RETRIEVE_MONITORED_NULL"
"400":
$ref: "#/components/responses/Generic400"
"401":
Expand Down Expand Up @@ -208,6 +219,10 @@ components:
description: Timestamp of latest SIM swap performed. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
nullable: true
example: "2023-07-03T14:27:08.312+02:00"
monitoredPeriod:
type: integer
description: Timeframe in days for SIM card change supervision for the phone number. It could be valued in the response if the latest SIM swap occurred before this monitored period.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: could it make sense to use hours instead of days here, to align this attribute with "maxAge" parameter from the "check" operation?
When I use check operation , maxAge is internally compared to the monitoredPeriod and the API returns a error when maxAge >monitoredPeriod.
From this perspective it could make sense to use same UoM for both.
On the other hand monitoredPeriod represented in hours promises to be a big number.
Would like to hear other opinions here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked myself same question when i proposed this design. It seems to me that the use of day is more aligned with this attribute meaning and I preferred it that unit consistency across the API.

BTW Thanks @gregory1g for your helpful review :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, even be not fully aligned with maxAge, "days" still looks better here.

example: 120
CheckSimSwapInfo:
type: object
required:
Expand Down Expand Up @@ -398,3 +413,17 @@ components:
status: 504
code: TIMEOUT
message: Request timeout exceeded.
examples:
RETRIEVE_DATE:
summary: Lastest SIM swap date is send back
value:
latestSimChange: 2024-09-18T07:37:53.471829447Z
RETRIEVE_MONITORED_NULL:
summary: Only null value is retrieved
value:
latestSimChange: null
RETRIEVE_MONITORED_PERIOD:
summary: null is send back for the date but a monitoredPeriod is provided
value:
latestSimChange: null
monitoredPeriod: 120