Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NOT mandating ‘prompt=none’ in the auth code flow for number verification API #160

Open
mingshiatwork opened this issue Dec 19, 2024 · 4 comments

Comments

@mingshiatwork
Copy link

Problem description

The following line in the number-verification.yaml states that authentication for the Number Verification API must occur automatically without any user interaction, making the prompt=none parameter mandatory for the auth request:
Statement in YAML file:
• - (1): Authentication must be automatic without any user interactions. Authentication methods such as SMS OTP or user/password are incompatible, as the goal is to validate the mobile phone number that is accessing the App. So it is required to be authentication via mobile network and without the user being involved. the use of parameter prompt=none, as described in [OIDC Connect] (https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), ensures no user interaction.

However, this requirement conflicts with the Identity and Consent Management specifications, which include consent capture as part of both the Authorization Code flow (frontend) and the CIBA flow (backend).

In countries such as Thailand, explicit consent is required before a mobile operator processes a Number Verification API request. As a result, all first-time API auth requests for a subscriber are likely to be rejected if the client includes ‘prompt=none’ in the auth request.
This conflict needs resolution to ensure compliance with both specifications and regulatory requirements.

Expected behavior
The ‘prompt=none’ parameter should not be mandated in the auth code request for the Number Verification API. This flexibility enables the mobile operator to integrate consent capture into the authentication flow. Once consent is obtained, subsequent API requests should proceed without requiring user interaction.

Alternative solution

Additional context

@bigludo7
Copy link
Collaborator

Hello @mingshiatwork
Your request make sense.
@AxelNennker as you lead ICM may you provide feedback? could we trigger a PR as suggested by @mingshiatwork?

@mhfoo
Copy link
Collaborator

mhfoo commented Dec 19, 2024

Adding more context: the API technical scope: number-verification:verify
Purpose: dpv:FraudPreventionAndDetection

@AxelNennker
Copy link
Collaborator

I see the issue more as an issue of NumberVerfication.

The API consumer can request an auth code without "prompt=none", but IF the MNO determines that consent is not granted and needed e.g. because the end-user opted out, then the MNO SHOULD redirect to end-user authentication and end-user consent collection. The MNO COULD return an error if the MNO decided that consent is needed and not present.

Why does the API Consumer not send the request with "prompt=none"? Wouldn't that solve the problem e.g. if the user opted-out and the legal basis requires consent?
Then the API consumer receives "error=consent_needed" and then the API consumer can start consent collection using OIDC auth code flow using "prompt=consent".

I created two PR in ICM because I want to achieve interoperability of CAMARA openid providers.
camaraproject/IdentityAndConsentManagement#229
camaraproject/IdentityAndConsentManagement#228

NumberVerification mixes two problems into one API:

  • device authentication
  • number verification

TS.43 created the operator token for "Device App authentication with OperatorToken" which we are currently integrating into CAMARA.

@mingshiatwork
Copy link
Author

@bigludo7 We are rolling out the number verification service for enterprise customers and aim to align with the CAMARA specification. However, to ensure compliance with government regulations, it is critical that we do not bypass obtaining the subscriber's consent.
To that end, we seek your input and decision on not mandating the prompt=none parameter in the YAML file. Your prompt action on this matter will be greatly appreciated.
Thank you for your guidance and support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants