Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

New PRs
Panel
  • PR #67: Update CAMARA Mobile Device Identifier API.yaml
    • Commonalities v0.4.0 allows x-correlator to be any string, and not restricted to being a uuid.
    • Therefore "format: uuid" needs to be removed from the definition.

MEETING UPDATE:

ACTIONS:

Panel
  • PR #66: Update CAMARA Mobile Device Identifier API.yaml
    • Update info section of OAS to comply with Commonalities guidelines v0.4.0

MEETING UPDATE:

ACTIONS:

Existing PRs
Panel
  • PR #64: Incorporate Commonalities WG recommendations on Simplification of Device object
    • Add Commonalities WG recommended text on "Identifying a device from the access token"
    • Add 422 error response option
    • Explicitly define request body as optional
    • Description updated to replace device with mobile subscription identifier as appropriate 

MEETING UPDATE:

ACTIONS:

Closed PRs
Panel
  • PR #63: Update Project README.md
    • Remove IMEI Fraud API from sub-project scope
    • Update links to CAMARA Wiki
    • Now merged
Panel
  • PR #62: Update CAMARA Mobile Device Identifier API.yaml
    • Re-name X-Correlator to x-correlator
    • Now merged

...

New IssuesNone
Existing Issues
Panel
  • Issue #21: API Definition Terminology
    • Issue is out of date

MEETING UPDATE:

ACTIONS:

    • Eric to update issue text (still open)
Closed Issues
Panel
  • Issue #61: Simplification of Device object - short term solution
    • Commonalties proposes to revise DeviceObject
      • Should be optional, with 3-legged access token normally used to identify the mobile subscription
      • If 2-legged token is used, device object should be provided to API
      • Network Access Identifier (3GPP External Id) option to be removed as support not common
      Issue now closed
    • Will be closed by PR #64
Closed Issues

Discussions

New DiscussionsNone
Existing Discussions
Panel
  • 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

AGREEMENT: Leave discussion open for now, but prioritise returning IMEI / IMEISV

Closed Discussions

None

...