Agenda

Antitrust Policy

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/209 OIDC authorization code flow error response

  • PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/210 fixes it (under review).

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/208 Proposal for CAMARA mandated minimum acceptable JWT token lifetime

  • minimum token lifetime that must be accepted by all authorisation servers for private_key_jwt.

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/211 New sections with error scenarios.

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/193 Spring25 scope. Review status and new topics added, milestones, identify "priority" issues (if any), etc...

  The relevant set of PRs covering the scope of the upcoming release shall be made available for Sub Project team review as follows:

  • PRs for critical issues must be created by Oct 15th (not necessarily merged)

  • PRs for other issues must be created by Oct 31st (not necessarily merged)

• Patch release r0.2.1. Correct the text of the r0.2.1 release to reflect the same contents of the changelog, which follows RM guidelines.

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/204 Fall24: ICM r0.2.0 clarification: Signed Request Object is optional

  • could it be closed with the existing answer?

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/205 Spring25: Proposal to RECOMMEND the use of Signed Request Object for the /authorize endpoint to prevent abuse

  • this is candidate for Spring25 to be fixed along with #194

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/207 ICM Release Versioning

Minutes

OIDC Authorization Code Flow Error Response (Issue #209)

• Overview:

  • The existing CAMARA specification mandates an HTTP 400 status code for invalid requests in the OIDC authorization code flow. However, Axel pointed out that this approach is not compatible with OIDC’s redirect-based error handling, making it technically infeasible.

• Resolution and Proposal:

  • Axel submitted a pull request (#210) to address this by specifying that for OIDC, errors should follow the invalid_request response with a redirection as per the OIDC core standards.

  • Jesús reviewed the proposal and suggested some minor corrections, including replacing "OIDC" references with "authorization code flow" to maintain clarity.

• Outcome:

  • Participants agreed to review the pull request in detail and merge it after ensuring alignment. A patch release was also suggested to address this change before the next meta-release.

CAMARA Mandated Minimum Acceptable JWT Token Lifetime (Issue #208)

• Context:

  • Eric proposed a mandated minimum acceptable lifetime for JWT tokens to ensure consistent acceptance across all authorization servers using private_key_jwt. The suggested value is 300 seconds, to avoid tokens with excessively long lifetimes which could pose a security risk.

• Discussion:

  • Jesús clarified that the scope of this proposal should focus on private_key_jwt tokens initially but might be extended to other JWT tokens depending on further input.

  • Mark Cornall emphasized the importance of interoperability and suggested a stricter guideline to ensure no ambiguity for API consumers. Instead of saying "may be accepted if longer than 300 seconds," he proposed stating "should be 300 seconds or less."

• Outcome:

  • Eric will draft more detailed text to specify exact requirements and error responses for various token lifetime scenarios. The group will review this in the next meeting to finalize.

New Sections with Error Scenarios (Issue #211)

• Proposal:

  • Jesús proposed adding a comprehensive list of error scenarios and corresponding error codes for common authorization flows (authorization code flow and ciba flow) in the CAMARA profile. This would provide clear guidance and help avoid misinterpretation of standards, which has been a pain point for integrators.

• Debate:

  • Normative vs. Informative:

    • Axel was concerned about making this mandatory. He argued that adding it as a normative requirement might lead to conflicts with existing standards (e.g., OpenID Connect, OAuth2).

    • On the other hand, Jesús, Telefónica and GSMA insisted on making it normative to ensure interoperability and uniform implementation across different operators.

  • Real-World Example:

    • Guido cited issues faced in Mobile Connect, where multiple valid error codes for the same scenario led to confusion and implementation inconsistencies.

    • Toyeeb shared his experience working on the Postman collection for authentication flow certification, noting that a standardized error list would greatly simplify the developer experience.

• Outcome:

  • Telefónica will create a proposal for review, and the group will decide whether this should be mandated as a normative requirement in the CAMARA profile.

ICM 0.3.0 - Preparing the Scope for Meta-Release Spring25 (Issue #193)

• Current Status and Scope Definition:

  • The Spring25 meta-release is being planned, with initial scope topics defined. Key focus areas include:

    • Improving documentation and aligning terminology.

    • Addressing error handling and new security considerations.

• Deadlines:

  • Critical issue pull requests must be created by October 15th.

  • All other issues must have pull requests by October 31st.

• Outcome:

  • All participants should review the defined scope and submit their respective pull requests by the deadlines. No additional critical topics were identified during the meeting.

Patch Release r0.2.1 - Text Correction

• Issue:

  • The release text for patch r0.2.1 does not accurately reflect the content of the changelog.

• Resolution:

  • Jesús will update the release text to ensure it follows RM guidelines and aligns with the changelog, maintaining consistency across documentation.

Fall24: ICM r0.2.0 Clarification - Signed Request Object Optional (Issue #204)

• Overview:

  • Clarification was sought on whether the use of a Signed Request Object is mandatory for the /authorize endpoint. Jesús confirmed that it is currently optional but will need further clarification in the next release.

• Outcome:

  • Participants agreed to review and decide in the next meta-release whether to recommend or mandate this for Spring25.

Spring25: Proposal to Recommend Signed Request Object for /authorize (Issue #205)

• Proposal:

  • To address potential abuse, a proposal was made to recommend the use of Signed Request Objects for the /authorize endpoint.

• Outcome:

  • This topic will be discussed further in conjunction with related security updates planned for Spring25.

ICM Release Versioning (Issue #207)

• No discussion, the group has run out of time. It will be taken offline. It is being discussed in the Release Management Working Group, and there are specific proposals. https://github.com/camaraproject/ReleaseManagement/issues/94

Action Items:

1. OIDC Error Response (Issue #210):

   • Review the latest pull request and prepare for a quick merge post-approval.

2. Minimum JWT Token Lifetime (Issue #208):

   • Eric to draft a detailed proposal on the recommended JWT token lifetime and handling.

3. Error Scenarios Proposal (Issue #211):

   • Telefonica to prepare a comprehensive document outlining error scenarios and suggested responses.

4. Patch Release Text Correction:

   • Jesús to update the release notes for r0.2.1 to match the changelog. → UPDATE (10/10): done

5. ICM Meta-Release Spring25 (Issue #193):

   • All teams to submit their respective pull requests by the set deadlines.

6. Signed Request Object (Issues #204 & #205):

   • Review and finalize the approach for Spring25, balancing security needs and implementation feasibility.

Next Meeting

Oct 23, 2024, 4:00:00 PM