Agenda

Antitrust Policy

• operator token login_hint format #218 merged

• ICM 0.3.0 - preparing the scope for meta-release Spring25 #193

• Update Pull Request template with breaking change indication #223

• Clarify case sensitivity of parameter names and values #221

• Add response codes for error scenarios #220

• Recommend signed authentication requests for CIBA #217

• Update section on client authentication #216

• Authentication method in authorization code flow #215

Minutes

Operator Token login_hint Format (#218)

• Decision: Standardized the login_hint for operator tokens with the prefix operatortoken: for clarity.

• Outcome: PR updated and merged after agreement on format, ensuring consistency across implementations.

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

• Status: Jesús raised concerns about delays in preparing PRs for the Meta release.

• Key Points:

  • Some issues within the Spring25 scope lack associated PRs, which could impact the release schedule.

  • If PRs remain incomplete, certain topics might need to be dropped from the release.

• Next Steps: Review the issues and prioritize PRs, distinguishing between API-impacting PRs (critical for release) and those that can be deferred to a later phase.

Outcome: Agreement to track and address outstanding PRs to keep the release on schedule.

Update Pull Request Template with Breaking Change Indication (#223)

• Proposal: Jesús suggested updating the PR template to include an indication for potential breaking changes, similar to Commonalities, to alert developers to compatibility impacts.

• Discussion:

  • Axel questioned who should mark a PR as breaking; it was clarified that the PR author would do so.

  • Rafal noted GitHub's checklist format could cause minor confusion with tasks marked as partially complete.

• Next Steps: Keep the PR open temporarily to refine the template based on usage feedback from Commonalities.

Outcome: Agreed to implement the update with ongoing adjustments to ensure clarity.

Clarify Case Sensitivity of Parameter Names and Values (#221)

• Proposal: Eric suggested clarifying that all parameter names and values are case-sensitive unless otherwise specified.

• Outcome: Agreed to add this clarification to the documentation for consistency.

Add Response Codes for Error Scenarios (#220)

• Proposal: Standardize and document error response codes in an appendix to improve interoperability and support developers.

• Discussion: Group agreed to make the error handling section normative, ensuring consistency across implementations.

• Outcome: Approved to include a normative appendix with error codes for better guidance on error handling.

Decision: Add standardized, normative error response codes to the documentation.

Recommend signed authentication requests for CIBA #217

• Proposal: Eric proposed signing authentication requests for CIBA, which was generally accepted. Jesús (Telefonica) agreed with the proposal but also suggested extending it to cover the authentication code flow (Issue #205).

• Discussion: Signing requests was seen as a recommendation, despite TLS protecting communication. Implementation can validate signed requests, as the necessary JWT validation code is already in place.

• Outcome:

  • Jesús to verify and approve Eric’s PR.

  • Ming Hui Foo to create a separate PR for the authentication code flow issue.

Update section on client authentication #216

• Proposal: Eric proposed keeping the iat claim in the client authentication JWT to determine the token's lifetime. Eric explained that the reference to error messages has been removed since they are now handled in a separate PR.

• Discussion: The key point from Eric was that including the iat claim is reasonable because it helps determine the token's lifetime by showing when the claim was created, which prevents misuse like stockpiling tokens. Axel pointed out that the iat does not prevent clients from stockpiling JWTs, as they could still create multiple tokens with different expiration times. Eric countered that the point is the standard says iat is optional. The proposal is to recommend it, so we think JWT should include it, and then use that to determine the token lifetime. And if it is there, it makes the token lifetime calculation very straightforward.

• Outcome: The PR will be reviewed offline by Axel and the WG and it will be decided if it will be merged later.

Authentication Method in Authorization Code Flow #215

• Proposal: Shilpa proposed closing the issue with comment https://github.com/camaraproject/IdentityAndConsentManagement/issues/215#issuecomment-2459938985

• Discussion:

  • Jesús disagreed with the proposed conclusion, emphasizing that the solution documented by ICM from v0.1.0 defines network-based authentication, which was not mentioned in the current discussion. Jesús refers to Telefónica comments on https://github.com/camaraproject/IdentityAndConsentManagement/issues/215#issuecomment-2456745705

  • Jesús clarified that the operator should decide whether consent is required, based on local regulations and the scope/purpose declared by the API client.

  • Axel agreed that operators must adhere to local legal frameworks, ensuring consistent consent practices across operators in a market.

  • Jesús also mentioned the current CAMARA specified solution where access tokens are always associated with a specific identifier/device (identified by network authentication).

  • Jesús agreed that, once network-based authentication has taken place, CAMARA does not prevents operators to use other additional authentication methods if needed (e.g., user/passport verification) as part of the in-band consent capture.

• Outcome:

  • Jesús proposed adding a new comment to the GitHub issue with alternative text as conclusion to agree on and discussed creating a pull request to update the documentation for better clarity if it is deemed necessary.

  • Consensus was reached that the issue could be closed once the necessary clarifications are added to the documentation.