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

Compare with Current View Page History

« Previous Version 10 Next »

DRAFT AGENDA

Attendees & Representation

TSC Members may indicate their attendance by marking an X in the column to the right.

Community members may use @name tag to mark their attendance below the table. 

RepresentativeOrganizationRole

Deutsche Telekom AG

TSC Chair, Active Maintainerx

Deutsche Telekom AG

Active Maintainer

Ericsson

Active Maintainer

KDDI

Active Maintainer

Orange

TSC Deputy Chair, Active Maintainerx

Radisys

EUC Representative

Summit Tech

EUC Representative

Telefonica

 not Active Maintainer

Tnot removedelefónica

Active Maintainer

Verizon

EUC Representative

Vodafone

TSC Deputy Chair

Vodafone

Active Maintainer

Vonage

Active Maintainer
George Glass

TM Forum

TM Forum Representative

TM Forum

TM Forum Representative

GSMA

GSMA Representative

GSMA

GSMA Representative

omLF Staff:

Community: 

Agenda

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

  • Review and approval of previous meeting minutes
  • Action Items Review
  • General Topics
    • Governance & project management issues
    • API Backlog
    • Commonalities
    • Identity & Consent Management
    • Release Management
  • Specific Topics
    • ...
  • Any Other Topics

Minutes

Review and approval of previous meeting minutes

Action Item Review

Governance & Project Management issues

  • EasyCLA Introduction (Casey Cain )
    • Concerns of the EasyCLA deployment have been resolved.
    • Suggested that we deploy EasyCLA on or  
      • LF Staff will be on standby to resolve any last-minute issues

API Backlog (Ricardo Serrano Gutierrez )

Commonalities (Rafal Artych )

  • Release 0.4.0-rc.1 - in preparation
    • All PRs missing in alpha merged, new fixes proposed (PR#229, PR#234, PR#236, PR#238)
      • Device object simplification  https://github.com/camaraproject/Commonalities/pull/233
        • Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios - Annex to API Design Guidelines 

        • networkAccessIdentifier  not removed from Device object, but not allowed in Commonalities 0.4.0 (Fall24 release)

        • Please review this PR
    • Target is to agree the RC.1 during Commonalities call on 24th of June and publish it during the week.

Identity & Consent Management (Jesús Peña  on behalf of Axel Nennker )

  • Create ICM Release Plan - #146
    • The team agreed to proceed with a release candidate directly, bypassing the alpha release, given the stability and closed scope of the current state.
  • Proposal to protect the /authorize endpoint for the Authorization Code Flow (Auth Code Flow) - RFC9101 - #128
    • Issue 128 will be excluded frm the current release, and the scope is now fully defined, allowing the team to proceed with generating the release candidate.
  • Is the service API meant to validate the content of the access token and compare this against the API parameters ? - #174
    • There is a recognition of the need for validation of access tokens but differing views on the feasibility and scope of standardization. Some participants suggested documenting standard claims in access tokens, while others emphasized the need to leave implementation details to individual operators.
  • OIDC authorization code flow and/or CIBA - #176
    • GSMA highlighted the need for clarity on which authorization flow operators should implement when onboarded in Open Gateway.
    • ICM feedback: The decision on which authorization flow to implement is more of a business decision than a technical one. Operators should support the flows defined by CAMARA and be compliant with ICM Security & Interoperability profile, but specific implementation can be decided based on business needs and regulatory requirements. For instance, an operator using only one API that requires a specific flow can choose to implement just that flow if it's allowed by the business decision of Open Gateway. For specific APIs with unique requirements, the auth flow to implement may be dictated by the API's functionality (such as Number Verification API) and be documented by the API subproject.

Release Management (Tanja de Groot Samuel Adeyemo )

  • Commonalities and ICM scope issues and alpha release PRs/releases are ready for TSC approval - Combined M0/M1 to be declared after that and notified to the all mailing list.
    • Question: How much time is needed for the TSC approval ?
    • Question: where do we post the "Request for scope and alpha review" announcement ? TSC mailing list or the RM mailing list ? If the latter, do we have sufficient TSC members on the RM mailing list ?
    • Delayed sending the message (per action previous TSC) to the all list due to an ongoing update of all the material (Update public release name - PR #35)
    • Proposal: combined M0/M1 message to be sent after TSC approval of Commonalities and ICM scope and alpha releases.
  • 15 APIs proposed for the Fall24 meta release sofar. All target initial (v0.x) public releases,. Possibly 1 or 2 may be proposed as stable public releases (NumberVerification and SimSwap)
  • Updated CHANGELOG_TEMPLATE and example PR available for review: https://github.com/camaraproject/ReleaseManagement/pull/36
  • Release management issues closed. One pending PR review 1 backlog item.
  • Upcoming tasks: start looking at the APIs proposed for the meta-release.

Any Other Business

Next Meeting

  • Next TSC Meeting will be on July 4th at 10:00 CEST / 08:00 UTC / 01:00 PST
  • Specific agenda topics backlog:
    • ...

Action items

  • No labels