Access token verification

Abstract

Example embodiments of the present disclosure relate to access token verification. In an example embodiment, a method is provided. The method includes receiving, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from a second network function and including a token to access the first network function, the token includes token verification of a list of delegated domains to which it is delegated by the first network function, the token being generated by the network repository function based on registration information from the first network function, the registration information includes at least one of an indication of whether delegation of token verification is allowed, or a delegation domain list, and verifying the token in accordance with a determination that the first service communication agent belongs to the delegation domain list. In this manner, authentication of access tokens may be improved.

Description

Technical Field

[0001] Example embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to apparatus, methods, and computer-readable media for access token authentication. Background Art

[0002] 5G Service-Based Architecture (SBA) has been defined to enable flexible and scalable deployment using virtualization and container technologies and cloud-based processing platforms. In 5G SBA, services are modeled as network functions (NFs) that communicate with each other using application program interfaces (APIs).

[0003] However, virtualization implementation and the use of cloud processing also put forward higher and different requirements on security. For example, the security of token verification for access to NF services needs to be well studied. Summary of the invention

[0004] In general, example embodiments of the present disclosure provide a solution for access token authentication.

[0005] In a first aspect, a device is provided. The device includes: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor, causes the device to at least: receive, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function, the token including a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and verifying the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0006] In a second aspect, an apparatus is provided. The apparatus includes: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor, causes the apparatus to at least: receive, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function; obtain a profile associated with the first network function, the profile including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegated domains to which token verification is delegated by the first network function; and verify the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0007] In a third aspect, an apparatus is provided. The apparatus includes: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor causes the apparatus to at least: receive registration information from a first network function at a network repository function, the registration information including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; receive a request for a token for accessing the first network function from a second service communication agent; and send the token to the second service communication agent.

[0008] In a fourth aspect, a device is provided. The device includes: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor, causes the device to at least: at a first network function, send registration information to a network repository function, the registration information including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and receive from a first service communication agent a second request for a service from the first network function, the second request including: a token for accessing the first network function, and an indication of success of verification of the token.

[0009] In a fifth aspect, a method is provided. The method includes: receiving, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function, the token including a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and validating the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0010] In a sixth aspect, a method is provided. The method includes: receiving, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function; obtaining a profile associated with the first network function, the profile including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and verifying the token based on determining that the first service communication agent belongs to the list of delegation domains.

[0011] In a seventh aspect, a method is provided. The method comprises: receiving, at a network repository function, registration information from a first network function, the registration information comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which token validation is delegated by the first network function; receiving a request for a token for accessing the first network function from a second service communication agent; and sending the token to the second service communication agent.

[0012] In an eighth aspect, a method is provided. The method includes: at a first network function, sending registration information to a network repository function, the registration information including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and receiving from a first service communication agent a second request for a service from the first network function, the second request including: a token for accessing the first network function, and an indication of success of verification of the token.

[0013] In a ninth aspect, an apparatus is provided. The apparatus comprises: a component for receiving, at a first service communication agent, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and comprising a token for accessing the first network function, the token comprising a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information comprising at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and a component for verifying the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0014] In a tenth aspect, an apparatus is provided. The apparatus includes: a component for receiving, at a first service communication agent, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and including a token for accessing the first network function; a component for obtaining a profile associated with the first network function, the profile including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegated domains to which token validation is delegated by the first network function; and a component for validating the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0015] In an eleventh aspect, an apparatus is provided. The apparatus includes: a component for receiving registration information from a first network function at a network repository function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; a component for receiving a request for a token for accessing the first network function from a second service communication agent; and a component for sending the token to the second service communication agent.

[0016] In a twelfth aspect, an apparatus is provided. The apparatus includes: a component for sending registration information to a network repository function at a first network function, the registration information including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and a component for receiving, from a first service communication agent, a second request for a service from the first network function, the second request including: a token for accessing the first network function, and an indication of success of verification of the token.

[0017] In a thirteenth aspect, a non-transitory computer-readable medium is provided, the medium comprising program instructions for causing an apparatus to at least execute the methods in the fifth to eighth aspects.

[0018] It should be understood that the invention summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0020] Figure 1 An example of a communication system in which some example embodiments of the present disclosure may be implemented is shown;

[0021] Figure 2 An example of a process flow for access token verification according to some example embodiments of the present disclosure is shown;

[0022] Figure 3 An example of another process flow for access token verification according to some other example embodiments of the present disclosure is shown;

[0023] Figure 4 An example process for access token verification according to some example embodiments of the present disclosure is shown;

[0024] Figure 5 Another example process for access token verification according to some other example embodiments of the present disclosure is shown;

[0025] Figure 6 shows further example processes for access token verification according to some further example embodiments of the present disclosure;

[0026] Figure 7 A flowchart illustrating an example method at a first service communication proxy (SCP) according to some other example embodiments of the present disclosure;

[0027] Figure 8A flowchart showing another example method at a first SCP according to some other example embodiments of the present disclosure;

[0028] Fig. 9 A flowchart illustrating an example method at a Network Repository Function (NRF) according to some example embodiments of the present disclosure is shown;

[0029] Fig.10 A flowchart illustrating an example method at a first network function (NF) according to some example embodiments of the present disclosure;

[0030] Fig.11 shows a simplified block diagram of a device suitable for implementing some example embodiments of the present disclosure; and

[0031] Fig.12 A block diagram illustrating an example of a computer readable medium according to some example embodiments of the present disclosure is shown.

[0032] Throughout the drawings, the same or similar reference numerals denote the same or similar elements. DETAILED DESCRIPTION

[0033] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are only for illustrative purposes, and contribute to those skilled in the art to understand and implement the present disclosure, without implying any limitation to the scope of the present disclosure. The present disclosure described herein can be implemented in various ways except for the modes described below.

[0034] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0035] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. In addition, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it should be considered that it is within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0036] It should be understood that although the terms "first" and "second" etc. can be used in this article to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element without departing from the scope of the example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0037] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an", and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "comprise", "include", "have", "have", "include" and / or "comprising", when used herein, specify the presence of the features, elements and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0038] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0039] (a) hardware circuit implementation only (e.g., implementation only in analog and / or digital circuitry), and

[0040] (b) a combination of hardware circuitry and software such as (where applicable):

[0041] (i) a combination of analog and / or digital hardware circuits and software / firmware, and

