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

Merged
merged 8 commits into from
Dec 20, 2024
Merged
Show file tree
Hide file tree
Changes from all 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
5 changes: 3 additions & 2 deletions .spectral.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# CAMARA Project - linting ruleset - documentation avaialable here:
# https://github.com/camaraproject/Commonalities/blob/main/documentation/Linting-rules.md
# 31.01.2024 - initial version
# 10.10.2024 - workaround for Spectral crashing: camara-path-param-id and camara-discriminator-use switched off

extends: "spectral:oas"
functions:
Expand Down Expand Up @@ -87,7 +88,7 @@ rules:
function: pattern
functionOptions:
notMatch: \b(id|Id|ID|iD)\b
recommended: true # Set to true/false to enable/disable this rule
recommended: false # Set to true/false to enable/disable this rule

camara-security-no-secrets-in-path-or-query-parameters:
message: "Sensitive data found in path: {{error}} Consider avoiding the use of Sesentive data "
Expand Down Expand Up @@ -221,7 +222,7 @@ rules:
field: discriminator
function: truthy
description: "Discriminator object is required when using oneOf or anyOf."
recommended: true # Set to true/false to enable/disable this rule
recommended: false # Set to true/false to enable/disable this rule

camara-operationid-casing-convention:
message: Operation Id must be in Camel case "{{error}}"
Expand Down
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 network operator 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).

- 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 were no sim swap events during 'monitoredPeriod'. Either the parameter is optional, it is recommended to support it in SimSwap implementations.

- 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/vwip"
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