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

Align device object with Guidelines Issue #228 #237

Merged
merged 1 commit into from
Jul 25, 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
51 changes: 47 additions & 4 deletions code/API_definitions/location-retrieval.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -54,13 +54,36 @@ info:

# Authorization and authentication


[Camara Security and Interoperability Profile](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md) provides details on how a client requests an access token.

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 device from the access token

This specification defines the `device` object field as optional in API requests, specifically in cases where the API is accessed using a 3-legged access token, and the device can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the device information associated with the access token used to invoke the API.

## Handling of device information:

### Optional device object for 3-legged tokens:

- When using a 3-legged access token, the device associated with the access token must be considered as the device for the API request. This means that the device object is not required in the request, and if included it must identify the same device, 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 device identification from the access token, if available.
- If the API request additionally includes a `device` object when using a 3-legged access token, the API will validate that the device identifier 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 device information in the request does not match the token.

### Error handling for unidentifiable devices:

- If the `device` object is not included in the request and the device 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 single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the `device` object MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens.

# Further info and support

(FAQs will be added in a later version of the documentation)
Expand Down Expand Up @@ -97,11 +120,33 @@ paths:
parameters:
- $ref: '#/components/parameters/x-correlator'
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/RetrievalLocationRequest'
required: true
examples:
INPUT_PHONE_NUMBER_MAX_AGE:
summary: Phone number and maxAge
description: Retrieve location for a device identified by a phone number, providing a maxAge
value:
device:
phoneNumber: "+123456789"
maxAge: 120
INPUT_IP_ADDRESS_V4:
summary: IPv4 address without maxAge
description: Retrieve location for a device identified by an IPv4 address, without an indication for maxAge
value:
device:
ipv4Address:
publicAddress: 123.234.1.2
publicPort: 1234
INPUT_NO_DEVICE_AND_MAX_AGE:
summary: Device not provided, only maxAge
description: The device has to be deducted from token
value:
maxAge: 120

responses:
'200':
description: Location retrieval result
Expand Down Expand Up @@ -161,8 +206,6 @@ components:
maxAge:
type: integer
description: Maximum age of the location information which is accepted for the location retrieval (in seconds). Absence of maxAge means "any age" and maxAge=0 means a fresh calculation.
required:
- device

Device:
description: |
Expand Down
35 changes: 34 additions & 1 deletion code/API_definitions/location-verification.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,30 @@ info:

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 device from the access token

This specification defines the `device` object field as optional in API requests, specifically in cases where the API is accessed using a 3-legged access token, and the device can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the device information associated with the access token used to invoke the API.

## Handling of device information:

### Optional device object for 3-legged tokens:

- When using a 3-legged access token, the device associated with the access token must be considered as the device for the API request. This means that the device object is not required in the request, and if included it must identify the same device, 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 device identification from the access token, if available.
- If the API request additionally includes a `device` object when using a 3-legged access token, the API will validate that the device identifier 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 device information in the request does not match the token.

### Error handling for unidentifiable devices:

- If the `device` object is not included in the request and the device 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 single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the `device` object MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens.

# Further info and support

(FAQs will be added in a later version of the documentation)
Expand Down Expand Up @@ -120,6 +144,16 @@ paths:
latitude: 50.735851
longitude: 7.10066
radius: 50000
INPUT_NO_DEVICE:
summary: Device not provided
description: The device has to be deducted from token
value:
area:
areaType: CIRCLE
center:
latitude: 50.735851
longitude: 7.10066
radius: 50000
responses:
"200":
description: Location verification result
Expand Down Expand Up @@ -283,7 +317,6 @@ components:
maxAge:
$ref: "#/components/schemas/MaxAge"
required:
- device
- area

VerifyLocationResponse:
Expand Down