[0042] (ii) any portion of hardware processor(s) with software (including digital signal processor(s), software and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions, and

[0043] (c) Hardware circuits and / or processor(s), such as microprocessor(s) or portions of microprocessor(s), that require software (e.g., firmware) to operate, but the software may not be present when the software is not required for operation.

[0044] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term "circuitry" also covers, for example, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, cellular network device, or other computing or network device, if applicable to the particular claim element.

[0045] As used herein, the term "communication network" refers to a network that complies with any appropriate communication standard, such as Long Term Evolution (LTE), Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. In addition, the communication between the terminal equipment and the network equipment in the communication network can be performed according to any appropriate generation communication protocol, including but not limited to the fourth generation (4G), 4.5G, future fifth generation (5G) communication protocol, and / or any other protocol currently known or to be developed in the future. The embodiments of the present disclosure can be applied to various communication systems. In view of the rapid development of communication, there will certainly be future types of communication technologies and systems, using which the present disclosure can be embodied. This should not be regarded as limiting the scope of the present disclosure to the above-mentioned systems.

[0046] As mentioned above, the use of virtualized implementations and cloud processing places higher and different requirements on security in 5G SBA. Currently, there is support for indirect communication between NFs based on token authorization. For example, in the prior art, the NF delegates its token verification to the Service Communication Proxy (SCP). In this case, if another NF requests a service from the NF, the SCP verifies the access token of the other NF on behalf of the NF, and then the SCP signals the result of the access token verification to the NF. If the result indicates verified access, the NF does not need to verify the access token from the other NF and provide the requested service.

[0047] However, there are still many uncertainties in the existing token verification. For example, the SCP cannot know that it is allowed to verify the access token on behalf of the NF. In addition, on the NF side, the NF cannot be sure that the SCP that has verified the token is the SCP that is authorized to verify the access token on behalf of the NF. Currently, there is no way to avoid the NF from providing the requested service when the token has not been effectively verified.

[0048] In order to solve at least part of the above problems and other potential problems, a solution for access token verification is proposed.

[0049] According to some embodiments of the present disclosure, a first SCP receives a first request for a service from a first NF from a second SCP. The first request originates from the second NF and includes a token for accessing the first NF. The token includes a list of delegated domains to which the token verification is delegated by the first NF. The token is generated by the NRF based on registration information from the first NF, and the registration information includes at least one of the following: an indication of whether the delegation of the token verification is allowed, or a list of delegated domains. Then, based on determining that the first SCP belongs to the list of delegated domains, the first SCP verifies the token on behalf of the first NF.

[0050] According to some other embodiments of the present disclosure, the first SCP receives a first request for a service from the first NF from the second SCP. The first request originates from the second NF and includes a token for accessing the first NF. Then, the first SCP obtains a profile associated with the first NF, the profile including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegated domains to which the token verification is delegated by the first NF. In addition, based on determining that the first SCP belongs to the list of delegated domains, the first SCP verifies the token on behalf of the first NF.

[0051] In this way, mutual trust between the first SCP and the first NF can be guaranteed. In this way, the security of access token verification can be improved.

[0052] The principle and implementation of the present invention will be described in detail below with reference to the accompanying drawings. Figure 1 .

[0053] Figure 1 1 shows an example of a communication system 100 in which some example embodiments of the present disclosure may be implemented. The environment 100 may be a public land mobile network (PLMN). Figure 1 As shown, the environment 100 includes NFs 110 and 120, an SCP 130 serving the NF 110, an SCP 140 serving the NF 120, and an NRF 150 serving one or more of the following items: NF 110, NF 120, SCP 130, and SCP 140. In some example embodiments, the NF 110 may act as a service consumer, which may request services from the NF 120 acting as a service producer. For illustrative purposes only, hereinafter, the NF 120 is also referred to as "NFp 120" or "first NF 120", and the NF 110 is also referred to as "NFc 110" or "second NF 110". The SCP 140 connected to the NFp 120 is also referred to as "SCPp 140" or "first SCP 140", and the SCP 130 connected to the NFc 110 is also referred to as "SCPc 130" or "second SCP 130".

[0054] exist Figure 1In the present invention, NRF 150 is the NF that maintains NF profiles and available NF instances. NRF 150 may also provide service registration and discovery functions so that NFs can discover each other. In some example embodiments, with a hierarchical (or redundant) NRF setup, the NRF 150 operation for a request for an access token by SCPc 130 may be different from the NF registration operation by NFp 120 and the NF discovery operation by SCPc 130 delegated to NFc 110. As an example, the NRF 150 herein may be implemented by an entity that is capable of performing some or all of the above operations and potentially other operations.

[0055] In a 5G SBA with model D (also referred to as indirect communication with delegated discovery), the function for discovering and selecting a target NF from a list of available NFs may be delegated to the SCP. In this case, NFc 110 and NFp 120 may not be directly connected to the NRF 150. As an example, NFc 110 may discover the target NFp 120 through SCPc 130. However, in a 5G SBA with model C (also referred to as indirect communication without delegated discovery), the SCP may not be delegated for target NF discovery. In this case, NFc 110 may be directly connected to the NRF 150 for target NF discovery and access token request, respectively. For example, SCPc 130 may be responsible for routing service requests from NFc 110 to SCPp 140. It should be understood that SCPs 130 and 140 may be implemented as the same physical network entity or different physical network entities.

[0056] In some example embodiments, Figure 2 As shown, SCP 130 and 140 may communicate directly with NRF 150. In some other example embodiments, SCP 130 or 140 may communicate indirectly with NRF 150 via one or more other devices or functions.

[0057] Communications between individual devices or functions in environment 100 may follow any suitable communication standards or protocols that already exist or will be developed in the future. The scope of the present disclosure is not limited in this regard.

[0058] It should be understood that the devices or functions shown in environment 100 are for illustration purposes only and do not imply any limitation. Environment 100 may include any other suitable devices, elements, or functions for providing communications.

[0059] Figure 2 An example of a process 200 for access token verification according to some example embodiments of the present disclosure is shown. For the purpose of discussion, the process 200 will refer to Figure 1It should be understood that although process flow 200 has been described in Figure 1 The process flow is described in the network environment 100, but the process flow can also be applied to any other similar communication scenarios.

[0060] like Figure 2 As shown, the NFp 120 sends (205) registration information to the NRF 150. For example, the registration information may include an indication of whether delegation of token verification is allowed. Alternatively or additionally, the registration information may include a list of delegated domains to which the token verification is delegated by the NFp 120. In this case, for example, if there is no explicit delegated domain list, a default delegated domain list associated with the domain to which the NFp 120 belongs may be implicitly indicated.

[0061] In some example embodiments, when NFp 120 registers with NRF 150, NFp 120 may add two new attributes "tokenValidationDelegationAllowed" and "tokenValidationDelegationSCPDomainList" in the NF profile or NF service. For example, the attribute "tokenValidationDelegationAllowed" may indicate whether delegation of token validation is allowed. The attribute "tokenValidationDelegationSCPDomainList" may indicate a list of delegation domains to which token validation is delegated by NFp 120. For example, NRF 150 may encrypt "tokenValidationDelegationSCPDomainList" in the token declaration using a configured public key or shared key.

[0062] For example, the NF profile may be as shown in Table 1.

[0063] Table 1: Definition of type NFProfile

[0064]

[0065] For example, the NF service may be as shown in Table 2.

[0066] Table 2: Definition of type NFService

[0067]

[0068] In some example embodiments, these new attributes in the NF profile may be used only by the NRF 150 or the SCPp 140. For security reasons, they may not need to be sent to the NFc 110 that discovers the NFp 120.

[0069] Alternatively, these new properties may be configured locally in the NRF 150 or SCPp 140. In this case, the above-described registration process is not required.

[0070] In some example embodiments, NFc 110 may send a request for services from NFp 120 to SCPc 130. For example, the request may include range information associated with NFp 120. Then, based on the request, SCPc 130 may perform a discovery process with NRF 150 to find NFp 120.

[0071] In addition, if Figure 2 As shown, SCPc 130 sends (210) a request for a token for access to NFp 120 to NRF 150. For example, NRF 150 generates a token based on the request from NFp 120 and the registration information. Then, NRF 150 sends (215) the token to SCPc 130. For example, the token may include a list of delegation domains to which token validation is delegated by NFp 120. In an embodiment where the registration information includes both an indication of whether delegation of token validation is allowed (such as, an attribute "tokenValidationDelegationAllowed" set to 1) and a list of delegation domains to which token validation is delegated by NFp 120 (such as, an attribute "tokenValidationDelegationSCPDomainList"). The token may include "tokenValidationDelegationSCPDomainList" as indicated in the registration information. Alternatively, in embodiments where the registration information includes only an indication of whether delegation of token validation is allowed, such as, the attribute "tokenValidationDelegationAllowed" is set to 1, without a list of delegation domains to which token validation is delegated by NFp 120, the token may include an implicitly indicated default delegation domain list, such as, a delegation domain list associated with the domain to which NFp 120 belongs.

[0072] For example, in this case, the tokens may be as shown in Table 3.

[0073] Table 3: Definition of type AccessTokenClaims

[0074]

[0075] like Figure 2As shown, SCPc 130 sends (220) a request for service (also referred to as a first request) from NFp 120. The first request includes a token as described above. After receiving the first request, SCPp 140 can determine whether it belongs to the list of delegated domains indicated in the token.

[0076] In some example embodiments, SCPp 140 may first determine whether token validation is required and then determine whether it belongs to the list of delegated domains indicated in the token. For example, when a service request is received using a token, SCPp 140 may discover (225) the profile of NFp 120 to obtain oauth2Required, perPlmnOauth2ReqList (as described in 6.1.6.2.3 of Technical Specification (TS) 29.510) to determine whether token validation is required, and additional scope information, such as allowedOperationsPerNfType and allowedOperationsPerNfInstance (as described in 6.1.6.2.3 of TS29.510) for further token validation. Then, if token validation is required, it may determine whether it belongs to the list of delegated domains indicated in the token.

[0077] In an example embodiment, the "tokenValidationDelegationSCPDomainList" in the token declaration is encrypted using a configured public key or shared key, and the SCPp 140 can query the token declaration and decrypt the "tokenValidationDelegationSCPDomainList" using the configured public key or shared key paired with the NRF 150 to check whether the token is allowed to be verified. If the SCPp 140 belongs to the delegated domain list, it verifies (230) the token. If the verification is successful, the SCPp 140 sends (235) another request for service (also referred to as a second request) to the NFp 120. For example, the second request may include a token and an indication of the success of the verification of the token. For example, the "AuthorizationValidated" field may be added to the second request to indicate the success of the verification of the token. Otherwise, if the verification is unsuccessful, the SCPp 140 may reject the first request.

[0078] Otherwise, if SCPp 140 does not belong to the trust domain list, it can directly relay the token to NFp 120 without an indication of success of the verification of the token. Then, NFp 120 can verify the token itself.

[0079] In an embodiment where the second request includes an indication of success of the verification of the token, the NFp 120 may also determine whether the SCPp 140 belongs to a list of delegated domains. As an example, the NFp 120 may determine the SCP domain identifier (ID) of the SCPp 140 based on a transport layer security (TLS) certificate. Then, based on this, the NFp 120 may determine whether the SCPp 140 belongs to a list of delegated domains. For example, the NFp 120 may verify that the SCPp belongs to a default list of SCP domains to which the NFp 120 belongs, or to a list of SCP domains authorized by the NFp 120.

[0080] For example, if SCPp 140 belongs to the delegated domain list, NFp 120 may no longer need to verify the access token. NFp 120 may also verify the scope information included in the second request. Otherwise, if SCPp 140 does not belong to the delegated domain list, NFp 120 may verify the token itself.

[0081] Through the process flow 200, mutual trust between the SCPp 140 and the NFp 120 can be ensured.

[0082] Figure 3 An example of another process flow 300 for access token verification according to some other example embodiments of the present disclosure is shown. For the purpose of discussion, the process flow 300 will refer to Figure 1 It should be understood that although process flow 300 has been described in Figure 1 The process flow is described in the network environment 100, but the process flow can also be applied to any other similar communication scenarios.

[0083] like Figure 3 As shown, NFp 120 sends (305) registration information to NRF 150. For example, the registration information may include an indication of whether delegation of token verification is allowed. Alternatively or additionally, the registration information may include a list of delegation domains to which token verification is delegated by NFp 120. Figure 2 Similarly, the indication and delegation domain list can be implemented as two attributes "tokenValidationDelegationAllowed" and "tokenValidationDelegationSCPDomainList" in the NF profile. Figure 2 The relevant details described also apply.

[0084] In some example embodiments, NFc 110 may send a request for services from NFp 120 to SCPc 130. For example, the request may include range information associated with NFp 120. Then, based on the request, SCPc 130 may perform a discovery process with NRF 150 to find NFp 120.

[0085] In addition, if Figure 3 As shown, the SCPc 130 sends (310) a request for a token for accessing the NFp 120 to the NRF 150. For example, the NRF 150 generates a token based on the request and registration information from the NFp 120. Then, the NRF 150 sends (315) the token to the SCPc 130.

[0086] Then, SCPc 130 sends (320) a request for a service (also referred to as a first request) from NFp 120. The first request includes a token. After receipt of the first request, SCPp 140 obtains (325) a profile associated with NFp 120. For example, the profile may include an indication of whether delegation of token verification is allowed. Alternatively or additionally, the profile may include a list of delegated domains to which token verification is delegated by NFp 120. Figure 2 Similarly, for example, if there is no explicit delegated domain list, a default delegated domain list associated with the domain to which the NFp 120 belongs may be implicitly indicated.

[0087] In some example embodiments, prior to the reception of the first request, the SCPp 140 may send a subscription request for at least one profile associated with at least one NF in at least one domain to the NRF 150, wherein the at least one NF includes the NFp 120. Then, the NRF 150 may send the at least one profile to the SCPp 140. For example, the subscription request may include a flag instructing the NRF 150 to immediately send the at least one profile to the SCPp 140. Then, the NRF 150 may send a subscription response to the SCPp 140. In this case, the SCPp 140 may subscribe to changes in at least one profile associated with at least one NF including the NFp 120. On this basis, the SCPp 140 may obtain a profile associated with the NFp 120 from the at least one profile based on the first request. Thus, the SCPp 140 may bind the first request to the profile associated with the NFp 120.

[0088] In some example embodiments, after receipt of the first request, the SCPp 140 may determine the NFp 120 based on the first request. In this case, the SCPp 140 may then perform a discovery process with the NRF 150 to obtain a profile associated with the NFp 120 from the NRF 150 based on the first request.

[0089] The SCPp 140 may then determine whether it belongs to the trusted domain list explicitly indicated in the profile or the default trusted domain list implicitly indicated.

[0090] like Figure 3 As shown, if SCPp 140 belongs to the list of trusted domains, it verifies (330) the token. In some example embodiments, SCPp 140 may first determine whether token verification is required, similar to reference Figure 2 As described, it can then verify the token if token verification is required. If the verification is successful, the SCPp 140 sends (335) another request for service (also referred to as a second request) to the NFp 120. For example, the second request may include: the token, and an indication of the success of the verification of the token. Otherwise, if the verification is unsuccessful, the SCPp 140 may reject the first request.

[0091] Otherwise, if SCPp 140 does not belong to the authorized domain list, it can directly relay the token to NFp 120 without an indication of success of the verification of the token. Then, NFp 120 can verify the token itself.

[0092] In embodiments where the second request includes an indication of success of the validation of the token, the NFp 120 may also determine whether the SCPp 140 belongs to a list of trusted domains, similar to reference Figure 2 For example, the NFp 120 may verify that the SCPp belongs to a default domain list that is implicitly indicated or an explicit domain list that is authorized by the NFp 120.

[0093] For example, if SCPp 140 belongs to the delegated domain list, NFp 120 may no longer need to verify the access token. NFp 120 may also verify the scope information included in the second request. Otherwise, if SCPp 140 does not belong to the delegated domain list, NFp 120 may verify the token itself.

[0094] Through the process flow 300, mutual trust between the SCPp 140 and the NFp 120 can be ensured.

[0095] Figure 4 An example process 400 for access token verification according to some example embodiments of the present disclosure is shown. For the purpose of discussion, the process 400 will refer to Figure 1 is described.

[0096] like Figure 4 As shown, at 402, the NFp 120 registers new token delegation attributes in its profile in the NRF, such as "tokenValidationDelegationAllowed" to indicate whether delegation of token validation is allowed, and "tokenValidationDelegationSCPDomainList" to indicate a list of delegation domains to which token validation is delegated by the NFp 120.

[0097] At 404, the NFc 110 sends a service request to the SCPc 130, the service request including scope information associated with the NFp 120 providing the requested service. Then, at 406, the SCPc 130 performs a discovery process with the NRF 150. For example, with a hierarchical NRF setup, the NRF 150 may be implemented as an Authorization Server NRF (AS-NRF).

[0098] At 408, SCPc 130 sends a request for an access token to NRF 150. In some example embodiments, if SCPc 130 uses "targetNfType" in the request for the access token, the audience in the access token statement may be set accordingly, and with multiple matching NF producer instances, "tokenValidationDelegationAllowed" and / or "tokenValidationDelegationSCPDomainList" may be configured differently. In this case, NRF 150 may need to act based on local policies when selecting the result to be included in the authorized access token. For example, when implemented as an AS-NRF, NRF 150 may not have all NFProfiles of NF producers for checking against the above-mentioned new parameters. In some other example embodiments, SCPc 130 uses "targetNfInstance" in the request for the access token. In this case, when implemented as an AS-NRF, NRF 150 may check whether there is the above-mentioned new parameter in the associated NFProfile for delegating access token validation to SCPp 140 and adding a new statement in the access token.

[0099] At 410, the NRF 150 checks whether "tokenValidationDelegationAllowed" is true, and if so, includes a new claim "tokenValidationDelegationSCPDomainList" in the access token to indicate that token validation can be delegated to SCPs, and to limit the SCPs that are allowed to validate the token based on NF service / NF profile or alternative local configuration. For example, when implemented as an AS-NRF, the NRF 150 may need to have a local policy that is used to check whether "tokenValidationDelegationAllowed" is true. For example, the NRF 150 may encrypt the "tokenValidationDelegationSCPDomainList" in the token claim using a configured public key or shared key.

[0100] Then, at 412, the NRF 150 responds to the Nnrf_AccessToken_Get request with the new token claim "tokenValidationDelegationSCPDomainList". At 414, the SCPc 130 sends a service request with the new token claim "tokenValidationDelegationSCPDomainList" to the SCPp 140. At 416, the SCPp 140 removes any AuthorizationValidated header that may be included from the incoming request. When a service request is received with the token, the SCPp 140 may discover the profile of the NFp 120 to obtain oauth2Required, perPlmnOauth2ReqList (as described in 6.1.6.2.3 of Technical Specification (TS) 29.510) to determine whether token validation is required, and additional scope information for further token validation, such as allowedOperationsPerNfType and allowedOperationsPerNfInstance (as described in 6.1.6.2.3 of TS29.510). A prerequisite is that the SCPp 140 is configured with the paired public / private key of the NRF which is used to authenticate the token.

[0101] Then, at 418, the SCPp 140 queries the token assertion and optionally decrypts the "tokenValidationDelegationSCPDomainList" using a configuration public key or shared key paired with the NRF 150 to check if the token is allowed to be validated. If allowed, the SCPp 140 validates the token based on the NFProfile obtained at 416. If the SCPp 140 is not allowed to validate the token, it directly relays the token to the NFp 120 without the AuthorizationValidated header being used to indicate that the token validation is successful.

[0102] At 420, if the token validation is successful, SCPp 140 forwards the NF service request with the token and an AuthorizationValidated header indicating that the token has been validated to NFp 120. Otherwise, SCPp 140 rejects the service request because it is unauthorized.

[0103] At 422, by checking the AuthorizationValidated header, NFp 120 knows that the token has been verified. In this case, NFp 120 also needs to check whether SCPp 140 is delegated to perform token verification. For example, NFp 120 can determine the SCP domain ID of SCPp 140 based on the TLS certificate. Then, on this basis, NFp 120 can determine whether SCPp 140 belongs to the delegated domain list. For example, NFp 120 can verify whether SCPp belongs to the default SCP domain list to which NFp 120 belongs or the SCP domain list authorized by NFp 120. If SCPp 140 is delegated to perform access token verification, NFp 120 no longer needs to verify the access token, but only needs to verify whether the service request matches the (multiple) ranges indicated in the Hypertext Transfer Protocol (HTTP) Range header. Otherwise, NFp 120 verifies the token by itself. Then, at 424-428, NF_Service_Response is sent to NFc 110.

[0104] References Figure 2 All operations and features described are equally applicable to process 400 and have similar effects. For the purpose of simplicity, details will be omitted.

[0105] Figure 5 Another example process for access token verification according to some other example embodiments of the present disclosure is shown. For the purpose of discussion, process 500 will refer to Figure 1 is described.

[0106] like Figure 5As shown, at 502, NFp 120 sends registration information to NRF 150. For example, the registration information may include an indication of whether delegation of token validation is allowed, and / or a list of delegation domains to which token validation is delegated by NFp 120. For example, two new attributes "tokenValidationDelegationAllowed" and "tokenValidationDelegationSCPDomainList" may be included in the NF profile. At 504, NRF 150 sends a registration response to NFp 120.

[0107] At 506, SCPp 140 performs a subscription associated with the SCP domain to NRF 150, for example, based on ScpDomainCond. In this case, SCPp 140 can subscribe to a collection of NF, SCP or SEPP instances belonging to certain SCP domains based on ScpDomainCond with immediateFlag set to true to instruct NRF 150 to immediately send the subscribed profile to SCPp 140. At 508, NRF 150 sends a subscription response to SCPp 140. Then, SCPp 140 can obtain the NF service / NF profile within the requested SCP domain. At 510, NFc 110 sends a service request to SCPc 130, which includes scope information associated with NFp 120 providing the requested service. Then, at 512, SCPc 130 performs a discovery process with NRF 150 and obtains an access token from NRF 150. At 514, SCPc 130 sends a service request to SCPp 140.

[0108] At 516, after receiving the incoming service request, the SCPp 140 removes any AuthorizationValidated header that may be included in the incoming request. The SCPp 140 can then check the service request and the profile of the NFp 120 to determine whether the token is allowed to be validated, for example, by checking two new attributes: tokenValidationDelegationAllowed and tokenValidationDelegationSCPDomainList. If allowed and delegated to validate the token, the SCPp 140 validates the token based on the profile of the NFp 120. If the SCPp 140 is not allowed to validate the token, it can directly pass the token to the NFp 120 without the AuthorizationValidated header being used to indicate successful token validation.

[0109] At 518, if the token validation is successful, the SCPp 140 forwards the NF service request with the token and the AuthorizationValidated header indicating that the token has been validated to the NFp 120. Otherwise, the SCPp 140 rejects the service request because it is not authorized.

[0110] At 520, by checking the AuthorizationValidated header, NFp 120 knows that the token has been verified. In this case, NFp 120 also needs to check whether SCPp 140 is entrusted to perform token verification. For example, NFp 120 can determine the SCP domain identifier (ID) of SCPp 140 based on the transport layer security (TLS) certificate. Then, for example, NFp 120 can verify that SCPp belongs to the default SCP domain list to which NFp 120 belongs or to the SCP domain list authorized by NFp 120. If SCPp 140 is entrusted to perform access token verification, NFp 120 no longer needs to verify the access token, but only needs to verify whether the service request matches the scope indicated in the hypertext transfer protocol (HTTP) 3gpp-Sbi-Access-Scope header. Otherwise, NFp 120 verifies the token by itself. Then, at 522-526, NF_Service_Response is sent to NFc 110.

[0111] References Figure 3 All operations and features described are equally applicable to process 500 and have similar effects. For the purpose of simplicity, details will be omitted.

[0112] Figure 6 4 shows another example process for access token verification according to some other example embodiments of the present disclosure. For the purpose of discussion, process 400 will refer to Figure 6 is described.

[0113] like Figure 6 As shown, at 602, NFp 120 sends registration information to NRF 150. For example, the registration information may include: an indication of whether delegation of token validation is allowed, and / or a list of delegation domains to which token validation is delegated by NFp 120. For example, two new attributes "tokenValidationDelegationAllowed" and "tokenValidationDelegationSCPDomainList" may be included in the NF profile. At 604, NRF 150 sends a registration response to NFp 120.

[0114] At 606, the NFc 110 sends a service request to the SCPc 130, the service request including scope information in a 3gpp-Sbi-Access-Scope header associated with the NFp 120 providing the requested service. Then, at 608, the SCPc 130 performs a discovery process with the NRF 150 and obtains an access token from the NRF 150. At 610, the SCPc 130 sends a service request to the SCPp 140. At 612, after receiving the service request, the SCPp 140 performs a discovery process with the NRF 150 to discover the profile of the NFp 120.

[0115] At 614, the SCPp 140 may check the service request and the profile of the NFp 120 to determine whether token validation is required, and if so, whether validation of the token is allowed, for example, by checking two new attributes: tokenValidationDelegationAllowed and tokenValidationDelegationSCPDomainList. If allowed and delegated to validate the token, the SCPp 140 validates the token based on the profile of the NFp 120. If the SCPp 140 is not allowed to validate the token, it may pass the token directly to the NFp 120 without the AuthorizationValidated header being used to indicate successful token validation.

[0116] At 616, if the token validation is successful, the SCPp 140 forwards the NF service request with the token and the AuthorizationValidated header indicating that the token has been validated to the NFp 120. Otherwise, the SCPp 140 rejects the service request because it is not authorized.

[0117] At 618, by checking the AuthorizationValidated header, NFp 120 knows that the token has been validated. In this case, NFp 120 also needs to check whether SCPp 140 is delegated to perform token validation. For example, NFp 120 can determine the SCP domain identifier (ID) of SCPp 140 based on the transport layer security (TLS) certificate. Then, for example, NFp 120 can verify that SCPp belongs to the default SCP domain list to which NFp 120 belongs or to the SCP domain list authorized by NFp 120. If SCPp 140 is delegated to perform access token validation, NFp 120 no longer needs to validate the access token, and it only needs to verify whether the service request matches the (multiple) scopes indicated in the Hypertext Transfer Protocol (HTTP) 3gpp-Sbi-Access-Scope header. Otherwise, NFp 120 validates the token itself. Then, at 620-624, NF_Service_Response is sent to NFc 110.

[0118] References Figure 3 All operations and features described are also applicable to process 600 and have similar effects. For the purpose of simplicity, details will be omitted.

[0119] Figure 7 1 shows a flowchart of an example method 700 at a first SCP according to some example embodiments of the present disclosure. The method 700 can be implemented at any suitable device. For example, the method 700 can be implemented at a first SCP as shown in FIG. Figure 1 The SCPp140 is implemented.

[0120] At block 710, SCPp 140 receives a first request for a service from a first NF from SCPc 130, the first request originating from NFc 110 and including a token for accessing the first NF, the token including a list of delegated domains to which token verification is delegated by NFp 120, the token being generated by NRF 150 based on registration information from NFp 120, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains. At block 720, SCPp 140 verifies the token based on a determination that SCPp 140 belongs to the list of delegated domains.

[0121] In some example embodiments, SCPp 140 may validate the token based on a determination that there is a need for token validation and based on a determination that SCPp 140 belongs to a trusted domain list.

[0122] In some example embodiments, SCPp 140 may send a second request for a service to NFp 120 in response to the success of the verification of the token, the second request including: the token, and an indication of the success of the verification of the token.

[0123] Those skilled in the art will understand that Figure 2 All operations and features described are also applicable to method 700 and have similar effects.

[0124] Figure 8 800 at a first SCP according to some other exemplary embodiments of the present disclosure. The method 800 can be implemented at any suitable device. For example, the method 800 can be implemented at a first SCP as shown in FIG. Figure 1 The described SCPp 140 is implemented.

[0125] At block 810, the SCPp 140 receives from the SCPc 130 a first request for a service from the NFp 120, the first request originating from the NFc 110 and including a token to access the NFp 120. At block 820, the SCPp 140 obtains a profile associated with the NFp 120, the profile including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains to which the token verification is delegated by the NFp 120. At block 830, the SCPp 140 verifies the token in accordance with a determination that the SCPp 140 belongs to the list of delegated domains.

[0126] In some example embodiments, SCPp 140 may send a subscription request to NRF 150 for at least one profile associated with at least one NF in at least one domain, the at least one NF including NFp 120, receive the at least one profile from NRF 150; and obtain a profile associated with NFp 120 from the at least one profile and based on the first request.

[0127] In some example embodiments, the subscription request includes an instruction to the NRF 150 to send a flag of at least one profile to the SCPp 140 .

[0128] In some example embodiments, SCPp 140 may obtain a profile associated with NFp 120 from NRF 150 based on the first request.

[0129] In some example embodiments, SCPp 140 may validate the token based on determining that there is a need for token validation and based on determining that SCPp 140 belongs to a trusted domain list.

[0130] In some example embodiments, SCPp 140 may send a second request for a service to NFp 120 in response to the success of the verification of the token, the second request including: the token, and an indication of the success of the verification of the token.

[0131] Those skilled in the art will appreciate that, as mentioned above, Figure 3 All operations and features described are also applicable to method 800 and have similar effects.

[0132] Fig. 9 1 shows a flow chart of an example method 900 at an NRF according to some example embodiments of the present disclosure. The method 900 can be implemented at any suitable device. For example, the method can be implemented at a device such as a reference device. Figure 1 The described NRF 150 is implemented.

[0133] At block 910, the NRF 150 receives registration information from the NFp 120, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the NFp 120. At block 920, the NRF 150 receives a request for a token to access the NFp 120 from the SCPc 130. At block 930, the NRF 150 sends the token to the SCPc 130.

[0134] In some example embodiments, the token includes a list of delegated domains.

[0135] In some example embodiments, NRF 150 may send at least one profile to SCPp 140 in response to receiving a subscription request from SCPp 140 for at least one profile associated with at least one NF in at least one domain, the at least one NF including NFp 120, and the profile associated with NFp 120 in the at least one profile includes at least one of the following: the indication or the delegated domain list.

[0136] In some example embodiments, NRF 150 may, in response to receiving a subscription request for a profile associated with NFp 120 from SCPp 140, send the profile to SCPp 140, the profile including at least one of: the indication or the delegated domain list.

[0137] Those skilled in the art will appreciate that Figure 3 to Figure 4 All operations and features described are also applicable to method 900 and have similar effects.

[0138] Fig.101 shows a flowchart of an example method 1000 at a first NF according to some example embodiments of the present disclosure. The method 1000 can be implemented at any suitable device. For example, the method can be implemented in a manner similar to that described in reference to FIG. Figure 1 The described NFp is implemented at 120.

[0139] At block 1010, NFp 120 sends registration information to NRF 150, the registration information including at least one of: an indication of whether token verification is allowed, or a list of delegated domains to which token verification is delegated by NFp 120. At block 1020, NFp 120 receives from SCPp 140 a second request for a service from NFp 120, the second request including: a token for accessing NFp 120, and an indication of success of verification of the token.

[0140] In some example embodiments, NFp 120 may determine, in response to the second request including an indication, whether SCPp 140 belongs to a trusted domain list.

[0141] In some example embodiments, NFp 120 may verify the scope information included in the second request based on determining that SCPp 140 belongs to the trusted domain list.

[0142] In some example embodiments, NFp 120 may validate the token based on a determination that SCPp 140 does not belong to the trusted domain list.

[0143] Those skilled in the art will appreciate that, as mentioned above, Figures 3 to 4 All operations and features described are also applicable to method 1000 and have similar effects.

[0144] Fig.11 1 shows a simplified block diagram of an apparatus 1100 suitable for implementing some example embodiments of the present disclosure. The apparatus 1100 may be provided to implement a communication device, such as Figure 1 The NFc 110, NFp 120, SCPc 130, SCPp 140 or NRF 150 are shown. As shown, the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processor 1110, and one or more communication modules 1140 coupled to the processor 1110.

[0145] The communication module 1140 is used for two-way communication. The communication module 1140 has at least one antenna to facilitate communication. The communication interface may represent any interface required to communicate with other network elements.

[0146] Processor 1110 may be of any type suitable for the local technology network, and may include, as non-limiting examples, one or more of: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 1100 may have multiple processors, such as application specific integrated circuit chips, which are time-slaved to a clock synchronized with a main processor.

[0147] The memory 1120 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1124, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), and other magnetic and / or optical memories. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1122 and other volatile memories that will not persist during the duration of a power outage.

