Page Comparison

DRAFT

Attendees & Representation

...

• Existing PRs:
• • PR #55: Update CAMARA Mobile Device Identifier API.yaml
    • Proposed changes:
      • Separates API into two endpoints:
        • retrieve-identifier to obtain individual device details
        • retrieve-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
    • Fixes issues #47 and #30

MEETING UPDATE:

• • • PR is approved by the meeting

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

...

• • • Will be fixed by PR #55

MEETING UPDATE:

• • • <Update>Will be closed when PR#55 is merged

• • 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
      • ACTION: All to comment on above text within PR #55 if changes are required
        • All comments raised have been incorporated into PR

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

• • • Will be fixed by PR #55

MEETING UPDATE:

• • • <Update>Will be closed by PR#55

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

...

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

...