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 https://github.com/camaraproject/IdentityAndConsentManagement/pull/214 , 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 https://github.com/camaraproject/IdentityAndConsentManagement/issues/211 and its corresponding PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/220 .
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 https://github.com/camaraproject/IdentityAndConsentManagement/issues/232 and https://github.com/camaraproject/IdentityAndConsentManagement/pull/238 .
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. https://github.com/camaraproject/IdentityAndConsentManagement/issues/224
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 assumptions 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.