Page History

...

...

• 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

...

• New proposal how to manage "API Families" as Sub Projects with one lead repository and multiple API "family member" repositories (#142) (Herbert Damker )
  • See issues about problem statement and proposed solution. It is a replacement for the previous proposal in #135 (working groups across Sub Projects).
  • Proposed next steps: close #135 and create a PR for the new proposal to enhance ProjectStructureAndRoles.md accordingly (Herbert Damker )
  • Discussion
    • Comments to the issue should be provided before June 11th.
    • EdgeCloud provides an example with SimpleEdgeDiscovery
    • Question related to the Wiki pages for NV, SIM SWap & OTP - if it becomes a family we will need to have one wiki page. Anyway we need to be consistent between the wiki structure & the GitHub organization.

• Proposal for new API Project lifecycle approach (Sandbox + Incubated) (#129)
  • Proposal to postpone until the previous point is done (#142)

...

• 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
  • 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 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.
    • 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

...

• 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 in all-hands call newt week (June 13th) featuring an example
  • Send a communication to all mailing list to informe about the release management and associated action;

...