Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 3 Next »

DRAFT

Attendees & Representation

NameCompanyAttendee
Eric MurrayVodafone (moderator)


Sachin KumarVodafone
Kevin SmithVodafone
Alex FerreiraPhronesis
Matthew HornseyPhronesis
Matthew HandPhronesis
Sébastien SynoldIntersec
S, VigneshwaranCognizant
Karthik Raj RethinakumarCognizant
Manish JainCognizant
Huub AppelboomKPN
Rafal ArtychDT
Axel NennkerDT
Abhisek DasInfosys
Brian SmithShabodi
Umair Ali RashidShabodi
Foo Ming HuiSingtel
Vilim DuganicInfobip
Surajj JaggernathVodacom
Walid TrabelsiSofrecom (Orange)
Aleksander BrankovicIpification

Agenda

  • Review of previous meeting minutes
    • < Decision >
  • Review of Device Identifier API status
    • PRs
    • Issues
    • Discussions
  • AOB

Review of Device Identifier API status

  • Current "work in progress" version can be found here

PRs

Closed PRs

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

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

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".

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

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

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

PR #98: Update device-identifier.yaml

MEETING UPDATES

:

  • Approved and merged

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

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

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

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

 

  • Alternative wording proposed in this comment

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

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

  • 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

  • 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

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

  • 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

  • Issue #21: API Definition Terminology

    • Issue is out of date

MEETING UPDATES

:

    • Still open

ACTIONS:

Other New Issues

None

Discussions

Closed DiscussionsNone
Existing Discussions

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 will be held Friday 7th March 2025 @ 09:00 UTC using Zoom
  • No labels