[0148] Computer program 1130 includes computer executable instructions executed by associated processor 1110. Program 1130 may be stored in ROM 1124. Processor 1110 may perform any appropriate actions and processes by loading program 1130 into RAM 1122.

[0149] The embodiments of the present disclosure may be implemented by the program 1130, so that the device 1100 may execute the Figures 1 to 10 Any process of the present disclosure discussed. The embodiments of the present disclosure may also be implemented by hardware or a combination of software and hardware.

[0150] In some embodiments, the program 1130 may be tangibly embodied in a computer-readable medium that may be included in the device 1100 (such as in the memory 1120) or in other storage devices accessible by the device 1100. The device 1100 may load the program 1130 from the computer-readable medium to the RAM 1122 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0151] Fig.12 1 shows a block diagram of an example of a computer readable medium 1200 according to some example embodiments of the present disclosure. The computer readable medium 1200 has a program 1130 stored thereon. It should be noted that although Fig.12 Computer readable medium 1200 is depicted in the form of a CD or DVD, but computer readable medium 1200 may be in any other form suitable for carrying or storing program 1130.

[0152] Generally, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof.

[0153] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer executable instructions, such as instructions included in a program module, which are executed in a device on a target real or virtual processor to perform the above referenced Figures 7 to 10 Method 700, 800, 900 or 1000 described. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functions of the program modules can be combined or split in various embodiments as needed. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local and remote storage media.

