Agenda

Antitrust Policy

• ICM 0.3.0 - preparing the scope for meta-release Spring25 - https://github.com/camaraproject/IdentityAndConsentManagement/issues/193

• PR #182 split - info.description template review (part 3 of 3) - https://github.com/camaraproject/IdentityAndConsentManagement/pull/214

  • Fixes 178, 190 and 200.

  • Let's merge it!

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

  • PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/220

  • There hasn't been any activity recently, so could we agree to merge the PR as is?

• DPoP support - https://github.com/camaraproject/IdentityAndConsentManagement/issues/125

  • PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/225

• Allow to use operator token for device authentication in OpenID Auth code flow - https://github.com/camaraproject/IdentityAndConsentManagement/issues/232

  • PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/238

• Add examples full CIBA flow for CIBA in CAMARA-ICM-examples.md - https://github.com/camaraproject/IdentityAndConsentManagement/issues/236

  • PR https://github.com/camaraproject/IdentityAndConsentManagement/pull/237

• Consent URL API vs OIDC consent collection - https://github.com/camaraproject/IdentityAndConsentManagement/issues/224

Minutes

ICM 0.3.0 - Meta-Release Spring25 Scope Preparation

• ICM alpha release r2.1 available at https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.1 with topics agreed and merged so far in the WG.

• Updated issue https://github.com/camaraproject/IdentityAndConsentManagement/issues/193 description according to current meta-release scope status. Added @sebdewet https://github.com/camaraproject/IdentityAndConsentManagement/pull/237 intended to fix https://github.com/camaraproject/IdentityAndConsentManagement/issues/236.

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

• Deferred topic. Discussions on https://github.com/camaraproject/IdentityAndConsentManagement/issues/125 and its related https://github.com/camaraproject/IdentityAndConsentManagement/pull/225 were postponed as key participants were unavailable.

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

• This item has already been covered in the first agenda topic.

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 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.