Include authentication policy for Number Verification

[jgarciahospital]

Problem description

The objective of Number Verification API is being able to authenticate the device of the customer for ensuring that is using the line associated with the phone number that the third party or application is using as identity.

For such purpose, the API needs to validate the connection (current method) or the SIM (evolution towards Operator Token TS.43) during the authentication process, to later validate that token associated to the actual line identifier with the one provided by the developer in the API request.

Based on that purpose, it is expected that the developer will trigger a new authentication process any time that the API is to be called, ensuring that a proper identification of the line/SIM over the current device is always done before the API call.

One of the use cases to be controlled/avoided is a device changing the SIM card and reusing a token created with the previous SIM: the previous token (linked to the mobile phone number of the old SIM card) would be the one used for the Number Verification evaluation, which is not correct.

Expected action

Include security policy in the API description to ensure that:

• Access tokens used in Number Verification API can only be used once (one-shot), ensuring a new authentication is required each time the API is called.
• Access tokens used in Number Verification API have a restrictive expiration policy to ensure that the token used in the APP has recently been obtained.

Text proposal (inclusion of point 2):

**(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.

+**(2):** Authentication is the core of this service API, ensuring that the phone_number retrieved or verified is correct and according to the current SIM or network connection. For that puspose, this API includes a security mechanism to avoid token re-usage and a short time expiration policy to ensure that authentication is valid by the moment the API is consumed.

**(3):** The way in which the phone_number is retrieved depends on the implementation. For example, access token may be a self contained encrypted JWT, so API can decrypt and identify phone_number. Some other implementations might request the phone_number associated to the token from Authserver.

[AxelNennker]

Add DPoP

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#secti:~:text=Authorization%20and%20resource%20servers%20SHOULD,%C2%B6

Authorization and resource servers SHOULD use mechanisms for sender-constraining access tokens, such as Mutual TLS for OAuth 2.0 [RFC8705] or OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449] (see Section 4.10.1), to prevent misuse of stolen and leaked access tokens.

[jgarciahospital]

Hi Axel,

Target of this proposal is to avoid misuse of a token by the same APP, and not only to avoid the token been used by an app who stole it.

Your proposal solves the hack of the channel ensuring that only the app who is supposed to use the token will be able to do it (possession), but we still need to ensure that the token representing a line is still valid, so the APP (the valid APP) need to also re-issue a new token each time the API is to be called.

This ensures that a change on the device's line is properly handle, and a Number Verification is not allowed based on a line that is not present anymore in the device.

[eric-murray]

@ToshiWakayama-KDDI
Does this issue also affect the "number verification" functionality of KYC Match?