Agenda

• Create ICM Release Plan - #146

• Proposal to protect the /authorize endpoint for the Authorization Code Flow (Auth Code Flow) - RFC9101 - #128

• Proposed text on network-based authentication - #173

• Is the service API meant to validate the content of the access token and compare this against the API parameters ? - #174

• OIDC authorization code flow and/or CIBA - #176 

Minutes

•  

  • @Jesús Peña García-Oliva  shared the agenda prior to the meeting and received no feedback, implying consensus.

  • Priority is on discussing the release plan and related tasks to comply with the release management working group.

Topic Create ICM Release Plan - #146

•  

  • The main topic was whether the alpha release is mandatory.

  • @Tanja de Groot explained that the alpha release is primarily for API subprojects to start working with and must be approved by the TSC.

  • @Herbert Damker highlighted that the alpha release allows for feedback and significant changes, while the release candidate should only involve bug fixes.

  • @Jesús Peña García-Oliva expressed that the scope is almost closed, implying minimal expected changes. He suggested skipping the alpha release and directly generating the release candidate.
    @Shilpa Padgaonkar and @Herbert Damker both supported skipping the alpha release if there are no significant changes expected.

•  

  • Also, given the delay from the original schedule, the consensus leaned towards creating a release candidate due to the stable state of the scope and dependencies with Commonalities.

  • @Jesús Peña García-Oliva agreed to generate a pull request for the release candidate and handle the process during his upcoming vacation, with @Axel Nennker or @Sébastien Dewet continuing his work.

•  

  • @Jesús Peña García-Oliva Create a pull request to generate the release candidate. → UPDATE (20/06): DONE. https://github.com/camaraproject/IdentityAndConsentManagement/pull/177

  • Team: Review the pull request and ensure smooth transition of tasks during Jesús's vacation.

•  

  • The team agreed to proceed with a release candidate directly, bypassing the alpha release, given the stability and closed scope of the current state.

Topic Proposal to protect the /authorize endpoint for the Authorization Code Flow (Auth Code Flow) - RFC9101 - #128

•  

  • @Jesús Peña García-Oliva introduced the next topic concerning issue 128.

  • The issue involves a proposal from Telefónica to support the use of RFC 9101.

  • This proposal aimed to address potential problems identified in previous discussions, including issues raised by other members (Vonage, @Ming Hui Foo , etc...).

•  

  • During the last call, there was no consensus on mandating the implementation of RFC 9101.

  • The proposal was to require both clients and operators to implement this RFC to effectively address the identified problems.

  • Feedback from participants, including Orange and Ericsson, indicated a preference against mandating this support at present.

•  

  • @Jesús Peña García-Oliva suggested excluding RFC 9101 from the scope of the next meta release also considering the time constraints.
    @Shilpa Padgaonkar agreed, recommending that the issue be closed for now and reopened in the future if necessary.

•  

  • The group agreed to close issue 128 for the current release cycle.

  • @Jesús Peña García-Oliva will close the issue after the call, ensuring the scope for the next release is finalized.

•  

  • @Jesús Peña García-Oliva Close issue 128 and finalize the scope for the next release. → UPDATE (20/06): DONE.

•  

  • Issue 128 will be excluded from the current release, and the scope is now fully defined, allowing the team to proceed with generating the release candidate.

Topic Proposed text on network-based authentication - #173

•  

  • @Jesús Peña García-Oliva introduced the next topic, which involves reviewing a pull request affecting documentation included in the upcoming meta release. The pull request was submitted by @Axel Nennker to clarify the network-based authentication mechanisms in the CAMARA-API-access-and-user-consent.md document.

  • Jesús is supportive of Axel's proposal and mentioned his own minimal suggestions, which are mainly formatting changes and making terminology more generic (e.g., changing "MSISDN" to "phone numbers"). Jesús suggested a review deadline by the end of the week, after which the pull request could be merged if there were no further comments.

  • Axel also mentioned in the PR that the glossary of terms in the document should be reviewed. However, he proposed this as a separate pull request. Jesús agreed, noting that reviewing and updating the glossary would require a thorough review of the entire document to ensure consistency.

