Skip to content

Commit

Permalink
Merge pull request #64 from eric-murray/eric-murray-patch-2
Browse files Browse the repository at this point in the history
Incorporate Commonalities WG recommendations on Simplification of Device object
  • Loading branch information
Kevsy authored Aug 9, 2024
2 parents 36d197c + 7b75618 commit 0953681
Showing 1 changed file with 90 additions and 17 deletions.
107 changes: 90 additions & 17 deletions code/API_definitions/CAMARA Mobile Device Identifier API.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -54,10 +54,32 @@ info:
### Authorization and authentication
CAMARA guidelines defines a set of authorization flows which can grant API clients access to the API functionality, as outlined in the document [CAMARA-API-access-and-user-consent.md](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md). 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.
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.
## Handling of mobile subscription information:
### Optional mobile subscription identifiers for 3-legged tokens:
- When using a 3-legged access token, the mobile subscription identifier associated with the access token must be considered as the mobile subscription identifier for the API request. This means that no mobile subscription identifiers are required in the request, and if included it must identify the same subscription. Hence **it is recommended NOT to include it in these scenarios** to simplify the API usage and avoid additional validations.
### Validation mechanism:
- The API server will determine the mobile subscription identifier (e.g. phone number) from the access token itself if that information is associated with it (i.e. 3-legged token).
- If the API request itself additionally includes one or more mobile subscription identifiers when using a 3-legged access token, the API will validate that the identifier(s) 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 mobile subscription information in the request does not match the token.
### Error handling for unidentifiable devices:
- If no mobile subscription information is included in the request and the mobile subscription information cannot be derived from the 3-legged access token, the server will return a `422 UNIDENTIFIABLE_DEVICE` error.
### Restrictions for tokens without an associated authenticated identifier:
- For scenarios which do not have a mobile subscription identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, mobile subscription identifiers MUST be provided in the API request. This ensures that the mobile subscription identifier is explicit and valid for each API call made with these tokens.
# API functionality
The API defines two service endpoints:
Expand All @@ -73,7 +95,7 @@ info:
If the mobile subscription parameters contain a formatting error, a `400 INVALID_ARGUMENT` error is returned.
If the mobile subscription cannot be identified from the provided parameters, a `404 NOT_FOUND` error is returned.
If the mobile subscription cannot be identified from the provided parameters, a `404 DEVICE_NOT_FOUND` error is returned.
If the end user has not consented to the API consumer getting access to the device identifier information, then a `403 PERMISSION_DENIED` error is returned.
Expand Down Expand Up @@ -139,6 +161,7 @@ paths:

requestBody:
description: Parameters to create a new session
required: false
content:
application/json:
schema:
Expand All @@ -159,6 +182,8 @@ paths:
$ref: '#/components/responses/405MethodNotAllowed'
"406":
$ref: '#/components/responses/406Unacceptable'
"422":
$ref: '#/components/responses/422UnprocessableContent'
"429":
$ref: '#/components/responses/429TooManyRequests'
"500":
Expand Down Expand Up @@ -192,6 +217,7 @@ paths:

requestBody:
description: Parameters to create a new session
required: false
content:
application/json:
schema:
Expand All @@ -212,6 +238,8 @@ paths:
$ref: '#/components/responses/405MethodNotAllowed'
"406":
$ref: '#/components/responses/406Unacceptable'
"422":
$ref: '#/components/responses/422UnprocessableContent'
"429":
$ref: '#/components/responses/429TooManyRequests'
"500":
Expand Down Expand Up @@ -316,6 +344,7 @@ components:
status: 400
code: OUT_OF_RANGE
message: "Invalid value: ipv4Address.publicPort"

401Unauthorized:
description: Unauthorized
headers:
Expand All @@ -324,13 +353,20 @@ components:
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
$ref: "#/components/schemas/ErrorResponse"
examples:
InvalidCredentials:
GENERIC_401_UNAUTHENTICATED:
description: Request cannot be authenticated
value:
status: 401
code: UNAUTHENTICATED
message: "Request not authenticated due to missing, invalid, or expired credentials"
message: Request not authenticated due to missing, invalid, or expired credentials.
GENERIC_401_AUTHENTICATION_REQUIRED:
description: New authentication is needed, authentication is no longer valid
value:
status: 401
code: AUTHENTICATION_REQUIRED
message: New authentication is required.

403Forbidden:
description: Forbidden
Expand All @@ -340,30 +376,43 @@ components:
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
$ref: "#/components/schemas/ErrorResponse"
examples:
InsufficientPermissions:
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: "API consumer does not have sufficient permissions to perform this action"
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: "{{field}} is not consistent with access token."

404NotFound:
description: Subscriber Not Found
description: Not found
headers:
x-correlator:
$ref: "#/components/headers/X-Correlator"
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
$ref: "#/components/schemas/ErrorResponse"
examples:
SubscriberNotFound:
description: The specified parameters are either inconsistent (if multiple parameters are specified) or not currently associated with any customers of this service
GENERIC_404_NOT_FOUND:
description: Resource is not found
value:
status: 404
code: NOT_FOUND
message: "No device found for the specified parameters"
message: The specified resource is not found.
GENERIC_404_DEVICE_NOT_FOUND:
description: Device identifier not found
value:
status: 404
code: DEVICE_NOT_FOUND
message: Device identifier not found.

405MethodNotAllowed:
description: Method Not Allowed
Expand Down Expand Up @@ -399,6 +448,29 @@ components:
code: NOT_ACCEPTABLE
message: "The server cannot produce a response matching the content requested by the client through Accept-* headers"

422UnprocessableContent:
description: Unprocessable Content
headers:
x-correlator:
$ref: "#/components/headers/X-Correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorResponse"
examples:
GENERIC_422_DEVICE_IDENTIFIERS_MISMATCH:
description: Inconsistency between device identifiers not pointing to the same device
value:
status: 422
code: DEVICE_IDENTIFIERS_MISMATCH
message: Provided device identifiers are not consistent.
GENERIC_422_DEVICE_NOT_APPLICABLE:
description: Service is not available for the provided device
value:
status: 422
code: DEVICE_NOT_APPLICABLE
message: The service is not available for the provided device.

429TooManyRequests:
description: Too Many Requests
headers:
Expand Down Expand Up @@ -523,7 +595,8 @@ components:
* `ipv6Address`
* `phoneNumber`
* `networkAccessIdentifier`
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
NOTE 1: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
NOTE 2: for the Commonalities release v0.4, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
type: object
properties:
phoneNumber:
Expand Down Expand Up @@ -581,10 +654,10 @@ components:
example: "[email protected]"

PhoneNumber:
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, optionally prefixed with '+'.
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 '+'.
type: string
pattern: '^\+?[0-9]{5,15}$'
example: "123456789"
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+123456789"

Port:
description: TCP or UDP port number
Expand Down

0 comments on commit 0953681

Please sign in to comment.