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.

Originally posted by @AxelNennker in #161 (comment)