Jesús Peña García-Oliva Axel Nennker Sébastien Dewet Ramesh Shanmugasundaram
Herbert Damker Jan Friman diego.gonzalezmartinez Mark Cornall ALI IQBAL
Type @<name> to tag attendance
https://github.com/camaraproject/IdentityAndConsentManagement/pull/276
https://github.com/camaraproject/IdentityAndConsentManagement/issues/278
https://github.com/camaraproject/IdentityAndConsentManagement/issues/277
https://github.com/camaraproject/IdentityAndConsentManagement/pull/268
https://github.com/camaraproject/IdentityAndConsentManagement/issues/267
https://github.com/camaraproject/IdentityAndConsentManagement/issues/272
https://github.com/camaraproject/IdentityAndConsentManagement/pull/256
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:
ICM 0.4.0 - preparing the scope for meta-release Fall25 #275
https://github.com/camaraproject/IdentityAndConsentManagement/issues/275
Reset version to wip after Spring25 public release #276
https://github.com/camaraproject/IdentityAndConsentManagement/pull/276
Consent URL API vs OIDC consent collection #224
https://github.com/camaraproject/IdentityAndConsentManagement/issues/224
Consent Info/Consent URL API DRAFT proposal #266
https://github.com/camaraproject/IdentityAndConsentManagement/pull/266
TSC conclusion in 2025-03-06 TSC Minutes
Cleanup Issues and PRs regarding Consent URL/Info API after repo creation
https://github.com/camaraproject/IdentityAndConsentManagement/issues/278
CIBA Privacy #258
https://github.com/camaraproject/IdentityAndConsentManagement/issues/258
CIBA MUST not become two-legged #268
https://github.com/camaraproject/IdentityAndConsentManagement/pull/268
Create OAuth2 two-legged flow with user identifier associated with the access token #277
https://github.com/camaraproject/IdentityAndConsentManagement/issues/277
Clarification on which device is authenticated in authorization code flow #255
https://github.com/camaraproject/IdentityAndConsentManagement/issues/255
Document when FE flow is applicable with regards to involved devices #256
https://github.com/camaraproject/IdentityAndConsentManagement/pull/256
TO BE CLOSED - Update working group description on http://camaraproject.org
https://github.com/camaraproject/IdentityAndConsentManagement/issues/265
https://camaraproject.org/identity-and-consent-management/ has been updated, can we close this issue?
TO BE CLOSED - Lacking of Misuse from mobile application Prevention
https://github.com/camaraproject/IdentityAndConsentManagement/issues/272
merged
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
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