Agenda

Antitrust Policy

• ICM 0.3.0 - preparing the scope for meta-release Spring25 · Issue #193 · camaraproject/IdentityAndConsentManagement

  • ICM Spring25 public release available at Release r2.3 · camaraproject/IdentityAndConsentManagement Thank you all!!

• CIBA MUST not become two-legged by AxelNennker · Pull Request #268 · camaraproject/IdentityAndConsentManagement

  • Please review and propose text

• Consent URL API vs OIDC consent collection · Issue #224 · camaraproject/IdentityAndConsentManagement

  • Consent Info/Consent URL API DRAFT proposal by jpengar · Pull Request #266 · camaraproject/IdentityAndConsentManagement

Minutes

Agenda Item 1: ICM 0.3.0 – Preparing the Scope for Meta-Release Spring25

• The Spring25 public release (Release r2.3) is now complete.

• The team acknowledged the significant effort and congratulated everyone on this achievement.

• Future discussions and development will target the Fall25 meta-release and upcoming meta-releases.

Agenda Item 2: CIBA MUST NOT Become Two-Legged (PR #268)

• The discussion focused on ensuring the CIBA flow maintains proper three-party authentication.

• Concerns were raised that using only a telephone number (MSISDN) could reduce the flow to a two-legged one, as it lacks sufficient proof of user authentication.

• It was noted that different authentication methods yield varying levels of assurance (for instance, network-based authentication may only verify a device rather than fully authenticating the end user.); API providers could rely on the login hint for user identification if it meets their confidence requirements (e.g. because the existing contract relationship with the API consumer) or opt for additional authentication (like using an operator token) when higher assurance is needed.

• Some participants emphasized that as long as the access token is issued for all three participants, it inherently constitutes a three-legged flow regardless of whether split authentication is applied.

• A token-based approach (such as using an ID token) was suggested as a better alternative to guarantee that all three parties (API consumer, provider, and data owner) are properly authenticated.

• The group agreed to review and refine the proposed text to clearly document these security expectations.

Agenda Item 3: Consent URL API vs. OIDC Consent Collection (PR #266)

• The Consent URL API was discussed as a complementary mechanism—not a replacement—for existing OIDC and CIBA flows.

• It is clarified that the usage of the consent Info/URL API does not impact the existing Authcode or CIBA protocols

• It offers additional flexibility by allowing API consumers to check consent status and capture consent when needed (e.g., during onboarding), without interfering with standard authentication processes.

• The group reached a consensus to move forward with the API proposal, pending further documentation and clarification.

• Next steps include bring ICM conclusion to TSC to ask for API approval and for repository creation (or subproject management) with ICM as parent group and clarifying release management implications in future updates.

Feel free to share any further adjustments or clarifications if needed!

Next Meeting

12/03/2025