[0154] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote machine or server.

[0155] In the context of the present disclosure, computer program codes or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various processes and operations as described above. Examples of carriers include signals, computer readable media, etc.

[0156] The computer readable medium may be a computer readable signal medium or a computer readable medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or apparatus, or any suitable combination of the above. More specific examples of computer readable media include an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0157] In addition, although the operation is described in a specific order, it should not be understood that such operation is required to be performed in the specific order shown or in a sequential order, or that all the operations shown require to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but should be interpreted as descriptions of features specific to a particular embodiment. Certain features described in the context of separate embodiments may also be combined in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0158] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Instead, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0159] Various example embodiments of these techniques have been described. In addition to or as an alternative to the above, the following examples are described. Features described in any of the following examples may be utilized with any other examples described herein.

[0160] In certain aspects, a method includes: at a first service communication agent, receiving a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for access to the first network function, the token including a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and determining to validate the token based on the first service communication agent belonging to the list of delegated domains.

[0161] In some example embodiments, validating the token: based on determining that there is a need for token validation, and based on determining that the first service communication agent belongs to a delegated domain list, validating the token.

[0162] In some example embodiments, the method further comprises: in response to successful verification of the token, sending a second request for a service to the first network function, the second request comprising: the token, and an indication of successful verification of the token.

