Agenda

Antitrust Policy

• PR Release Candidate r2.2

• Issue: Discuss and specify requirements for enabling Interoperable Authorization Code Flow with Network and Non-Network based Authentication Methods in Camara
  PR: Allow API to decide on network-based authentication in OIDC authorization code flow

• Issue Transitional support for client_secret_basic client authentication

• Issue Consent URL API vs OIDC consent collection

Minutes

@Jesús Peña García-Oliva is moderating today’s ICM meeting because @Axel Nennker excused himself.

Release Candidate r2.2

• All pending topics from the last call were closed over the past two weeks.

• All topics in https://github.com/camaraproject/IdentityAndConsentManagement/issues/193 were finalized.

• A pull request (#254) has been created for the release candidate, already approved by the Release Management Team and @Axel Nennker .

• There is on review comment from @Tanja de Groot that info.description uses the word “operator” instead if “API consumer”.
  @Jesús Peña García-Oliva asked the participants what their opinion is on whether the change the info.description. If ICM changes the text all subprojects should adopt the new version.

• @Eric Murray proposed to change info.description because there is still a lot of time before the release.

• Elisabeth Mueller (Ericsson) highlighted the complexity in multi-stakeholder environments (e.g., aggregators, developer platforms). After discussion, it was agreed to refine the wording to clarify roles.

• @Jesús Peña García-Oliva is proposing text which can then be reviewed.

  • UPDATE (30/01): Done. See https://github.com/camaraproject/IdentityAndConsentManagement/pull/254/commits/7627127037a39a24661e560fb16320216969907c

Issue: Discuss and specify requirements for enabling Interoperable Authorization Code Flow with Network and Non-Network based Authentication Methods in Camara

Background

• The discussion originated from Issue #215, which aimed to clarify authentication methods in the Authorization Code Flow.

• The outcome of Issue #215 confirmed that CAMARA currently only considers network-based authentication for issuing access tokens, but there was agreement that CAMARA does not intend to restrict the flow to network authentication exclusively.

• As a result, Issue #245 and PR #244 were created to explore new authentication methods while ensuring interoperability.

Discussion Points

• Implicit Assumptions in the Authorization Code Flow

  • Elisabeth Mueller (Ericsson) pointed out that the Authorization Code Flow implicitly assumes that the device initiating the flow (user device) is the same as the target device for which an access token is being requested.

  • This assumption arises because network-based authentication relies on identifying the target device through its IP address, which is then linked to an MSISDN and verified against the consent database.

  • Elisabeth suggested that this assumption should be explicitly documented to avoid misunderstandings.

  • While Jesús Peña (Telefónica) acknowledged that documentation already describes these technical rules, Elisabeth argued that the distinction between user device and target device is not explicitly stated.

  • Elisabeth proposed submitting a pull request to clarify that front-end flows (Authorization Code Flow) apply only when the user device is the same as the target device.

  • The group agreed that further clarification could be helpful, but Jesús noted that any new documentation updates should be reviewed and potentially included in a future release rather than the current one.

• Proposal for Supporting Non-Network-Based Authentication

  • A new issue was created to discuss how to introduce additional authentication methods while maintaining interoperability.

  • An initial proposal from Axel Nennker suggests modifying the profile to support non-network-based authentication methods. Currently, CAMARA's Authorization Code Flow assumes network-based authentication. The proposal suggests that API consumers should explicitly request network-based authentication via an acr value. If no acr is provided, the flow would follow OpenID standards, which do not mandate a specific authentication method.

• Concerns on Backward Compatibility

  • Jesús expressed concerns that this proposal would break backward compatibility. Under the current implementation, if no acr value is provided, the default behavior is to use network-based authentication. The proposed change would alter this, leading to potential integration issues.

  • Jesús suggested:

    • Maintain backward compatibility by keeping Network-Based Authentication as the default behavior, with acr_values providing optional flexibility.

    • Standardize acr_values for each supported authentication method, ensuring granularity and clear expectations for both UX and security.

    • Define error scenarios for unsupported acr_values and standardize their handling to avoid inconsistencies across operators.

    • Ensure token-device/phone number association is preserved for all supported authentication methods.

  • The group needs to further analyze whether this approach is the best way to introduce non-network-based authentication while preserving compatibility with existing integrations.

Issue Transitional support for client_secret_basic client authentication

• Many current customers use client_secret_basic for client authentication in Mobile Connect. Migrating to CAMARA requires private_key_jwt, but several customers have not implemented this method.

• Proposal: Create a transitional interoperability profile allowing client_secret_basic for a limited time to facilitate migration. This would not be available for new deployments, which should use private_key_jwt.

• Concerns Raised by Jesús Peña (Telefónica):

  • Impact on Open Gateway and TMF APIs: It is unclear whether current TMF API definitions allow anything other than private_key_jwt.

  • Security and Credential Management:

    • In the early Open Gateway discussions, GSMA strongly opposed client_secret_basic due to security risks and provisioning complexity.

    • Aggregators would need to store credentials for multiple clients, increasing security risks.

    • private_key_jwt eliminates this issue by relying on client-side private keys and publicly available public keys, simplifying provisioning and improving security.

• Eric clarifies that the transitional profile would be optional and only used if all parties involved (including aggregators) agree to support it. It would not replace the standard interoperability profile but provide a temporary option for migration.

• More feedback is needed from other working group participants. Jesús noted that his concerns relate more to Open Gateway than directly to CAMARA.

• The discussion will continue offline.

Issue Consent URL API vs OIDC consent collection

• Telefónicas proposed a Consent Capture URL API that allows API consumers to obtain a URL for consent capture. This offers flexibility for consumers to display consent capture pages based on the user context. Consent management would remain with the operator, and this API would just facilitate consent capture.

• Ericsson's Proposal: Advocates for a Consent Info API that enables applications to check consent status before triggering consent capture dialogues. This would improve user experience by allowing applications to decide whether to prompt for consent based on the current consent status for specific scopes and purposes.

  • Telefónica sees no problem with adding an endpoint for consent status retrieval, as long as it’s for reading the status without enabling delegated consent management.

  • Ericsson emphasizes the importance of enabling applications to decide when and where to show consent dialogues for a smoother user experience. They also suggest avoiding unnecessary front-end flows that could complicate the system.

• Further work will be done and discussion will continue offline

Next Meeting

12.02.2025