@bigludo7 this one is no longer needed I think.
Per current design, the token must 3-legged identifying a subscription and if the phone number in the request doesn't match we return a false in the response.

We are removing this one in almost all apis

@fernandopradocabrillo Just to be sure before we remove it - it means that test case @NumberVerification_phone_number_verify204_no_phonenumber_associated_with_access_token is not relevant anymore?

@fernandopradocabrillo I'm a bit reluctant to remove this code example because it is also use in /device-phone-number operation if for any reason we're not able to 'read' the phone number from the access token.
Any thoughts on the topic @AxelNennker ?

mm that is a good question. In order to be a valid access token it has to be associated with a phone number somehow (the internal structure of the access token is up to the Operator). Do you have an scenario or an example where you can have a valid access token but not being able to get the associated phone number?

Adding @AxelNennker to get his view.
I see this a safety bucket "in case of" but probably 403 NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_MOBILE_NETWORK coud make the job?

Adding @trehman-gsma to get conformance perspective.
Toyeeb, make sens if we remove this 403 INVALID_TOKEN_CONTEXT?

A valid 3-legged access token implies that an identifier is associated with the access token which can be used to identify the subscription. This identifier can be a MSISDN but it can be anything the API provider seems fit e.g. IMSI or ICCID.

I think that the case where there is a valid access token that is not associated with a subscription identifier (phone number) does not exist if the access token was created using a 3-legged flow.

I suggest that Commonalities defines an error for all APIs that means that the API provider tried network-based authentication but failed. I would go with
{
"status": 400,
"code": "BAD REQUEST",
"message": "identifying the subscription failed"
}
if the API consumer failed to send the code request over a CSP connection controlled by the API provider.

If CIBA is used, then this case can not happen, because the login_hint is backed into the access token. But CIBA does not really identify the end-user, which I think is important in most jurisdictions.

Regarding CIBA vs OIDC authorization code flow with Age Verification, I think the API description should have some text explaining to the API consumer that CIBA uses an authentication device and if a minor has access to their parent's or to some other adult's mobile phone then CIBA relies on the adult's ability to keep their mobile phone out of the hands of the minor.
OIDC authorization code flow could make use of network-based authentication but then the age of the subscriber is verified and not the age of the end-user. If Age Verification promises to the API consumer that it verifies the age of the end-user then, OIDC authorization code flow with max_age=0 is the only solution, I think.

I think that, speaking only about Number Verification API, the INVALID_TOKEN_CONTEXT error cannot happen. This API is intended to use with Auth Code Network auth, which means 3-legged and, as Axel said, is not possible to have a valid access token not associated with an identifier.

The invalid token context error is checking the same as the core functionality of the API, which is that the phone number used for the network based authentication is the same one included in the request body. If they don't match, number verification returns a false.

What we wanted to check with @trehman-gsma is how this error has been tested in previous versions. I think it was excluded based on technical limitations.

If we have no use for this error, maybe it is best to remove it, even if we have to upgrade the major version..

Hi @bigludo7 @fernandopradocabrillo,

From my perspective, it's fine to remove INVALID_TOKEN_CONTEXT from this API. We were unable to simulate the error, and the test case @NumberVerification_phone_number_verify204_no_phonenumber_associated_with_access_token was excluded from certification based on technical limitations.

In the edge case of GET /device-phone-number being called with an access token where it's not possible to read the phone number, would a 403 PERMISSION_DENIED suffice?

A valid 3-legged access token implies that an identifier is associated with the access token which can be used to identify the subscription. This identifier can be a MSISDN but it can be anything the API provider seems fit e.g. IMSI or ICCID.

I think that the case where there is a valid access token that is not associated with a subscription identifier (phone number) does not exist if the access token was created using a 3-legged flow.

I suggest that Commonalities defines an error for all APIs that means that the API provider tried network-based authentication but failed. I would go with
{
"status": 400,
"code": "BAD REQUEST",
"message": "identifying the subscription failed"
}
if the API consumer failed to send the code request over a CSP connection controlled by the API provider.

If CIBA is used, then this case can not happen, because the login_hint is backed into the access token. But CIBA does not really identify the end-user, which I think is important in most jurisdictions.

Regarding CIBA vs OIDC authorization code flow with Age Verification, I think the API description should have some text explaining to the API consumer that CIBA uses an authentication device and if a minor has access to their parent's or to some other adult's mobile phone then CIBA relies on the adult's ability to keep their mobile phone out of the hands of the minor.
OIDC authorization code flow could make use of network-based authentication but then the age of the subscriber is verified and not the age of the end-user. If Age Verification promises to the API consumer that it verifies the age of the end-user then, OIDC authorization code flow with max_age=0 is the only solution, I think.