Versions Compared

Version Old Version 1 New Version 2
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


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  

 

  • Now merged


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

 

  • Now merged


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

 

  • Now merged


Panel
borderColorred
borderStylesolid

PR #91: Update error response schema following Commonalities update

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

 

  • PR now merged


Panel
borderColorred
borderStylesolid

PR #93: Update test cases for meta-release

  • Updates test cases for retrieve-identifier path to be more comprehensive
  • Adds new test cases for the retrieve-type path

MEETING UPDATES

 

  • PR was approved and merged offline


Panel
borderColorred
borderStylesolid

PR #98: Update device-identifier.yaml

MEETING UPDATES

:

  • Approved and merged


Panel
borderColorred
borderStylesolid

PR #99: Update x-correlator definition in device-identifier.yaml

  • Commonalities r2.2 requires a pattern to be applied to the x-correlator header.

MEETING UPDATES

:

  • Approved and merged


Open Spring'25 PRs


Panel
borderColorred
borderStylesolid

PR #94: Release r1.2 (Spring'25 M3)

  • Publication of Spring'25 M3 release candidate v0.2.0-rc.1

MEETING UPDATES

 

  • Reviewed by Release Management (Tanja). Some changes to be made.
  • Request for compliance with Commonalities 0.5.0-rc.1 and ICM 0.3.0-rc.1
  • Issues / PRs raised following Release Management review:
    • ICM template: #98
    • X-Correlator header pattern: #99
    • Error documentation: #101


Panel
borderColorred
borderStylesolid

PR #101: Update error documentation in info.description

  • Update error documentation in info.description

    • Some errors
    • Some details are out of date
    • Better explanation of CAMARA or API specific errors
  • Needs to be approved and merged for Spring'25 meta-release

MEETING UPDATES

:

  • < Discussion >


Other Open 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 #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

 

  • < Discussion >


Other New PRs

None

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

  • Will be closed by PR#88

 

  • Closed by PR #88


Panel
borderColorred
borderStylesolid

  • Issue #96: Update ICM documentation in info.description

    • Section in YAML on "Authorization and authentication" is out of date following ICM r2,2 0.3.0-rc.1

MEETING UPDATES

:

    • Closed by PR #98


Panel
borderColorred
borderStylesolid

  • Issue #97: Update x-correlator definition

    • x-correlator definition is out of date following Commonalities r2,2 0.5.0-rc.1

MEETING UPDATES

:

    • Closed by PR #99


Spring'25 Issues


Panel
borderColorred
borderStylesolid

  • Issue #95: Should the 429 error response be documented in the YAML?

    • 429 errors are now no longer mandatory in the OAS definition
    • We do document 429 errors. Should we keep them?

MEETING UPDATES

:

    • < Discussion >


Panel
borderColorred
borderStylesolid

  • Issue #100: Description of 403 PERMISSION_DENIED error is outdated

    • Current text in info.description for `403 PERMISSION_DENIED" is as follows:

      If the end user has not consented to the API consumer getting access to the device identifier information, then a 403 PERMISSION_DENIED error is returned.

      This is only true for a 2-legged access token (i.e. client credentials), and is not the only reason for this error. More generally, for both 2- and 3-legged access tokens, this error would be returned if the access token did not have the correct scope for the endpoint being called.

    • Updated error description text proposed in PR #101

MEETING UPDATES

:

    • < Discussion >


Other Existing Issues


Panel
borderColorred
borderStylesolid

  • Issue #21: API Definition Terminology

    • Issue is out of date

MEETING UPDATES

:

    • Still open

ACTIONS:


Other New Issues

None

Discussions

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.

 

  • < Discussion >


New Discussions

None

Other Issues

  • None

AOB

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

...