Content for  TS 29.500  Word version:  19.0.0

When the NF service consumer is configured to use delegated service discovery, requirements in clause 13.4.1.3.2 of TS 33.501 shall apply with the following additions. If the NF service consumer received an access token in a previous service response that is valid for the new service request, the NF service consumer should include the access token in the Authorization header in the service request. An access token received in a previous service response is valid for the new service request if:

• it has a matching scope, or it has a matching service-level scope only (i.e. the new service request also requires a resource/operation-level scope that is not present in the scope of the access token received in the previous service response);
• it has a matching audience (i.e. matching producer's NF type or NF instance ID);
• it has a matching producer's NF set ID, S-NSSAI, NSI and PLMN ID, if the access token contains a producer NF set ID, S-NSSAI, NSI and PLMN ID respectively; and
• the access token has not expired.

If the NF service consumer does not include an access token in the service request, or if it does but the access token has a matching service-level scope only but not a matching resource/operation-level scope, or if does but the access token is NF instance specific and reselection of a different producer instance may apply at the SCP (e.g. a routing binding header or a discovery header provides the producer's NF set ID), the NF service consumer shall include in the service request:

• the necessary NF service discovery factors to be used by the SCP for the Service access authorization procedures, as specified in clause 6.10.3.2; and
• the 3gpp-Sbi-Access-Scope header indicating the access scope of the service request for access authorization, as defined for the specific resource/operation in the corresponding API (see clause 5.2.3.2.16).

In service requests including the 3gpp-Sbi-Access-Scope header, the NF service consumer may also include the 3gpp-Sbi-Other-Access-Scopes header indicating other access scopes that are desired to be obtained for the access token, in addition to the scopes indicated in the 3gpp-Sbi-Access-Scope, that are not required for the service request itself but that may be required for further service requests, when requesting an access token to the NRF. The NF service consumer may also include its Client Credentials Assertion as specified in clause 6.7.5. The SCP should use the access scope information received in the 3gpp-Sbi-Access-Scope header to determine the access scope required for access authorization for an incoming service request. The SCP may also use the scopes required by the NF service producer (as registered in its NF profile) for this determination and, if a new access token is required, request an access token to the NRF for a list of scopes that is the intersection of the scopes indicated in the 3gpp-Sbi-Access-Scope header and the scopes expected by the NF Service producer. If the 3gpp-Sbi-Other-Access-Scopes header is received in the incoming service request, the SCP may also include the other access scopes received in this header to the scopes requested to the NRF for the access token. If the NF service consumer has included an access token in the service request without including the 3gpp-Sbi-Access-Scope header, or if the SCP has a cached granted access token that matches the service request, the SCP should reuse the available access token. If the NF service consumer has included an access token in the service request and the 3gpp-Sbi-Access-Scope header, the 3gpp-Sbi-Access-Scope header contains multiple scopes, and the access token has a matching scope only for a subset of the scopes present in the 3gpp-Sbi-Access-Scope header, the SCP should consider that the access token has a valid scope for the service request if the NF service producer does not require any scope not granted in the Access Token (as determined from its NF profile); otherwise, the SCP shall request a new access token for the service request. When the NRF receives a request to obtain an access token for a list of scopes, but the NF service producer's profile does not allow to grant a token for all the requested scopes, the NRF should grant an access token but restricted to the allowed scope, unless the request cannot be authorized for other reasons. A failure to obtain an access scope received in the 3gpp-Sbi-Other-Access-Scopes header in the granted token shall not result in the SCP failing the service request, as long as all the scopes required for access authorization for the incoming service request have been authorized by the NRF. When the SCP requests an access token for a service request, the SCP may include the access token it has obtained from the NRF in the service response it forwards to the NF service consumer, by including the 3gpp-Sbi-Access-Token header, for possible re-use in subsequent service requests by the NF service consumer. The NF service consumer should store the access token received in a service response and use it in subsequent service requests as defined above.

If the SCP cannot issue an Access Token Request towards the NRF due to missing information in the incoming service request, e.g. if the 3gpp-Sbi-Discovery-requester-nf-instance header is missing, the SCP shall reject the service request with a 400 Bad Request response including a ProblemDetails IE with:

• the cause attribute set to MISSING_ACCESS_TOKEN_INFO;
• the invalidParams attribute indicating the missing parameters (e.g. missing discovery header).

If the SCP can issue an Access Token Request towards the NRF, but the NRF rejects the request (e.g. because the validation of the Client Credentials Assertion fails at the NRF or because the NF service consumer is not authorized to access the requested service), the SCP shall reject the service request towards the NF service consumer with a 403 Forbidden response including a ProblemDetails IE with the cause attribute set to ACCESS_TOKEN_DENIED. The ProblemDetails IE should also contain:

• the accessTokenError attribute set to the accessTokenErr content received from the NRF;

and it may contain:

• the accessTokenRequest attribute set to the Access Token Request content sent to the NRF;
• the nrfId attribute set to the FQDN of the NRF that rejected the access token request.

In either case, the SCP shall include the Server header in the error response set with its own identity (i.e. SCP FQDN) as specified in clause 6.10.8.2.

If the SCP issues an Access Token Request towards the NRF and the NRF returns an access token not granting authorization for all the scopes required for access authorization of the incoming service request, the SCP shall reject the service request towards the NF service consumer with a 403 Forbidden response including a ProblemDetails IE with the cause attribute set to ACCESS_TOKEN_DENIED. The ProblemDetails IE may contain:

• the accessTokenRequest attribute set to the Access Token Request payload sent to the NRF;
• the nrfId attribute set to the FQDN of the NRF that rejected the access token request.

The SCP shall include the Server header in the error response set with its own identity (i.e. SCP FQDN) as specified in clause 6.10.8.2. The SCP may include the access token it has obtained from the NRF (e.g. granting authorization for the other access scopes indicated in the service request) in the service response to the NF service consumer, by including the 3gpp-Sbi-Access-Token header, for possible re-use in subsequent service requests by the NF service consumer. The NF service consumer should store the access token received in a service response and use it in subsequent service requests as defined above.

If the NF service producer rejects the service request with a "401 Unauthorized" response or with a "403 Forbidden" response with a "WWW-Authenticate" header containing "Bearer" as the scheme for challenge:

• if the SCP had included an access token received from the NF service consumer in the service request to the NF service producer, the SCP shall forward the response to the NF service consumer; the NF service consumer shall then delete the corresponding access token and may repeat the request without an access token or with a different access token;
• if the SCP had included an access token it had cached or obtained from the NRF, the SCP shall not repeat the request with the access token that was used; the SCP may repeat the request with a new access token; otherwise, or if the repeated request fails, the SCP shall forward the response to the NF service consumer;
• if the SCP had not included an access token in the service request to the NF service producer, the SCP should request an access token to the NRF and repeat the request; otherwise, the SCP shall forward the response to the NF service consumer.

When requesting a new access token, the NF service consumer or the SCP should consider the error information received in the error response, e.g. to retrieve a new access token with the scopes or claims required by the NF service producer (see clause 6.7.3).