Guidance on Flows

[AxelNennker]

Problem description
CIBA sending a out an SMS to authenticate a user does not make much sense for NumberRecycling, right?
The common use case for NR is to validate that the phone number is still the same to what the ASP thinks it is.

Expected action
Describe pros and cons for each of the available flow provinding guidance to developers in the context of NR beyond the general guidance provided in ICM
https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#choosing-the-right-authorization-flow

Additional context

[PedroDiez]

Hi @AxelNennker,

Can you elaborate with an Use Case/Example to have more details about the topic? Think it will help in order to understand the implications behind, both from AuthN/AuthZ and Privacy/Legal points of view.

Not sure if the point is the case of having to manage consent in CIBA case (What would happen in case consent is already given).
But not sure if this could also have implications with other AuthN/AuthZ scenarios (Authorization Code, JWT Bearer).

Please, we would appreciate to have your input about this.

[AxelNennker]

Hola Pedro,

I do not understand you comment - at all.

Please see the API description:

    For example, below is a potential scenarios:
    * Scenario 1
      * Pre-conditions
        * User A signed a contract with MNO A for the phone number '+123456789' on October 9, 2023, and is still using it.
        * User A also signed contracts with ASP A on December 22, 2023 for its services.
        * ASP A holds the contract date (2023-12-22) and the phone number (+123456789) for User A.
        * Currently, on November 2, 2024, ASP A wishes to send a SMS message to User A.
      * Potential operations
        * ASP A sends a request with specified date (2023-12-22) and phone number (+123456789) to the Number Recycling API.
        * The API response sets to 'false', indicating that there has not been a change in the user associated with the phone number.
      * Post-conditions
        * ASP A decides to send the SMS message to User A.
      * By following these steps, ASP A ensures that a phone number is linked to User A.

Can you elaborate with an Use Case/Example to have more details about the topic? Think it will help in order to understand the implications behind, both from AuthN/AuthZ and Privacy/Legal points of view.

The usecase is the usecase described in the API description. Nothing new.

Not sure if the point is the case of having to manage consent in CIBA case (What would happen in case consent is already given). But not sure if this could also have implications with other AuthN/AuthZ scenarios (Authorization Code, JWT Bearer).

The issue and PR is not at all about consent. The standard usecase of NR implies a two-legged flow with a three-legged token.
CIBA is a three-legged flow and does not make sense for NR because CIBA sends an authentication message (e.g. SMS or push notification) to the number which might belong to a different user.

ACF might be used for NR regardless whether network-based authentication is used.

Please, we would appreciate to have your input about this.

Which flow does TEF plan to use with NR?

[Masa8106]

Hi @AxelNennker, thank you for opening this issue and a correspoinding PR.
What I am thinking is whether this problem happens only in CIBA case. Is the reason CIBA sends message by SMS? How about Auth Code flow?
As mentioned in Scenario 1, one of the main purpose of NR is to prevent SMS misdelivering. CIBA sends an authentication message by e.g. SMS. In my understanding, CIBA sends the message to an authentication device, which is not a consumption device to be checked the number by NR API. So what I want to know more is how the CIBA flow is related to this problem, or if my understanding is not correct please point it out.
I’m afraid I’m not familiar well with ICM topic, but I would appreciate it if you could explaing to me about it.

[AxelNennker]

The crux with CIBA is not SMS but that the authentication message is based on the phone number. This problem doesn’t exist with ACF because ACF really authenticates the User. JWT Bearer Flow with tel-prefix, if there is a special trust relationship between ASP and CSP, also works.

…

________________________________ From: Masaharu Hattori ***@***.***> Sent: Tuesday, 14 July 2026 19:03:35 To: camaraproject/NumberRecycling ***@***.***> Cc: Nennker, Axel ***@***.***>; Mention ***@***.***> Subject: Re: [camaraproject/NumberRecycling] Guidance on Flows (Issue #109) [https://avatars.githubusercontent.com/u/112887632?s=20&v=4]Masa8106 left a comment (camaraproject/NumberRecycling#109)<#109 (comment)> Hi @AxelNennker<https://github.com/AxelNennker>, thank you for opening this issue and a correspoinding PR. What I am thinking is whether this problem happens only in CIBA case. Is the reason CIBA sends message by SMS? How about Auth Code flow? As mentioned in Scenario 1, one of the main purpose of NR is to prevent SMS misdelivering. CIBA sends an authentication message by e.g. SMS. In my understanding, CIBA sends the message to an authentication device, which is not a consumption device to be checked the number by NR API. So what I want to know more is how the CIBA flow is related to this problem, or if my understanding is not correct please point it out. I’m afraid I’m not familiar well with ICM topic, but I would appreciate it if you could explaing to me about it. — Reply to this email directly, view it on GitHub<#109?email_source=notifications&email_token=AANEMB263QNSAVGXWUXLHOL5EZRWPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJXGE4DKNRWGM2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4971856634>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANEMB4MUM2UROTFMV67VIL5EZRWPAVCNFSNUABFKJSXA33TNF2G64TZHM4DGNRQHEZDONRSHNEXG43VMU5TINZUGE4TEMBYHAZ2C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AANEMB2U62IT2MPFOZAW3535EZRWPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJXGE4DKNRWGM2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AANEMBZM2Y6SQHM4D4AR4RL5EZRWPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJXGE4DKNRWGM2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>