[0163] In some aspects, a method includes: receiving, at a first service communication agent, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and including a token for accessing the first network function; and obtaining a profile associated with the first network function, the profile including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegated domains to which token validation is delegated by the first network function; and validating the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0164] In some example embodiments, obtaining a profile associated with a first network function includes: sending a subscription request to a network repository function for at least one profile associated with at least one network function in at least one domain, the at least one network function including the first network function; receiving at least one profile from the network repository function; and obtaining a profile associated with the first network function from the at least one profile and based on the first request.

[0165] In some example embodiments, the subscription request includes instructing the network repository function to send an indication of at least one profile to the first service communications agent.

[0166] In some example embodiments, obtaining the profile associated with the first network function comprises obtaining the profile associated with the first network function from a network repository function based on the first request.

[0167] In some example embodiments, validating the token comprises validating the token based on determining that there is a need for validation of the token and based on determining that the first service communication agent belongs to a delegated domain list.

[0168] In some example embodiments, the method further comprises: in response to successful verification of the token, sending a second request for a service to the first network function, the second request comprising: the token, and an indication of successful verification of the token.

[0169] In some aspects, a method includes: receiving, at a network repository function, registration information from a first network function, the registration information including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which token validation is delegated by the first network function; receiving a request for a token for access to the first network function from a second service communication agent; and sending the token to the second service communication agent.

