Versions Compared

Version Old Version 7 New Version 8
Changes made by

Eric Murray

Eric Murray

Saved on

Key

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

DRAFT

Attendees & Representation

...

Closed PRs

None

Existing PRs


Panel
borderColorred
borderStylesolid

PR #87: Update Device object handling and description

  • Other APIs passing a Device object do this by passing a separate parameter named device, even if that is the only object passed in the request.

  • This PR:

    • Updates the Device Identifier API to use this pattern
    • Updates documentation on identifying the device from the access token following the current agreement in Commonalities
    • Updates the API error responses following the current agreement in Commonalities
    • Removes 406, and 5XX errors from the OAS definition, as these errors do not need to be explicitly documented and are not relevant to the API use case

MEETING UPDATES

:

  • Add examples for different request body scenarios
  • Leave open for comments until next meeting

:

  • Updates since last meeting
    • Request body scenario examples added
    • 406 and 5XX errors removed
    • Remaining error examples updated
  • PR to remain open for comments until  


Panel
borderColorred
borderStylesolid

PR #88: Update LastChecked description

  • Update description for lastChecked field to make its meaning clearer

  • Fixes Issue #80

MEETING UPDATES

:

:

  • Ramesh happy with proposed wording change
  • DECISION: PR can be approved and merged


New PRs


Panel
borderColorred
borderStylesolid

PR #89: Remove multi-sim text

  • Multi-SIM support is not well-understood and should be "solved" for all CAMARA APIs.

  • Multi-SIM support was discussed in several CAMARA API subprojects without solution.

  • For interoperability reasons API providers should handle the Multi-SIM case in the same manner.

MEETING UPDATES

:

  • Eric Murray to propose more generic text describing different options for multi-SIM scenario handling


Panel
borderColorred
borderStylesolid

PR #90: Use identifier instead of identity

  • Use the term "identifier" if an identifier is talked about.

  • Operators often use the term "identity" when in fact it is an "identifier". Generally an "identity" and an "identifier" are different. There a several definitions for "identity" e.g. in OIDF, IETF and W3C e.g. "a collection of claims". But identity is never used when an identifier is meant.

  • I think we should avoid operator-speak and use "identifier" if it is an "identifier".

Note

IMEI really is defined as "International Mobile Equipment Identity". See TS 22.016.

MEETING UPDATES

:

  • IMEI definition reverted to International Mobile Equipment Identity
  • PR approved and merged


Panel
borderColorred
borderStylesolid

PR #91: Update error response schema following Commonalities update

Note

This PR now overlaps with changes proposed in PR #87. It is proposed to merge PR #87 and then fix this PR as required to implement the updated CAMARA error response schema.

MEETING UPDATES

:

  • Wait for PR #87 to be merged and then fix any conflicts with this one.
  • Goal is to approve and merged the updated PR before next meeting


Panel
borderColorred
borderStylesolid

PR #92: Use scopes and introduce a pairwise pseudonymous identifier

  • This PR proposes two changes to the API definition:

    • Introduction of a third device identifier ppid, which is a pairwise pseudonymous identifier for the device
    • Control of fields included in the response by individual scopes, rather than by a single scope covering all possible response fields

MEETING UPDATES

:

  • Discussion:
    • PPID as third device identifier is fine, but should be introduced as additional endpoint rather than controlling through scopes
    • A better description of the properties of a PPID is required, in addition to the external link
      • For example, if a new SIM (from the same MNO) is used in the physical device, should the PPID be re-generated?
  • Eric Murray to comment in PR


Issues

Closed Issues

None

Existing Issues


Panel
borderColorred
borderStylesolid

Issue #80: Purpose of the lastChecked field in the response?

  • lastChecked response field is not clear to all potential API consumers
  • This is the last time that the API provider checked which IMEI was being used by a specific MSISDN
    • Could be "now", or could be some minutes ago. Implementation dependent.
  • How to fix?
    • Rename field (maybe to lastConfirmed)?
    • Better description in YAML itself?

MEETING UPDATES

:

  • Leave issue open for now. Axel Nennker to review how this would be supported by DT.

:

  • Eric Murray to propose updated description for this field

  • To be fixed by PR#88: Update LastChecked description


Panel
borderColorred
borderStylesolid

  • Issue #21: API Definition Terminology

    • Issue is out of date

MEETING UPDATES

:

    • Still open

ACTIONS:

    • Eric to update issue text (still open)


New Issues

None

...

Closed DiscussionsNone
Existing Discussions


Panel
borderColorred
borderStylesolid

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

MEETING UPDATES:

:

  • Discussion updated by Axel Nennker with proposal to include PPID as a 3rd device identifier that can be requested (in addition to IMEI or TAC)

:

  • Axel Nennker to review and make proposal for additional physical device identifier

:

  • No update

  • Discussion has been updated. Please review.


New Discussions

None

Other Issues

  • None

AOB

  • Next meeting proposed to be held Friday 7th February 2025 @ 09:00 UTC using Zoom

...