@Jesús Peña García-Oliva @Sébastien Dewet @diego.gonzalezmartinez

@Ming Hui Foo @Eric Murray @Herbert Damker @Mark Cornall @Ola Ajibola @Shilpa Padgaonkar @Elisabeth Mueller @Jan Friman

Agenda

Minutes

ICM 0.3.0 - Meta-Release Spring25 Scope Preparation

PR #182 split - info.description template review (part 3 of 3)

Discussed the progress of PR PR #182 split - info.description template review (part 3 of 3) by jpengar · Pull Request #214 · camaraproject/IdentityAndConsentManagement , addressing issues #178, #190, and #200.
Agreed to merge the PR, as feedback from reviewers like Tanya, Randy, and Axel has been addressed.
It requires a code owner final approval @Sébastien Dewet @Axel Nennker

New sections with error scenarios

Reviewed Issue New sections with error scenarios · Issue #211 · camaraproject/IdentityAndConsentManagement and its corresponding PR Add response codes for error scenarios by garciasolero · Pull Request #220 · camaraproject/IdentityAndConsentManagement .
There has been minimal recent activity. The WG was asked to review the PR in order to agree on whether to merge it, as it consolidates error scenarios in an annex for clearer implementation guidelines.

DPoP support

Allow to use operator token for device authentication in OpenID Auth code flow

Discussed Allow to use operator token for device authentication in OpenID Auth code flow · Issue #232 · camaraproject/IdentityAndConsentManagement and Add a section on operator token usage in authorization code flow by AxelNennker · Pull Request #238 · camaraproject/IdentityAndConsentManagement .
The discussion centered on whether operator tokens could securely authenticate devices in the Authorization Code (Auth Code) flow or if they only serve as identifiers in CAMARA context.
Skeptics highlighted that operator tokens, in their current form, cannot authenticate a device. They only identify the device, similar to providing an MSISDN or IP address.
It was proposed that tokens be enhanced with attributes such as app IDs or IP addresses in order to improve security.
CAMARA’s Role: Some members emphasized that CAMARA should remain agnostic about the token enhancement process. If external specifications (e.g., TS 43 or ASAC) standardize a secure operator token, CAMARA could acknowledge and document it.
Summary of Action Items:
- Clarify CAMARA’s stance on operator tokens’ authentication capabilities in the Auth Code flow.
- Explore the feasibility of adopting enhanced operator tokens while maintaining alignment with existing standards and guidelines.
- Gather more feedback on scenarios where operator tokens could provide value without compromising security.

Add examples full CIBA flow for CIBA in CAMARA-ICM-examples.md

Consent URL API vs OIDC consent collection

The group discussed the proposed Consent URL API, which aims to allow standalone consent collection via a URL, independent of OIDC authentication flows. Consent URL API vs OIDC consent collection · Issue #224 · camaraproject/IdentityAndConsentManagement
Participants expressed differing opinions about the necessity and implications of the Content URL API. Some argued it was a flexible approach to gathering user consent, while others worried it deviated from existing standards and introduced fragmentation risks.
Telefónica emphasized that the existing network-based authentication definitions in CAMARA might be disrupted if new authentication mechanisms are introduced without careful consideration. They highlighted potential interoperability issues and the need to rework previous agreements.
Deutsche Telekom questioned whether the proposal should move forward as a sandbox API or aim for standardization. They expressed concerns about imposing implementation burdens on all operators and suggested further exploration of alternatives within existing standards.
Both sides acknowledged strong opposing views and suggested involving additional participants to achieve consensus.