[0170] In some example embodiments, the token includes a list of delegated domains.

[0171] In some example embodiments, the method further comprises, in response to receiving a subscription request from the first service communication agent for at least one profile associated with at least one network function in at least one domain, sending at least one profile to the first service communication agent, the at least one network function comprising a first network function, and the profile in the at least one profile associated with the first network function comprising at least one of the following: an indication or a delegate domain list.

[0172] In some example embodiments, the method further comprises, in response to receiving a subscription request for a profile associated with the first network function from the first service communication agent, sending a profile to the first service communication agent, the profile comprising at least one of: an indication or a delegate domain list.

[0173] In some aspects, a method includes: at a first network function, sending registration information to a network repository function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and receiving from a first service communication agent a second request for a service from the first network function, the second request including: a token for access to the first network function, and an indication of success of verification of the token.

[0174] In some example embodiments, the method further comprises, in response to the second request including the indication, determining whether the first serving communications agent belongs to a delegate domain list.

[0175] In some example embodiments, the method further comprises: verifying scope information included in the second request based on determining that the first service communication agent belongs to the delegated domain list.

[0176] In some example embodiments, the method further comprises: validating the token based on determining that the first service communication agent does not belong to the delegated domain list.

[0177] In some aspects, a device includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function, the token including a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and verifying the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0178] In some example embodiments, the apparatus is caused to validate the token by: in response to determining that there is a need for validation of the token, and in response to determining that the first serving communications agent belongs to a delegated domain list, validating the token.

