Page Comparison

DRAFT

...

New Issues

None

Existing Issues

Panel

ACTIONS:

Closed Issues

None

...

New Discussions

None

Existing Discussions

Panel

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

Closed Discussions

None

Note
The IMEI Fraud API use case has been referred back to the GSMA OGW Product Workstream for re-evaluation. If the use case is still valid, it will be re-submitted the CAMARA API Backlog WG for re-approval. If approved, a separate repository will be created for the API. Discussions on this API can continue in these meetings if desired.

See API Proposal submission here. For MTN proposal for the initial YAML, see here.

Panel
#37: IMEI Fraud API Input Proposal is just to use a single "IMEI" field, which would accept either IMEI or IMEISV

Panel
34: What values should the IMEI Fraud API respond with to indicate reported ownership status? The GSMA appear to have an existing Device Check service, which includes an API. How does the CAMARA proposal differ from this? Kevin highlighted a GSMA video on their Device Check service.

Issue #48: Additional sub-project codeowner required
- UPDATE: No additional codeowner yet identified
Next meeting proposed to be held Friday 7th June 2024 @ 09:00 BST using Zoom

...