-
Notifications
You must be signed in to change notification settings - Fork 24
/
Copy pathsim_swap.yaml
405 lines (372 loc) · 17.3 KB
/
sim_swap.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
openapi: 3.0.3
info:
title: SIM Swap
description: |
The SIM swap API provides a programmable interface for developers and other users (capabilities consumers) to request the last date of a SIM swap performed on the mobile line, or, to check whether a SIM swap has been performed during a past period.
# Introduction
The SIM Swap API performs real-time checks on the last SIM Swap event.
The SIM Swap API is useful to prevent fraud by reducing the risk of account takeover fraud by strengthening SIM based authentication processes such as SMS One-time passwords. Fraudsters are using SIM swap techniques to intercept SMS messages and reset passwords or receive verification codes that allow them to access protected accounts.
The SIM Swap API can also be used to protect non-automated actions. For example, when a call center expect contacts a user to clarify or confirm a sensitive operation.
This API is used by an application to get information about a mobile line latest SIM swap date. It can be easily integrated and used through this secured API and allows SPs (Service Provider) to get this information an easy & secured way. The API provides management of 2 endpoints answering 2 distinct questions:
* When did the last SIM swap occur?
* Has a SIM swap occurred during last n hours?
Depending on the network provider implementation, legal enforcement, etc... either one or both endpoints could be implemented.
# Relevant terms and definitions
**SIM swap**:
A SIM swap is a process in which a user's mobile phone number (MSISDN) is associated with a new SIM card (IMSI). This is typically done by contacting the user's mobile service provider and requesting a new SIM card for various reasons, such as a lost or damaged SIM card or upgrading to a new phone.
SIM swap also happens during other actions like changing user's phone number, changing mobile service provider keeping user's mobile phone number or when activating a new SIM associated to the same phone number, known as multisim service. New subscription is considered as a SIM swap as well, the MSISDN which can be used by another person earlier, is associated with a SIM card it was not associated before.
# API functionality
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 check: Checks if SIM swap has been performed during a past period (defined in the request with 'maxAge' attribute) for a given phone number.
# Authorization and authentication
The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
# Identifying a phone number from the access token
This specification defines the `phoneNumber` field as optional in API requests, specifically in cases where the API is accessed using a 3-legged access token, and the phone number can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the information associated with the access token used to invoke the API.
## Handling of phone number information:
### Optional `phoneNumber` field for 3-legged tokens:
- When using a 3-legged access token, the phone number associated with the access token must be considered as the phone number for the API request. This means that the `phoneNumber` field is not required in the request, and if included it must identify the same phone number, therefore **it is recommended NOT to include it in these scenarios** to simplify the API usage and avoid additional validations.
### Validation mechanism:
- The server will extract the phone number identification from the access token, if available.
- If the API request additionally includes a `phoneNumber` field when using a 3-legged access token, the API will validate that the phone number provided matches the one associated with the access token.
- If there is a mismatch, the API will respond with a 403 - INVALID_TOKEN_CONTEXT error, indicating that the phone number information in the request does not match the token.
### Error handling for unidentifiable phone number:
- If the `phoneNumber` field is not included in the request and the phone number information cannot be derived from the 3-legged access token, the server will return a 422 `UNIDENTIFIABLE_PHONE_NUMBER` error.
### Restrictions for tokens without an associated authenticated phone number:
- For scenarios which do not have a phone number associated to the token during the authentication flow, e.g. 2-legged access tokens, the `phoneNumber` field MUST be provided in the API request. This ensures that the phone number is explicit and valid for each API call made with these tokens.
# Further info and support
[GSMA Mobile Connect Account Takeover Protection specification](https://www.gsma.com/identity/wp-content/uploads/2022/12/IDY.24-Mobile-Connect-Account-Takeover-Protection-Definition-and-Technical-Requirements-v2.0.pdf) was used as source of input for this API. For more about Mobile Connect, please see [Mobile Connect website](https://mobileconnect.io/).
(FAQs will be added in a later version of the documentation)
termsOfService: http://swagger.io/terms/
contact:
email: project-email@sample.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.0-rc.1
x-camara-commonalities: 0.4.0
externalDocs:
description: Product documentation at Camara
url: https://github.com/camaraproject/SimSwap
servers:
- url: "{apiRoot}/sim-swap/v1rc1"
variables:
apiRoot:
default: http://localhost:9091
description: API root, defined by the service provider, e.g. `api.example.com` or `api.example.com/somepath`
paths:
/retrieve-date:
post:
security:
- openId:
- sim-swap:retrieve-date
- openId:
- sim-swap
tags:
- Retrieve SIM swap date
description: Get timestamp of last SIM swap event for a mobile user account provided with phone number.
operationId: retrieveSimSwapDate
parameters:
- $ref: '#/components/parameters/x-correlator'
requestBody:
description: |
Create a SIM swap date request for a phone number.
content:
application/json:
schema:
$ref: "#/components/schemas/CreateSimSwapDate"
required: true
responses:
"200":
description: Contains information about SIM swap change
headers:
x-correlator:
$ref: '#/components/headers/x-correlator'
content:
application/json:
schema:
$ref: "#/components/schemas/SimSwapInfo"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"404":
$ref: "#/components/responses/Generic404"
"422":
$ref: "#/components/responses/Generic422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/check:
post:
security:
- openId:
- sim-swap:check
- openId:
- sim-swap
tags:
- Check SIM swap
description: Check if SIM swap has been performed during a past period
operationId: checkSimSwap
parameters:
- $ref: '#/components/parameters/x-correlator'
requestBody:
description: |
Create a check SIM swap request for a phone number.
content:
application/json:
schema:
$ref: "#/components/schemas/CreateCheckSimSwap"
required: true
responses:
"200":
description: Returns whether a SIM swap has been performed during a past period
headers:
x-correlator:
$ref: '#/components/headers/x-correlator'
content:
application/json:
schema:
$ref: "#/components/schemas/CheckSimSwapInfo"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"404":
$ref: "#/components/responses/Generic404"
"422":
$ref: "#/components/responses/Generic422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
components:
securitySchemes:
openId:
type: openIdConnect
openIdConnectUrl: https://example.com/.well-known/openid-configuration
parameters:
x-correlator:
name: x-correlator
in: header
description: Correlation id for the different services
schema:
type: string
headers:
x-correlator:
description: Correlation id for the different services
schema:
type: string
schemas:
SimSwapInfo:
type: object
required:
- latestSimChange
properties:
latestSimChange:
type: string
format: date-time
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"
CheckSimSwapInfo:
type: object
required:
- swapped
properties:
swapped:
type: boolean
description: Indicates whether the SIM card has been swapped during the
period within the provided age.
PhoneNumber:
type: string
pattern: '^\+[1-9][0-9]{4,14}$'
example: '+346661113334'
description: A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
ErrorInfo:
type: object
required:
- status
- code
- message
properties:
status:
type: integer
description: HTTP response status code
code:
type: string
description: Code given to this error
message:
type: string
description: Detailed error description
CreateCheckSimSwap:
type: object
properties:
phoneNumber:
$ref: "#/components/schemas/PhoneNumber"
maxAge:
type: integer
example: 240
description: |
Period in hours to be checked for SIM swap.
format: int32
minimum: 1
maximum: 2400
default: 240
CreateSimSwapDate:
type: object
properties:
phoneNumber:
$ref: "#/components/schemas/PhoneNumber"
responses:
Generic400:
description: Bad Request
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_400_INVALID_ARGUMENT:
description: Invalid Argument. Generic Syntax Exception
value:
status: 400
code: INVALID_ARGUMENT
message: Client specified an invalid argument, request body or query param.
Generic401:
description: Unauthorized
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_401_UNAUTHENTICATED:
description: Request cannot be authenticated
value:
status: 401
code: UNAUTHENTICATED
message: Request not authenticated due to missing, invalid, or expired credentials.
Generic403:
description: Forbidden
headers:
x-correlator:
$ref: '#/components/headers/x-correlator'
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorInfo'
examples:
GENERIC_403_PERMISSION_DENIED:
description: Permission denied. OAuth2 token access does not have the required scope or when the user fails operational security
value:
status: 403
code: PERMISSION_DENIED
message: Client does not have sufficient permissions to perform this action.
GENERIC_403_INVALID_TOKEN_CONTEXT:
description: Reflect some inconsistency between information in some field of the API and the related OAuth2 Token
value:
status: 403
code: INVALID_TOKEN_CONTEXT
message: phoneNumber is not consistent with access token
Generic404:
description: Not found
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_404_NOT_FOUND:
description: Resource is not found
value:
status: 404
code: NOT_FOUND
message: The specified resource is not found.
Generic422:
description: Unprocessable Content
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_422_NOT_SUPPORTED:
description: Not Supported
value:
status: 422
code: NOT_SUPPORTED
message: Service not supported for this phoneNumber
UNIDENTIFIABLE_PHONE_NUMBER:
description: The phone number is not included in the request and the phone number information cannot be derived from the 3-legged access token
value:
status: 422
code: UNIDENTIFIABLE_PHONE_NUMBER
message: The phone number cannot be identified
Generic500:
description: Internal Server Error
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_500_INTERNAL:
description: Problem in Server side. Regular Server Exception
value:
status: 500
code: INTERNAL
message: Unknown server error. Typically a server bug.
Generic503:
description: Service Unavailable
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_503_UNAVAILABLE:
description: Service is not available. Temporary situation usually related to maintenance process in the server side
value:
status: 503
code: UNAVAILABLE
message: Service Unavailable.
Generic504:
description: Gateway Timeout
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_504_TIMEOUT:
description: API Server Timeout
value:
status: 504
code: TIMEOUT
message: Request timeout exceeded.