Page Comparison

DRAFT AGENDA

Attendees & Representation

LF Staff:

Agenda

• 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

• Minutes of previous TSC meeting: 2024-11-21 TSC Minutes

  • No comments - minutes approved

Action Item Review

• See home page Technical Steering Committee for current list of open action items

  • …One open action point for Tanja de Groot postponed to next TSC

Governance & Project Management issues

• Agreed concept between CAMARA and GSMA for API Descriptions

  • Presentation by Markus Kümmerle
    

    View file
    name Concept for API descriptions.pdf

    • Proposal for consistent presentation of API descriptions

      • Updated API categories

      • API names defined in API Backlog table

      • Each API will have an associated API description, based on TM Forum template

    • Tanja de Groot raised point of keeping information up to date. Automation and reuse of information from GitHub preferred.

• Sandbox / Incubated / Graduated Approach for API Repositories

  • ProjectCharter and ProjectStructureAndRoles updated (PR #161 merged)

  • Next Steps:

    • Work on API-Onboarding-and-Lifecycle.md (aka API-Onboarding)

      • not yet started, will be based on Proposal for the lifecycle of API Repositories with Sandbox/Incubated/Graduated/Archived

    • Restructuring/sorting of CAMARA Wiki pages (Independent Sandboxes vs Sub Projects with Incubated API Repositories)

      • see proposal below

    • Define first round of Incubated API Repositories

      • Candidates are all API repositories from Fall24 meta-release which have

      • Candidate proposals to come from API Backlog WG

    • Question to CAMARA Board: best opportunities to communicate / announce the first round of incubated APIs

  • Proposal for Wiki structure:

    • Requirements

      • Structure will fit for Sub Project with one API Repository and Sub Projects with multiple API Repositories (current structure works only for 1:1)

      • API Repository are first-class citizens beside Sub Projects, not be hidden underneath Sub Projects

      • Graduated and Incubated API Repositories are prominently placed and can be viewed on one glance

      • Sandbox API Repositories are separated into an own section

    • Proposed structure

      • Every API Repository has an own wiki page (similar to current Sub Project pages, with content of README in GitHub)

        • Parent page for the release trackers

        • If part of Sub Project (default for Incubated/Graduated): Link to the Sub Project wiki page for organizational information

        • If an Independent Sandbox: contains all needed information to get involved and contribute

      • Sub Projects Wiki pages

        • have a list of their API repositories

        • all information relevant across the API Repositories (meeting information & minutes, scope of the sub project, list of Maintainers, main contacts, …).

        • there could be an overview of released API versions (based on the release trackers within the API Repositories, so automatically updated)

      • The API Repository wiki pages will be sorted into the three top level sections, following today's “Sub Project” top level. The top level section will be then:

        • Getting Started with CAMARA

        • CAMARA Working Groups

        • CAMARA Sub Projects

        • (Graduated CAMARA API Repositories - to be added later)

        • Incubated CAMARA API Repositories

        • Sandbox API Repositories

        • (Archived API Repositories - to be added later)

    • New structure would be set-up by LF/CAMARA admin team

      • Once in place, each Sub Project and (Sandbox) API Repository can make further updates

API Backlog (Jorge Garcia Hospital)

• No new API proposals forwarded to TSC for todays meeting

• Consent URL API is pending as discussed within last TSC. From ICM 04/12:

  • Identified gap in current CAMARA standard for consent management when captured in a different device than targeted device.

  • TEF proposal focused on creating an ad-hoc mechanism separated from API access token generation.

  • DT proposing a OIDC adapted option (to be reviewed).

  • Proposal (TBC): To create a working group focussed sub-team within ICM to discuss the most optimal solution ¿?

    • Proposal is agreed

• Reminder that backlog table is available and updated (weekly):

  • https://github.com/camaraproject/APIBacklog/blob/main/documentation/APIbacklog.md

Commonalities (Rafal Artych )

• Status r2.1 (with 0.5.0-alpha.1):

  • Release PR ready for final review, main CHANGELOG points:

  • Added

    • Common 'area' data-type added to CAMARA_common.yaml by @tlohmar in #315

    • Security and Privacy Considerations for Filtering in API Design Guidelines by @rartych in #331

    • Security scheme added to CAMARA_common.yaml by @rartych in #335

    • VERSION.yaml file added to indicate Commonalities version by @rartych in #339

    • Filtering for boolean guideline and examples in API Design Guidelines by @rartych in #336

    • Guidelines on the coverage of error codes in API-Testing-Guidelines by @jlurien in #343

  • Changed

    • Normalization of error status and code allowed values using enum by @PedroDiez in #316

    • Guidelines for subscription and event notification in API Design Guideliness by @bigludo7 in #313 main changes:

      • updated terminationReason in event notification type "subscription-ends"

      • updated description of sink and sinkCredential attributes for subscription

      • added rules for subscriptions with device identifier attribute

      • added section 11.7 Resource access restriction relevant to subscriptions

      • added clarification on expiresAt attribute for subscription

    • Updated error codes and changed info.description template for device / phone number identifiers in Appendix A in API Design Guideliness by @eric-murray in #324

    • Guidelines regarding mandatory error status and alignment of error codes related to identifiers in API Design Guideliness by @PedroDiez in #329

  • Fixed

    • Clarification on api-name, filenames and servers object by @rartych in #333

    • Removed broken link to DPV document and updated broken links to CAMARA wiki by @rartych in #347

• To be added before RC:

  • Remaining PRs:

    • https://github.com/camaraproject/Commonalities/pull/277

    • https://github.com/camaraproject/Commonalities/pull/325

    • https://github.com/camaraproject/Commonalities/pull/330

  • Cleanup and slim down design guidelines document

  • Linting rules update

  • Corrections to alpha version

• Volunteers needed to migrate linting rules to reusable workflows:https://docs.github.com/en/actions/sharing-automations/reusing-workflows

  • Review and test the workflows

  • Should we use https://github.com/camaraproject/.github or dedicated repository as workflows repository?

    • To be decided by the team who will set up the functionality

• Question from Toshi Wakayama as to which of above listed changes are breaking changes

  • Updated error codes and subscription / event notification may be a breaking change for some APIs

  • Each sub-project to do their own review of impact

  • Rafal Artych to prepare initial analysis as to which changes will be breaking, which may be breaking, and which will not be breaking, preferable until the All-hands Call next week Thursday

Identity & Consent Management (Axel Nennker Jesús Peña García-Oliva )

• r2.1 created (with 0.3.0-alpha.1)

  • Meta-release Spring25

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/224

  • see above within APIBacklog discussion, work on solution will be continued within ICM

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/215

• Sender-Constrained Access Tokens with DPoP

  • https://github.com/camaraproject/IdentityAndConsentManagement/issues/125

  • https://github.com/camaraproject/IdentityAndConsentManagement/pull/225

Release Management (Tanja de Groot)

• r2.1 PR for RM Release Management repository approved and released.

• Spring25 meta-release

  • 23 API have provided their release tracker

  • Commonalities: M2 rc 0.5.0-alpha.1 PR ready. M2 with release candidate expected by Dec 9th

    • Rafal Artych expects M2 with release candidate to be later

  • ICM: 0.3.0-alpha.1 version released as r2.1 done Dec 3rd. now available

  • M2: Risk of delay due to delayed M1- need more time to cover all changesproposal to fix M2 date with the availability of the 2 release candidates of Commonalities and ICM.

  • M3: Risk of being delayed into 2025.

    • Can review at next TSC meeting on 19 Dec 2024

• Fall24 meta-release

  RM repo r2.1 was released

  • M6 was announced on RM mailing list & codeowners list following the release of the RM repo

  • Fall24 meta-release is now closed.

  • Patch updates of APIs can be done as needed. Discussion is if it should be a new API release tracker or not (issue #125).

    • Spring25 updated tracker allows patch releases to be listed

Any Other Business

• ...None

Next

Meeting”

• Next TSC Meeting will be on December 19th, 15:00 UTC (16:00 CET, 07:00 PT)

• Specific agenda topics backlog:

  • ...

  • ... 

Action items

• • None yet 

Action items

•  Rafal Artych to prepare initial analysis as to which changes will be breaking, which may be breaking, and which will not be breaking 12 Dec 2024
•  Herbert Damker create issue(s) within Governance for the next steps to execute the Sandbox / Incubated approach