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 guidance for multi-SIM scenarios #378

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

eric-murray
Copy link
Collaborator

What type of PR is this?

  • documentation

What this PR does / why we need it:

Provides guidance on using the QoD APIs in multi-SIM scenarios

Which issue(s) this PR fixes:

Fixes #376

Special notes for reviewers:

This guidance will need to be updated when Commonalities Issue #302 is resolved

Changelog input

 release-note
 - Add guidance for multi-SIM scenarios

Additional documentation

None


In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device.

Possible workarounds in such a scenario include:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Possible workarounds in such a scenario include:
Possible mitigation in such a scenario include:


Possible workarounds in such a scenario include:
- Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
- Identifying the intended device from a unique identifier for that device, such as its source IP address and port
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- Identifying the intended device from a unique identifier for that device, such as its source IP address and port
- Identifying the intended device from a unique identifier for that device, such as its source IP address and port. This applies as well as the recommended value for the `login_hint` parameter of the OIDC CIBA flow.

Possible workarounds in such a scenario include:
- Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
- Identifying the intended device from a unique identifier for that device, such as its source IP address and port
- Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device
- Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available.

In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device.

Possible workarounds in such a scenario include:
- Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
Copy link
Collaborator

Choose a reason for hiding this comment

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

If we finally approve in Commonalities that a device identifier in request body is incompatible with a 3-legged access token (and "In this case, a 422 UNNECESSARY_IDENTIFIER error code MUST be returned"), then we can remark that

Suggested change
- Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
- Using the authorisation code flow to obtain an access token, which will automatically identify the intended device. Moreover, in this case, no other device identifier must be included in the request.

Copy link
Collaborator

@jlurien jlurien left a comment

Choose a reason for hiding this comment

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

In line with the latest consensus in camaraproject/Commonalities#324, I have included some suggestions. They will apply to all the 3 APIs with minor adjustments.


# Multi-SIM scenario handling

In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device.
Copy link
Collaborator

@jlurien jlurien Nov 26, 2024

Choose a reason for hiding this comment

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

Another possibility is to apply the service to all the devices associated to the phone number:

Suggested change
In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device.
In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to all the devices associated with the phone number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document current behavior for devices with multiple SIMs
2 participants