Page Comparison

Attendees & Representation

Agenda

• Review of previous meeting minutes
• Discussion on requirements for IMEI Fraud
• Review of Device Identifier API status
• AOB

Discussion on IMEI Fraud API

• See API Proposal submission here
• Open Discussions:
  • #37: IMEI Fraud API Input
    • Proposal is just to use a single "IMEI" field, which would accept either IMEI or IMEISV
  • #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?

AGREEMENT: MTN / Huawei will join sub-project meetings from next year, so can then drive these discussion

Review of Device Identifier API status

• Current "work in progress" version can be found here

...

• Open PRs:
  • PR #44: Create README.md

AGREEMENT: PR can be merged

• New Issues
  • None

• Open Issues:
  • Issue #40:  Proposed renaming of device identifier API
    • Using sub-project three letter code dvi as API name not scalable as additional APIs are added to the sub-project
    • Proposal is to use device-identifier as the new nameTo be agreed in meeting

AGREEMENT: basepath API name to be changed to device-identifier
ACTION: Eric to open PR

Huub: Suggests to rename YAML title to "CAMARA Mobile Device Identifier API"
ACTION: Eric to open issue to discuss API title

• • Issue #30: Defined scopes and meanings, being discussed in Issue 
    • Proposal is to have two scopes - one for all information, and one for TAC, Make and Model only
• Brian: Should separate paths be defined rather than have a single path which accepts two scopes?
Please

ACTION: Eric to update issue with third option of separate endpoints for all information or only TAC / manufacturer / model information
ACTION: All, please comment if you have a view, whether from point of view of API consumer, provider or end user

• • Issue #21: API Definition Terminology
    • Issue is out of date
    • ACTION: Eric to update issue text (still open)

• Open Discussions:
  • Discussion #35: Age of information or device connectivity status
    • Vodafone's implementation checks in "real time", so device must be connected and "age of information" would be 0
      • The current API design implicitly assumes these values
    • Other implementor's solutions may rely on cached data possibly be out of date, and hence require such a field

AGREEMENT: Adding an "ageOfInformation" field

...

would be useful

ACTION: Eric to open issue to finalise agreement
ACTION: All, please continue to comment if you have a view, after which discussion will be closed

• • 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
Please comment if you have a view

No time for full discussion 

ACTION: All to review current discussion and comment on value of salted / hashed IMEI for different use cases of interest to them

AOB

• Additional sub-project codeowners required - any volunteers?
  • ACTION: Eric to open issue requesting new codeowners
• Meeting scheduled for Friday December 29th will be cancelled. Next meeting to be held Friday 15th December 2023 12th January 2024 @ 09:00 GMT.
• One day, meetings will be held using the LFX Zoom service, but not yet