Device Identifier Meeting Minutes 2024-07-05

• PR #64: Incorporate Commonalities WG recommendations on Simplification of Device object
  • Add Commonalities WG recommended text on "Identifying a device from the access token"
  • Add 422 error response option
  • Explicitly define request body as optional

MEETING UPDATE:

• • <update>

ACTIONS:

• • <actions>

• PR #62: Update CAMARA Mobile Device Identifier API.yaml
  • Re-name X-Correlator to x-correlator

MEETING UPDATE:

• • <update>

ACTIONS:

• • ALL to provide any comments before end of month

• PR #63: Update Project README.md
  • Remove IMEI Fraud API from sub-project scope
  • Update links to CAMARA Wiki

MEETING UPDATE:

• • <update>

ACTIONS:

• • ALL to provide any comments before end of month

• PR #59: Create Device Identifier User Story
  • Adds user stories for the Retrieve Device Identifier and Retrieve Device Type use cases

MEETING UPDATE:

• • Now closed and merged

ACTIONS:

• • <actions>

• Issue #61: Simplification of Device object - short term solution
  • Commonalties proposes to revise DeviceObject
    • Should be optional, with 3-legged access token normally used to identify the mobile subscription
    • If 2-legged token is used, device object should be provided to API
    • Network Access Identifier (3GPP External Id) option to be removed as support not common

MEETING UPDATE:

• • Should be closed by PR #64

ACTIONS:

• • ALL to review and comment before next meeting

• Issue #21: API Definition Terminology
  • Issue is out of date

MEETING UPDATE:

ACTIONS:

• • Eric to update issue text (still open)

• Discussion #36: Alternative device identifiers
  • An alternative proposal is to salt the IMEI with an API consumer specific salt and then hash it
  • This would a less useful identifier (only useful to the API consumer) but easier to justify providing under an opt-out or no consent basis
  • Use cases for such an alternative identifier are not clear

AGREEMENT: Leave discussion open for now, but prioritise returning IMEI / IMEISV