...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Attendees & Representation
Name | Company | Attendee |
---|---|---|
Eric Murray | Vodafone (moderator) | X |
Sachin Kumar | Vodafone | X |
Kevin Smith | Vodafone | X |
Alex Ferreira | Phronesis | |
Matthew Hornsey | Phronesis | |
Matthew Hand | Phronesis | |
Sébastien Synold | Intersec | |
S, Vigneshwaran | Cognizant | |
Karthik Raj Rethinakumar | Cognizant | |
Manish Jain | Cognizant | |
Huub Appelboom | KPN | X |
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) |
...
- Review of previous meeting minutes
- [ DECISION ]
- APPROVED
- Review of Device Identifier API status
- Discussion on requirements for IMEI Fraud
- AOB
...
- Current "work in progress" version can be found here
PRs
- New PRs:
- PR #55: Update CAMARA Mobile Device Identifier API.yaml
- Proposed changes:
- Separates API into two endpoints:
retrieve-identifier
- Separates API into two endpoints:
to - Proposed changes:
- to obtain individual device details
retrieve-type
to - to obtain type of device
- Add scopes for each endpoint
Add - Add
lastChecked
- Add
field
- PR #55: Update CAMARA Mobile Device Identifier API.yaml
- Existing PRs:
- None
- Closed PRs:
- PR #54: Update API to match common schema definitions
- Updates
Device
schema to match that in CAMARA_common.yaml - Identifying device by IPv6 must be single IPv6 address
- Updates
- PR #54: Update API to match common schema definitions
- PR #53: Add X-Correlator to OAS and update linting rules
- Requirement in latest version of API Design Guidelines
- Linting rules agreed in Commonalities, but still not merged
- PR #53: Add X-Correlator to OAS and update linting rules
UPDATE: Rafal suggested newline issue was due to Windows newline format being used rather than Linux
- PR #51: Add Identity & Consent header
- Adds mandatory identity & consent header to API information
- This will be a requirement of v0.1.0 of Identity & Consent documentation
- PR #51: Add Identity & Consent header
- 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
- Issue #47: Add ageOfInformation field to API response
ISSUE UPDATE:
- Current proposal is to introduce
lastChecked
response parameter, defined as follows:
- Current proposal is to introduce
lastChecked:
description: Last time that the associated device identity was checked and updated if necessary
type: string
format: date-time
ISSUE UPDATE:
- Will be fixed by PR #55
MEETING UPDATE:
- Huub proposed
lastRecorded
AGREED
ACTION: Eric to raise PRNone
- Huub proposed
- 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:
- Proposed text:
- ACTION: Eric to open discussion on multi-SIM scenarios
Issue #30: Defined scopes and meanings, being discussed in Issue The - Huub raised issue of primary / secondary MSISDNs and multi-SIM
- "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."
- ACTION: All to comment on above text within PR #55 if changes are required
- ACTIONS:
- Updated proposal
- 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
- Issue #30: Security Schemes and Scopes for Device Identifier API
ISSUE UPDATE:
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 UPDATE:
- Will be fixed by PR #55
MEETING UPDATE:
- Alex supports two endpoints
- Kevin suggests
retrieve-identifier
andretrieve-type
- AGREED to use
retrieve-identifier
andretrieve-type
ACTION: Eric to raise PR
- Issue
- None
- ACTIONS:
- None
- ACTIONS:
- Issue #21: API Definition Terminology
- Issue is out of date
- Issue #21: API Definition Terminology
ACTIONACTIONS:
- Eric to update issue text (still open)
- Closed Issues
- None
Discussions
- New Discussions
- None
...
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
...
- Issue #48: Additional sub-project codeowner required
- UPDATE: No additional codeowner yet identified
- Next meeting to be held Friday 23rd February 8th March 2024 @ 1609:00 GMT.
- One day, meetings will be held using the LFX Zoom service, but not yet
...