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 Device Identifier API status

PRs

Closed 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 merged and r1.2 pre-release now published

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

:

  • Leave open for comments until end of Tuesday , and then merge before requesting final review of PR #94

:

  • PR approved and merged


PR #102: Reset version numbers to WIP following release r1.2 Update error documentation in info.description

  • Admin PR, to reset all version numbers to wip following publication of release candidate

MEETING UPDATES

:

  • PR approved and merged


Open Spring'25 PRs


PR #103 r1.3 Spring'25 Meta-Release M4 PR

  • M4 PR for release 0.2.0
  • No changes relative to 0.2.0-rc.1, other than version number updates

MEETING UPDATES

:

  • < Meeting update >


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

:

  • < Meeting update >

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

:

  • Cannot now be merged before Spring'25 meta-release. Leave open in case Axel Nennker wants to revise. Otherwise raise new issue on PPID introduction following Spring'25 meta-release.

:

  • < Meeting update >


Other New PRs

None

Issues

Closed 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

:

  • No view expressed either way during meeting. Leave open for comments until PR #94 is merged, and then close if no comments.

:

  • No view expressed. Keeping 429 errors in YAML for now. Issue closed.


  • 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

:

  • No comments during meeting

:

  • Issue closed by PR #101


Spring'25 Issues

None

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.

: 

  • No additional comments during last month
  • Leave open until either PR #92 is resolved or separate issue on PPID is opened

:

  • < Meeting updates >


New Discussions

None

Other Issues

AOB