Agenda

The project's Antitrust Policy is linked from the LF and project websites. The policy is important when multiple companies, including potential industry competitors, are participating in meetings. Please review it, and if you have any questions, please contact your company’s legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.

• OTP-Validation

• SIM Swap

• Number Verification

Minutes

OTP - Validation

No update

Sim Swap

New requests

• #199 [SimSwap-Subscriptions]: Missing config.subscriptionMaxEvents and config.initialEvent

  • Fully agree for config.subscriptionMaxEvents but I do not understand how initialEvent can work.

    • checked with Max

  • Tagged for Fall25

• #198 [SimSwap-Subscriptions]: Missing description for "Subscription deleted by user"-notification

  • Tagged for Fall25

• #197 [SimSwap-Subscriptions]:data.phoneNumber cannot be required in notifications for sim-swap-subscriptions

  • Aligned with other subscription API

  • phoneNumber could be retrieved from the access token

  • Tagged for Fall25

• #195 [SimSwap-Subscriptions]:Non-defined type and format for startsAt

  • The startsAt in the sim-swap-subscriptions.yaml has not defined a type-property

  • Tagged for Fall25

Work in progress

• Issue #196 and PR#201: SUBSCRIPTION_DELETED event and INVALID_TOKEN_CONTEXT error missing in Fall24 v0.1.1 sim-swap-subscriptions

  • We can close the issue - to be checked with @Fernando Prado Cabrillo

Previous request

• #194 [SimSwap-Subscriptions]: 403 SUBSCRIPTION_MISMATCH cannot be returned

  • As the API only one event type this error cannot be triggered

  • Tagged for Fall25

• #190 What to do when local regulation regulations prevents 100 days maxAge in check operation?

  • Proposal to close it with The regular 400 with the OUT_OF_RANGE

• #181 Notification subscriptions reading logic

  • This is still valid

  • Tagged for Fall25

Number Verification

New

• #184 Support tempToken usage in AuthCodeFlow

  • Need clarification

  • for good practice better to create first an issue

  • Related to discussion in issue #181

• #183 [API Backlog] Voice Verification Code API proposal analysis

  • China Unicom API proposal considers the creation of an API that will allow applications to authenticate users (network subscribers) based on the possession factor validated by a phone call, providing a voice code similar to the SMS OTP.

    As feature is related to current scope of Number Verification (and SMS-OTP) working groups, feedback is required from this group before moving on with the API proposal.

  • Reference: New API Proposal - Voice Verification Code · Issue #160 · camaraproject/APIBacklog

    • To be maintain in a separate repository

    • We need to have maintainer(s) from companies supporting this API

    • We’re ok to host the discussion on this API within the Number Verification sub project call

    • We have to rename the sub project because it is too confusing.

      • Proposal for name: user authentification? anti fraud ? account Take Over Protection?

      • @Ludovic Robert will open an issue to discuss new sub project name.

• #182 Number Verification r1.4 tag

  • done

  • Issue to be close

• #181Temp Token flows

  • Probably ICM is the good audience for this discussion at least to be solved before to be propagated to API WG

  • Discussion CIBA MUST not become two-legged by AxelNennker · Pull Request #268 · camaraproject/IdentityAndConsentManagement is perhaps the starting point

    • @Axel Nennker will create an issue in Number Verification WG to apply in this API what is discussed in ICM.

• #180 Updated API description to be provided by Sub Project

  • closed

• #178 Check alignement with Commonalities for 422 errors.

  • No updated → As suggested in the issue proposal to close it