[0179] In some example embodiments, the apparatus is further caused to: in response to successful verification of the token, send a second request for service to the first network function, the second request comprising: the token, and an indication of successful verification of the token.

[0180] In some aspects, a device includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function; and obtain a profile associated with the first network function, the profile including at least one of the following: an indication of whether delegation of token verification is allowed, or a list of delegated domains to which token verification is delegated by the first network function; and verify the token based on determining that the first service communication agent belongs to the delegated domain list.

[0181] In some example embodiments, the apparatus is caused to obtain a profile associated with a first network function by: sending a subscription request to a network repository function for at least one profile associated with at least one network function in at least one domain, the at least one network function including the first network function; receiving at least one profile from the network repository function; and obtaining a profile associated with the first network function from the at least one profile and based on the first request.

[0182] In some example embodiments, the subscription request includes instructing the network repository function to send an indication of at least one profile to the first service communications agent.

[0183] In some example embodiments, the apparatus is caused to obtain the profile associated with the first network function by: obtaining, based on the first request, from a network repository function, the profile associated with the first network function.

[0184] In some example embodiments, the apparatus is caused to validate the token by: in response to determining that there is a need for validation of the token, and in response to determining that the first serving communications agent belongs to a delegated domain list, validating the token.

[0185] In some example embodiments, the apparatus is further caused to: in response to successful verification of the token, send a second request for service to the first network function, the second request comprising: the token, and an indication of successful verification of the token.

[0186] In some aspects, an apparatus includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive, at a network repository function, registration information from a first network function, the registration information including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegated domains to which token validation is delegated by the first network function; receive, from a second service communication agent, a request for a token for access to the first network function; and send the token to the second service communication agent.

[0187] In some example embodiments, the token includes a list of delegated domains.

[0188] In some example embodiments, the apparatus is further caused to: in response to receiving a subscription request from the first service communication agent for at least one profile associated with at least one network function in at least one domain, send at least one profile to the first service communication agent, the at least one network function including the first network function, and the profile associated with the first network function in the at least one profile including at least one of the following: an indication or a delegate domain list.

[0189] In some example embodiments, the apparatus is further caused to: in response to receiving a subscription request for a profile associated with the first network function from the first serving communication agent, send a profile to the first serving communication agent, the profile comprising at least one of: an indication or a delegate domain list.

[0190] In some aspects, a device includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: send registration information to a network repository function at a first network function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains to which token verification is delegated by the first network function; and receive from a first service communication agent a second request for a service from the first network function, the second request including: a token for accessing the first network function, and an indication of success of verification of the token.

[0191] In some example embodiments, the apparatus is further caused to: in response to the second request including the indication, determine whether the first serving communications agent belongs to a trusted domain list.

[0192] In some example embodiments, the apparatus is further caused to: based on determining that the first serving communications agent belongs to a trusted domain list, verify the scope information included in the second request.

[0193] In some example embodiments, the apparatus is further caused to: based on determining that the first serving communications agent does not belong to the trusted domain list, verify the token.

[0194] In some aspects, an apparatus includes: a component for receiving, at a first service communication agent, a first request for a service from a first network function from a second service communication agent, the first request originating from the second network function and including a token for accessing the first network function, the token including a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegated domains; and a component for verifying the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0195] In some example embodiments, means for validating the token comprises means for validating the token in accordance with a determination that there is a need for token validation and in accordance with a determination that the first service communications agent belongs to a delegated domain list.

[0196] In some example embodiments, the apparatus further comprises means for sending a second request for services to the first network function in response to success of validation of the token, the second request comprising the token and an indication of success of validation of the token.

[0197] In some aspects, an apparatus includes: a component for receiving, at a first service communication agent, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and including a token for accessing the first network function; and a component for obtaining a profile associated with the first network function, the profile including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegated domains to which token validation is delegated by the first network function; and a component for validating the token based on determining that the first service communication agent belongs to the list of delegated domains.

[0198] In some example embodiments, means for obtaining a profile associated with a first network function includes: means for sending a subscription request for at least one profile associated with at least one network function in at least one domain to a network repository function, the at least one network function including the first network function; means for receiving the at least one profile from the network repository function; and means for obtaining the profile associated with the first network function from the at least one profile and based on the first request.

[0199] In some example embodiments, the subscription request includes instructing the network repository function to send an indication of at least one profile to the first service communications agent.

[0200] In some example embodiments, means for obtaining a profile associated with the first network function comprises means for obtaining the profile associated with the first network function from a network repository function based on the first request.

[0201] In some example embodiments, means for validating the token comprises means for validating the token based on determining that there is a need for validation of the token and based on determining that the first service communications agent belongs to a delegated domain list.

[0202] In some example embodiments, the apparatus further comprises means for sending a second request for services to the first network function in response to successful validation of the token, the second request comprising the token and an indication of successful validation of the token.

[0203] In some aspects, an apparatus includes: a component for receiving registration information from a first network function at a network repository function, the registration information including at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which token validation is delegated by the first network function; a component for receiving a request for a token for access to the first network function from a second service communication agent; and a component for sending the token to the second service communication agent.

[0204] In some example embodiments, the token includes a list of delegated domains.

[0205] In some example embodiments, the apparatus further comprises: means for sending at least one profile to the first service communication agent in response to receiving a subscription request from the first service communication agent for at least one profile associated with at least one network function in at least one domain, the at least one network function comprising the first network function, and the profile in the at least one profile associated with the first network function comprising at least one of the following: an indication or a delegate domain list.

