Page History

...

• EasyCLA vs Developer Certificate of Origin (DCO) (Casey Cain )
  • Debrief from CAMARA Board Meeting and leadership call CAMARA / LF / GSMA
  • GSMA / LF Catch-up  (June 5th) - push to use EasyCLA but no decision at this stage. We need to solve the GSMA issue in cooperation with GSMA & LF (Link to the , potentially based on the existing file-header).txt template. Target to close on this topic for next TSC  

...

• Adapt API Guidelines to ICM Security and Interoperability Profile -  https://github.com/camaraproject/Commonalities/pull/208

  • Agreed in ICM: https://github.com/camaraproject/IdentityAndConsentManagement/issues/160
• Alignment with Release Management and ICM for Release Candidate

Identity & Consent Management (Axel Nennker )

• Mark raised the point about diversity of using either authorization code flow and/or CIBA but we need to be careful. Straightforward question: Is it one of the either or both? do we mandate something?
  • Axel Nennker opened a discussion in ICM but with no real result of a global direction because it'is up to API implementation.
    • Sub-project can indicate if & how they are supported CIBA. I, Axel, do not know how they can indicate CIBA support in their YAML files. Also, openid discovery does not help because the metadata allows to express support for flows on a AZ global level through grant_types_supported not on an API level and not on an API endpoint level. Maybe subprojects can "indicate" support or requirement for CIBA somewhere - to be acted upon at onboarding time - but not on a technical level e.g. in the yaml file. So, telcos do not know which flow must be supported by an API and API consumers do not know which flow is supported or needed by an API by looking at the API's yaml file.
  • Diego González Martínez raised that we need to decouple the "how the developer get auth flow accepted" from "how we manage several possible auth flow for one API". Also said that from his point of view, discussion mentioned by Axel was about security schemas but not for the topic raised by Mark.
  • We can have a 'decision' at sub project level to 'device' which authorization flow will be supported. Need anyway to see how this 'information' will be communicated.
  • Move this discussion in ICM.
  Alignment with Release Management and
  • ICM
  for Release Candidate

...

• ICM examples was created
• Commonalities API Design Guidelines PR agreement was reached in ICM on June 5th. 
  Still being worked on but close to being finished
  • Axel & Diego discussed about the redundancy of information between ICM & Commonalities - minimum should be duplicated and links should be provided.
• CAMARA APIs access and user consent management adaption to CAMARA Security and Interoperability Profile finished.
  Still some discussion on what network authentication "authenticates", user vs subscriber discussion.
• Working on ICM release plan

...

• Progress of meta-release plan: Meta-release Fall24. 2 APIs were added.
• Commonalities and ICM M1 shifting into June; M2 still kept on 15/06
• Commonalities and ICM may have to prioritize the closing of main functional/technical issues or decide to move to next meta-release in order to reach an alpha release ASAP. 
• Release Management issues status: see 2024-06-04 Release WG Minutes
• The API release tracking page has been added to all API Sub Projects (thanks to Casey)
  • For new Sub Projects this page will be automatically created in the Confluence page structure. The RM documentation needs to be updated accordingly.
  • API Sub Projects can create their API tracker(s) by clicking on the button on the API Release Tracking page and following the guidelines. There should be one tracker for each API and its version they plan to publish in the meta-release
• Updated API-Readiness-Checklist PR available for review: Add API-Readiness-Checklist.md to RM project
• Actions:
  • Presented Present in all-hands call newt next week (June 13th), featuring an example for the release tracking pages
  • Send a communication to "all" mailing list to informe inform about the release management and associated action ;requested from Sub Project

Any Other Business

Next Meeting

• Next TSC Meeting will be on June 20th at 16:00 CEST / 14:00 UTC / 07:00 PST
• Specific agenda topics backlog:
  • No specific request but feel free to propose till next meeting.

Action items

•  Raise an issue in Sub Projects impacted by device object definition changes - https://github.com/camaraproject/Commonalities/issues/171 to analyse the impact Rafal Artych 
•  Release Management: Present in all-hands call next week (June 13th), featuring an example for the release tracking pages Samuel Adeyemo 13 Jun 2024 
•  Release Management: Send a communication to "all" mailing list to inform about the release management and associated action requested from Sub Project Samuel Adeyemo 13 Jun 2024 Cancelled and replaced by action on combined M0/M1 announcement email.