Fall25 task force - CIBA privacy fix - TEF DRAFT proposal

[jpengar]

What type of PR is this?

• documentation

What this PR does / why we need it:

This is Telefónica's proposal to fix CIBA Privacy Issue #258, based on the discussions held in #258 and #268. This PR is intended solely to provide a clean draft proposal to facilitate discussions for the Fall25 task force created in the ICM WG.

Which issue(s) this PR fixes:

Fixes #258

Special notes for reviewers:

The PR was created purely for the sake of the task force, to facilitate reaching an agreement on a clean proposal that we might end up agreeing on.

CC @subha5h

Changelog input

CIBA auth and privacy clarifications

Additional documentation

• https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/123077145/2025-05-21+Draft+Agenda+ICM+Minutes
• https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/126878096/2025-05-27+Fall25+task+force+1+-+Draft+Agenda+ICM+Minutes

[AxelNennker]

This flow always returns an auth_request_id regardless whether the end-user already granted their consent, right?
As long as the ip address or msisdn belong to the user.

That would then not leak PII, I think.

[AxelNennker]

To repeat the privacy issue:

We do not want to allow the API Consumer to iterate over millions of MSISDNs and determine the consent status.
Second attack scenario, the attacker enters the victim's MSISDN into the API Consumer's process, e.g. at bank account creation time the attacker enters the victim's MSISDN, based on the response by the API Provider which changes the response of the API Consumer the consent status of that user is now known to the attacker.

Does this PR prevent these leaks?

It is the API Provider who has to pay the e.g. GDPR fines "up to 2% of its entire global turnover of the preceding fiscal year" e.g. if the API Consumer make a mistake or actively exploits the CIBA request to gain PII.

[AxelNennker]

The problem remains that with tel and ipport the API Provider just has an identifier but not an authorization.
With operatortoken or idtoken_hint API Provider would have prove that the User was involved and consented.

[AxelNennker]

if an identifer like MSISDN or ipport is used with this CIBA flow, then the flow is a two-legged flow because the User is not involved. A prio involvement by e.g. having given consent out-of-band beforehand does not solve this being a two-legged flow because the user has not control over the authentication request parameters like login_hint.

The attacker enters the victims MSISDN and the API Provider leaks the PII whether the end-user gave their consent or not.

[AxelNennker]

With JWT Bearer the API Provider would not have this PII-leakage problem, because JWT Bearer is a two-legged flow by design and JWT Bearer never sends an authentication message to the end-user.

[shilpa-padgaonkar]

@jpengar @AxelNennker

Following yesterday’s taskforce call, I wanted to share my thoughts on the topic. I see this version as an improvement over the previous text. We interpret this new text in a way that in CIBA, User authentication is mandatory while consent capture is not mandatory as the user might have already granted consent and it might still be valid.

Now our primary focus be on finalizing the JWT bearer token flow, enabling use cases that don't require user interaction to transition from CIBA to the JWT bearer token flow ASAP.

[shilpa-padgaonkar]

#293 (comment)

LGTM

[jpengar]

@jpengar @AxelNennker

Following yesterday’s taskforce call, I wanted to share my thoughts on the topic. I see this version as an improvement over the previous text. We interpret this new text in a way that in CIBA, User authentication is mandatory while consent capture is not mandatory as the user might have already granted consent and it might still be valid.

Now our primary focus be on finalizing the JWT bearer token flow, enabling use cases that don't require user interaction to transition from CIBA to the JWT bearer token flow ASAP.

If by "User authentication is mandatory while consent capture is not mandatory as the user might have already granted consent and it might still be valid." you mean that user interaction is mandatory in CIBA and that JWT-Bearer would enable scenarios without user interaction, that is not what the text says.

That is also not aligned with existing implementations until Spring 25.

The text essentially maintains backwards compatibility, but also gives API providers the freedom to choose how to authorise requests, which may or may not involve user interaction depending on the use case and always in accordance with applicable law. An API provider could now always contact the user (if applicable legislation requires so), but also they may rely in the login_hint according to their own risk/legal assessment for example because the API Consumer (say a bank) is in under a contract relationship where the API Consumer is responsible to validate those MSISDNs and to send requests only for MSISDNs that corresponds to customers of the API Consumer.

In any case, we agree completely that this text represents the best way forward, and we are willing to merge it as is. However, it is crucial that we are aligned in our interpretation of it.

[jpengar]

As per above comments, would you and the WG be happy to merge PR #293 as it is and fix issue #258? If so, @sebdewet and @AxelNennker, please consider approving the PR as code owners. #268 would then be closed to resolve the issue fully within the Fall25 scope.

Then we can focus on finalising the JWT-Bearer flow specification.

CC @shilpa-padgaonkar @Elisabeth-Ericsson @subha5h @HuubAppelboom et al.

[sebdewet]

LGTM

[jpengar]

As agreed in today's ICM Fall25 Task Force session 2 meeting, I will proceed to merge this PR.