Page Comparison

DRAFT

Attendees & Representation

...

• 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
   to
  • • • •  to obtain individual device details
        • retrieve-type
   to
  • • • •  to obtain type of device
      • Add scopes for each endpoint
  Add 
  • • • Add lastChecked
   field
  • • •  field to indicate when information about device was last confirmed correct
    • Fixes issues #47 and #30

• 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

• • 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

UPDATE: Rafal suggested newline issue was due to Windows newline format being used rather than Linux

• • PR #52: Rename project to CAMARA Mobile Device Identifier API
    • As agreed in Issue #46

• • 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

• • 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:

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 PR[   Update   ]
  • OPEN ACTIONS: 
    • Huub raised issue of primary / secondary MSISDNs and multi-SIM
      • ACTION: Eric to open discussion on multi-SIM scenarios
      • ACTION: Eric to update documentation on MSISDN being treated as secondary MSISDN by network

• Updated proposal
  • Issue #30: Defined scopes and meanings, being discussed in Issue The 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 UPDATE: 

• • • Agreement is to have two separate endpoints as follows:

      get-identifier with scope device-identifier:get-identifier which returns:

      • imeisv
      • imei
      • tac
      • model
      • manufacturer

      get-type with scope device-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  and retrieve-type 
    • AGREED to use retrieve-identifier  and retrieve-type 
      ACTION: Eric to raise PR

• Issue
  • • [   Update   ]

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

ACTION: Eric to update issue text (still open)

• Closed Issues

• • Issue #46:  Rename API title to CAMARA Mobile Device Identifier APIClosed by PR #52None

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

...