From ef0d315c4cce9ca9aafbecb0aa546b00124f4879 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Tue, 7 Jul 2026 10:59:39 +0200 Subject: [PATCH 1/2] CIBA in NR is problematic CIBA defeats the purpose of NR --- code/API_definitions/number-recycling.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/code/API_definitions/number-recycling.yaml b/code/API_definitions/number-recycling.yaml index 2b3aa31..e76ece5 100644 --- a/code/API_definitions/number-recycling.yaml +++ b/code/API_definitions/number-recycling.yaml @@ -59,6 +59,14 @@ info: In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. + Note: Using CIBA to obtain an access token for this API is problematic, because CIBA + delivers an authentication challenge (e.g. a push notification or SMS) to the device + associated with the phone number. This conflicts with the API's purpose: checking + whether that phone number still belongs to the same subscriber who originally consented. + If the number has since been recycled, the authentication challenge is delivered to the + new subscriber rather than the original one — undermining the very check this API exists + to perform. + # Identifying the phone number from the access token This API requires the API consumer to identify a phone number as the subject of the API as follows: From 28102e6f5441d65af63f8699fc5dce38439b8995 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Tue, 28 Jul 2026 11:15:08 +0200 Subject: [PATCH 2/2] Update number-recycling.yaml rephrase --- code/API_definitions/number-recycling.yaml | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/code/API_definitions/number-recycling.yaml b/code/API_definitions/number-recycling.yaml index e76ece5..4ae3d71 100644 --- a/code/API_definitions/number-recycling.yaml +++ b/code/API_definitions/number-recycling.yaml @@ -59,13 +59,9 @@ info: In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. - Note: Using CIBA to obtain an access token for this API is problematic, because CIBA - delivers an authentication challenge (e.g. a push notification or SMS) to the device - associated with the phone number. This conflicts with the API's purpose: checking - whether that phone number still belongs to the same subscriber who originally consented. - If the number has since been recycled, the authentication challenge is delivered to the - new subscriber rather than the original one — undermining the very check this API exists - to perform. + Note: If sending an authentication message in CIBA is based on the MSISDN and the MSISDN was reassigned to a new subscriber, then + this defeats the purpose of the number recycling API which is to determine whether the MSISDN was reassigned. + If the ASP and the CSP know at onboarding time that User consent is not needed, then JWT-Bearer-Flow with tel-prefix is recommended to be used with number recycling. # Identifying the phone number from the access token