/
2025-03-12 ICM Draft Agenda/Minutes

2025-03-12 ICM Draft Agenda/Minutes

Owned by Axel Nennker, created

Community Attendees:

@Jesรบs Peรฑa Garcรญa-Oliva @Axel Nennker @Sรฉbastien Dewet @Ramesh Shanmugasundaram

Community Attendees:

@Herbert Damker @Jan Friman @diego.gonzalezmartinez @Mark Cornall @ALI IQBAL

LF Staff:

Agenda

Antitrust Policy

ย 

@Jesรบs Peรฑa Garcรญa-Oliva Suggested agenda items for consideration. We can merge them with the existing ones for the convenience of the WG:

ย 

Minutes

  1. https://github.com/camaraproject/IdentityAndConsentManagement/pull/276

merged

  1. ICM 0.4.0 - preparing the scope for meta-release Fall25 #275
    We are going to add issues and PRs to this issue so that we have a list what we are working on that is supposed to be in the Fall25 release.
    Issues are going to be labeled with the new fall25 label as well

  2. https://github.com/camaraproject/IdentityAndConsentManagement/issues/277
    https://github.com/camaraproject/IdentityAndConsentManagement/issues/258
    https://github.com/camaraproject/IdentityAndConsentManagement/pull/268
    We could not agree on whether CIBA without user authentication is two-legged or not.
    Short version: DTโ€™s position is that Client Initiated Backchannel Authentication without user authentication is not a three-legged flow because the user-leg is missing.
    Telefรณnica's position is that, looking at the whole picture (and not just the scenario where consent is not required or is already given), the existing documented flow does not turn CIBA into a two-legged flow, since the user's rights to opt-in (in this case, the user is explicitly authenticated) and opt-out (revocation of consent is checked on each auth request) are still maintained, and the access token is indeed associated with the user identifier (the access token contains the three legs, client, auth server and user).

    Telefonica thinks that the proposed changes in PR #268 could potentially solve issue #258 by not requiring another alternative flow to be defined. The proposed changes are based on not contradicting CIBA, but also not going beyond CIBA itself by always mandating the interaction with the user. They emphasise and reinforce the API provider's freedom to choose authentication and authorisation methods in CIBA, based on their risk assessment and confidence level, and always in accordance with applicable law.

Tanja suggested to use id_token_hint instead of login_hint.
Refreshtokens could also be used.
Discussion continues off-line.

Next meeting: 26. March Calendar

Related content