•  

  • The team was asked to review pull request 173 and provide feedback by the end of the week. If no further comments are received, the pull request will be merged.

  • @Herbert Damker Agreed with the proposed plan.

  • No further comments from other participants.

•  

  • Team: Review pull request 173 by the end of the week.

  • @Jesús Peña García-Oliva Summarize this discussion in the meeting minutes and proceed to merge the pull request if no additional feedback is received. → UPDATE (21/06): DONE.

•  

  • The pull request will be reviewed and potentially merged by the end of the week, ensuring the documentation is updated for the next meta release.

Topic Is the service API meant to validate the content of the access token and compare this against the API parameters ? - #174

•  

  • @Jesús Peña García-Oliva invited @Elisabeth Mueller  to provide context and open the discussion.

  • Elisabeth highlighted various approaches to using the data subject named in the access token and comparing it to API parameters. Emphasized the need for APIs to validate that the correct access token is used for API calls. Suggested standardizing the content of access tokens to aid vendors in ensuring compatibility across different operators.

  • Jesús argued that standardizing access token content is unrealistic due to different internal implementations by operators. Stressed that handling and validating access tokens should remain implementation-dependent. Acknowledged the challenge for vendors needing to adapt to each operator's unique implementation but maintained that operators' flexibility is crucial.

  • Elisabeth and @Jan Friman (Ericsson) voiced concerns about the burden on vendors to develop custom solutions for each operator. Suggested standardizing certain claims in the access token to streamline development and integration efforts.

  • @Mark Cornall (GSMA) agreed that while it would be ideal to have a standard, it veers into internal implementation territory, which is beyond CAMARA scope. Suggested that recommendations on access token content could be better addressed in other working groups like OPG and OPAG.

  • @Herbert Damker pointed out that token formats are often already defined internally by operators and that proprietary parts complicate standardization.

•  

  • @Jesús Peña García-Oliva requested that participants write down their opinions and feedback on the issue in the discussion forum.

  • @Elisabeth Mueller was asked to provide a more detailed proposal and specific examples for the working group to review.

•  

  • The discussion highlighted the differences between the need for standardization for vendors and the flexibility required by operators.

  • Further input and detailed proposals are needed to move forward with potential standardization efforts regarding the content of access tokens.

Topic OIDC authorization code flow and/or CIBA - #176  - er

•  

  • Toyeeb Rehman from GSMA highlighted the need for clarity on which authorization flow operators should implement. Operators often ask whether to use authorization code flow, client credentials flow, or others. Operators often seek specific documentation on the applicable authorization flows per API.

  • Current State: There's no documentation specifying which authorization flows should be used for each API. The flows are defined during the onboarding process.

  • @Jesús Peña García-Oliva From a technical standpoint, operators need to align with CAMARA's ICM security and interoperability profile, which defines the authorization flows used by CAMARA (among other things). The decision on which flow to implement is influenced by local regulations and the specific API in use.

  • The CAMARA ICM documentation aims to provide flexibility, supporting multiple authorization flows (authorization code, client credentials, etc.). This approach decouples API specifications from local regulations and specific use cases, allowing for easier updates without modifying the API specs.

  • From Jesus's perspective, 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, 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.

  • The topic may need further discussion in the business stream to align technical recommendations with business decisions.

  • Jesús's say that operators should follow CAMARA's defined flows, but the decision on implementing all flows or not is a business one. For specific APIs with unique requirements, the flow may be dictated by the API's functionality (such as Number Verification API).

•  

  • Review @Jesús Peña García-Oliva detailed comment on the issue and provide feedback. Further discussions might be needed to clarify the balance between technical recommendations and business decisions regarding authorization flows.

  • Toyeeb will communicate the points discussed to @Mark Cornall and gather any additional viewpoints or decisions from the business stream.

Next meeting: https://lists.camaraproject.org/g/wg-icm/viewevent?repeatid=57069&eventid=2360389&calstart=2024-07-03