DRAFT
Attendees & Representation
Name | Company | Attendee |
---|---|---|
Eric Murray | Vodafone (moderator) | X |
Sachin Kumar | Vodafone | X |
Kevin Smith | Vodafone | |
Alex Ferreira | Phronesis | X |
Matthew Hornsey | Phronesis | |
Matthew Hand | Phronesis | |
Sébastien Synold | Intersec | |
S, Vigneshwaran | Cognizant | |
Karthik Raj Rethinakumar | Cognizant | |
Manish Jain | Cognizant | |
Huub Appelboom | KPN | |
Rafal Artych | DT | X |
Abhisek Das | Infosys | |
Brian Smith | Shabodi | |
Umair Ali Rashid | Shabodi | |
Foo Ming Hui | Singtel | |
Vilim Duganic | Infobip | |
Surajj Jaggernath | Vodacom | |
Walid Trabelsi | Sofrecom (Orange) |
Agenda
- Review of previous meeting minutes
- APPROVED
- Review of Device Identifier API status
- Discussion on requirements for IMEI Fraud
- AOB
Review of Device Identifier API status
- Current "work in progress" version can be found here
PRs
- New PRs:
- None
- Existing PRs:
- PR #55: Update CAMARA Mobile Device Identifier API.yaml
- Proposed changes:
- Separates API into two endpoints:
retrieve-identifier
to obtain individual device detailsretrieve-type
to obtain type of device
- Add scopes for each endpoint
- Add
lastChecked
field to indicate when information about device was last confirmed correct - Updates documentation on MSISDN being treated as secondary MSISDN by network
- Separates API into two endpoints:
- Fixes issues #47 and #30
- Proposed changes:
- PR #55: Update CAMARA Mobile Device Identifier API.yaml
- Closed PRs:
- None
Issues
- New Issues
- None
- Existing Issues
- Issue #47: Add ageOfInformation field to API response
- Follows on from Discussion #35
- Current API response gives no indication of when the physical device information was collected for the specified subscription identifier (e.g.
phoneNumber
). Dependent on the backend implementation, this information could have been collected some time earlier, and potentially be out of date - Current proposal is to introduce
lastChecked
response parameter, defined as follows:
- Issue #47: Add ageOfInformation field to API response
lastChecked:
description: Last time that the associated device identity was checked and updated if necessary
type: string
format: date-time
- Will be fixed by PR #55
MEETING UPDATE:
- <Update>
- ACTIONS:
- Huub raised issue of primary / secondary MSISDNs and multi-SIM
- ACTION: Eric to open discussion on multi-SIM scenarios
- Still open
ACTION: Eric to update documentation on MSISDN being treated as secondary MSISDN by network- Proposed text:
"In scenarios where a primary MSISDN is shared between multiple devices, each of which has its own "secondary" MSISDN (e.g. OneNumber), the MSISDN passed by the API consumer will be treated as the secondary MSISDN, and hence the identifier returned will be that of the relevant associated device. In such scenarios, the "primary" device (e.g. smartphone) is usually allocated the same primary and secondary MSISDN, and hence providing the primary MSISDN will always return the identity of the primary device." - COMPLETE: Text included in PR #55
- Proposed text:
- ACTION: All to comment on above text within PR #55 if changes are required
- ACTION: Eric to open discussion on multi-SIM scenarios
- Huub raised issue of primary / secondary MSISDNs and multi-SIM
- ACTIONS:
- Issue #30: Security Schemes and Scopes for Device Identifier API
- For the two use cases (retrieve all parameters or only tac / manufacturer / model), two separate scopes are required
- Should they be two scopes of same endpoint, or associated with separate endpoints
Agreement is to have two separate endpoints as follows:
get-identifier
with scopedevice-identifier:get-identifier
which returns:- imeisv
- imei
- tac
- model
- manufacturer
get-type
with scopedevice-identifier:get-type
which returns:- tac
- model
- manufacturer
- Issue #30: Security Schemes and Scopes for Device Identifier API
- Will be fixed by PR #55
MEETING UPDATE:
- <Update>
- ACTIONS:
- None
- ACTIONS:
- Issue #21: API Definition Terminology
- Issue is out of date
- Issue #21: API Definition Terminology
ACTIONS:
- Eric to update issue text (still open)
- Closed Issues
- None
Discussions
- New Discussions
- None
- Existing Discussions:
- 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
- Discussion #36: Alternative device identifiers
AGREEMENT: Leave discussion open for now, but prioritise returning IMEI / IMEISV
- Closed Discussions
- None
Other Issues
- Kevin raised the point that YAML schemas should use the common schemas defined in CAMARA_common.yaml where appropriate. Ideally, they could be directly referenced, though this can cause issues with some OAS viewers.
- ACTION: Kevin to check how OAS viewers handle external references
Discussion on IMEI Fraud API
This API will not be further discussed until API proponents attend the sub-project meetings.
For MTN proposal for the initial YAML, see here
- 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?
- Kevin highlighted a GSMA video on their Device Check service.
- #37: IMEI Fraud API Input
AGREEMENT: MTN / Huawei will join sub-project meetings from next year, so can then drive these discussion
AOB
- Issue #48: Additional sub-project codeowner required
- UPDATE: No additional codeowner yet identified
- Next meeting to be held Friday 5th April 2024 @ 09:00 GMT
- Meeting scheduled for Friday 22nd March cancelled due to holidays
- One day, meetings will be held using the LFX Zoom service, but not yet