[0206] In some example embodiments, the method further comprises, in response to receiving a subscription request for a profile associated with the first network function from the first service communication agent, sending a profile to the first service communication agent, the profile comprising at least one of: an indication or a delegate domain list.

[0207] In some aspects, a method includes: at a first network function, sending registration information to a network repository function, the registration information including at least one of: an indication of whether delegation of token verification is allowed, or a list of delegation domains to which token verification is delegated by the first network function; and receiving from a first service communication agent a second request for a service from the first network function, the second request including: a token for access to the first network function, and an indication of success of verification of the token.

[0208] In some example embodiments, the apparatus further comprises means for determining, in response to the second request including the indication, whether the first serving communications agent belongs to a trusted domain list.

[0209] In some example embodiments, the apparatus further comprises means for verifying scope information included in the second request based on determining that the first serving communications agent belongs to the delegated domain list.

[0210] In some example embodiments, the apparatus further comprises means for validating the token based on determining that the first serving communications agent does not belong to the delegated domain list.

[0211] In some aspects, a computer-readable medium includes program instructions stored thereon, which, when executed by a processor of a device, cause the device to perform methods according to some example embodiments of the present disclosure.

Claims

1. A device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: At a first serving communication agent, receiving, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and comprising a token for accessing the first network function, the token comprising a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information comprising at least one of the following: an indication of whether delegation of said token verification is permitted, or said delegation domain list; and Based on determining that the first service communication agent belongs to the delegated domain list, the token is verified.

2. The apparatus of claim 1 , wherein the apparatus is caused to verify the token by: Based on determining that there is a need for verification of the token, and based on determining that the first service communication agent belongs to the delegated domain list, verifying the token.

3. The apparatus according to claim 1, wherein the apparatus is further configured to: In response to success of the verification of the token, sending a second request for the service to the first network function, the second request comprising: The token, and an indication of the success of the verification of the token.

4. A device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: At a first serving communication agent, receiving, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and including a token for accessing the first network function; obtaining a profile associated with the first network function, the profile comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; and Based on determining that the first service communication agent belongs to the delegated domain list, the token is verified.

5. An apparatus according to claim 4 or 5, wherein the apparatus is caused to obtain the profile associated with the first network function by: sending, to a network repository function, a subscription request for at least one profile associated with at least one network function in at least one domain, the at least one network function including the first network function; receiving the at least one profile from the network repository function; as well as The profile associated with the first network function is obtained from the at least one profile and based on the first request.

6. The apparatus of claim 5, wherein the subscription request comprises a flag instructing the network repository function to send the at least one profile to the first service communication agent.

7. The apparatus of claim 4, wherein the apparatus is caused to obtain the profile associated with the first network function by: Based on the first request, the profile associated with the first network function is obtained from a network repository function.

8. An apparatus according to any one of claims 4 to 7, wherein the apparatus is caused to verify the token by: Based on determining that there is a need for verification of the token, and based on determining that the first service communication agent belongs to the delegated domain list, verifying the token.

9. The device according to any one of claims 4 to 8, wherein the device is further configured to: In response to success of the verification of the token, sending a second request for the service to the first network function, the second request comprising: The token, and an indication of the success of the verification of the token.

10. An apparatus comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: At the Network Repository feature, receiving registration information from a first network function, the registration information comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; receiving, from a second serving communications agent, a request for a token to access the first network function; as well as The token is sent to the second service communications agent. The apparatus of claim 10 , wherein the token comprises the trusted domain list.

12. The apparatus of claim 10, wherein the apparatus is further configured to: In response to receiving a subscription request for at least one profile associated with at least one network function in at least one domain from a first service communication agent, sending the at least one profile to the first service communication agent, the at least one network function including the first network function, and the profile associated with the first network function in the at least one profile including at least one of the following: the indication or the delegate domain list.

13. The apparatus of claim 10, wherein the apparatus is further configured to: In response to receiving a subscription request for a profile associated with the first network function from a first serving communication agent, sending the profile to the first serving communication agent, the profile including at least one of: the indication or the delegate domain list.

14. An apparatus comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: At the first network function, sending registration information to a network repository function, the registration information comprising at least one of: an indication of whether delegation of token verification is permitted, or a list of delegation domains to which the token verification is delegated by the first network function; as well as A second request for a service is received from the first service communication agent from the first network function, the second request including a token for accessing the first network function and an indication of success of verification of the token.

15. The apparatus of claim 14, wherein the apparatus is further configured to: In response to the second request including the indication, determining whether the first serving communications agent belongs to the trusted domain list.

16. The apparatus of claim 15, wherein the apparatus is further configured to: Based on determining that the first service communication agent belongs to the delegated domain list, scope information included in the second request is verified.

17. The apparatus of claim 15, wherein the apparatus is further configured to: Based on determining that the first service communication agent does not belong to the delegated domain list, the token is verified.

18. A method comprising: At a first serving communication agent, receiving, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and comprising a token for accessing the first network function, the token comprising a list of delegated domains to which token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information comprising at least one of the following: an indication of whether delegation of said token verification is permitted, or said delegation domain list; and Based on determining that the first service communication agent belongs to the delegated domain list, the token is verified.

19. A method comprising: At a first serving communication agent, receiving, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and including a token for accessing the first network function; obtaining a profile associated with the first network function, the profile comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; and Based on determining that the first service communication agent belongs to the delegated domain list, the token is verified.

20. A method comprising: At the Network Repository feature, receiving registration information from a first network function, the registration information comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; receiving, from a second serving communications agent, a request for a token to access the first network function; as well as The token is sent to the second service communications agent.

21. A method comprising: At the first network function, sending registration information to a network repository function, the registration information comprising at least one of: an indication of whether delegation of token verification is permitted, or a list of delegation domains to which the token verification is delegated by the first network function; as well as A second request for a service is received from the first service communication agent from the first network function, the second request including a token for accessing the first network function and an indication of success of verification of the token.

22. An apparatus comprising: means for receiving, at a first service communication agent, from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and comprising a token for accessing the first network function, the token comprising a list of delegation domains to which the token verification is delegated by the first network function, the token being generated by a network repository function based on registration information from the first network function, the registration information comprising at least one of: an indication of whether delegation verified by the token is allowed, or the list of delegation domains; as well as means for validating the token based on determining that the first service communications agent belongs to the delegated domain list.

23. An apparatus comprising: means for receiving, at a first service communication agent from a second service communication agent, a first request for a service from a first network function, the first request originating from the second network function and comprising a token for access to the first network function; means for obtaining a profile associated with the first network function, the profile comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; as well as means for validating the token based on determining that the first service communications agent belongs to the delegated domain list.

24. An apparatus comprising: means for receiving, at a network repository function, registration information from a first network function, the registration information comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; means for receiving, from a second serving communications agent, a request for a token for access to said first network function; as well as Means for sending the token to the second service communications agent.

25. An apparatus comprising: means for sending registration information at the first network function to the network repository function, the registration information comprising at least one of: an indication of whether delegation of token validation is allowed, or a list of delegation domains to which the token validation is delegated by the first network function; as well as Means for receiving, from the first service communication agent, a second request for a service from a first network function, the second request comprising a token for access to the first network function and an indication of success of validation of the token.

26. A non-transitory computer-readable medium comprising program instructions for causing an apparatus to at least perform the method of claims 18 to 21.

Images