Network nodes and methods therein for network function interconnection

Abstract

The present disclosure provides a method (300) in a first Network Function, NF. The method (300) includes transmitting (310), to a second NF, authorization delegation information enabling the second NF to authorize service Application Program Interface, API, access for an API invoker.

Description

NETWORK NODES AND METHODS THEREIN FOR NETWORK FUNCTION INTERCONNECTIONTECHNICAL FIELDThe present disclosure relates to communication technology, and more particularly, to network nodes and methods therein for network function interconnection.BACKGROUNDIn the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.222, V19.0.0, which is incorporated herein by reference in its entirety, Common Application Program Interface (API) Framework (CAPIF) for 3GPP northbound APIs is introduced. Within the standardization of CAPIF, the 3GPP has addressed a variety of different processes, including onboarding / offboarding of Application Functions, service discovery and management, event subscription and notification, security and charging. Security mechanisms such as authentication, authorization and interface security for CAPIF is specified in TS 33.122, V18.2.0, which is incorporated herein by reference in its entirety. There are three authentication and authorization mechanisms specified in clause 6.5.2 in TS 33.122. An API invoker learns API Exposing Function (AEF) supported mechanism (s) from a CAPIF Core Function (CCF) , which is specified in clause 6.3.1.2 of TS 33.122.Service federation between different service providers is important for an application enabler to support service sharing. Two organizations with a business relationship that have each deployed a CAPIF may need to interoperate to allow API invokers in each trust domain to utilize service APIs from both CAPIF providers as illustrated in Fig. 1. In Fig. 1, interconnection between CAPIF provider A and CAPIF provider B allows API invokers in the trust domain of CAPIF provider A to utilize service APIs from CAPIF provider B, and vice versa.Fig. 2A shows a more detailed architectural model for CAPIF interconnection, which allows API invokers of a CAPIF provider to utilize service APIs from a 3rd party CAPIF provider. In the architecture shown in Fig. 2A, the API provider domain functions are registered in the CCF within the same trusted domain. The CCFs are connected via CAPIF-6e, in order to share service APIs. The API provider domain functions in one domain do not see the interconnected CCF in the other domain. The API invokers onboarded (registered) in one CAPIF provider can consume service APIs provided in the other domain via CAPIF-2e.Fig. 2B shows an architectural model for CAPIF interconnection within a same CAPIF provider domain, which allows API invokers of CCF 1 to utilize service APIs from CCF2. Both CCF1 and CCF 2 are hosted within the trust domain of the CAPIF provider A.SUMMARYThe existing procedures supporting CAPIF interconnection are described in clause 8.25 of TS 23.222, including service API publish / retrieval / update / unpublish and discovery over CAPIF-6 / 6e reference point. However, for CAPIF interconnection, authentication and / or authorization of an API invoker to access a service API has not been specified. In either Fig. 2A or Fig. 2B for example, when an API invoker registered in (or served by) CCF1 requests access to a service API provided by an AEF registered in (or served by) CCF2, the existing procedures defined for the non-interconnection scenario, e.g., in clause 8.11.3 of TS 23.222 and clause 6.5.2 of TS 33.122, do not apply.It is an object of the present disclosure to provide network nodes and methods therein, capable of solving or at least mitigating at least one of the above problems.According to a first aspect of the present disclosure, a method in a first Network Function (NF) is provided. The method includes transmitting, to a second NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker.In an embodiment, the authorization delegation information may contain information needed for the second NF to authorize the service API access.In an embodiment, the authorization delegation information may be transmitted in an interconnection API publish request or in response to a request from the second NF.In an embodiment, the method may further include transmitting, to the second NF, a request for revoking authorization of the API invoker.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.According to a second aspect of the present disclosure, a method in a second NF is provided. The method includes receiving, from a first NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker.In an embodiment, the method may further include receiving, from the API invoker, an authorization request for accessing a service API, and transmitting, to the API invoker, an authorization response containing authorization information for the API invoker to access the service API.In an embodiment, the method may further include receiving, from the first NF, a request for revoking authorization of the API invoker, and revoking the authorization of the API invoker in response to the request.According to a third aspect of the present disclosure, a method in a first NF is provided. The method includes receiving, from a second NF, an authorization request for authorizing access to a service API for an API invoker. The method further includes transmitting, to the second NF, an authorization response containing authorization information for the API invoker to access the service API.In an embodiment, the authorization request may contain information on the API invoker.In an embodiment, the method may further include transmitting, to the second NF, a notification indicating revocation of authorization of the API invoker.According to a fourth aspect of the present disclosure, a method in a second NF is provided. The method includes transmitting, to a first NF, an authorization request for authorizing access to a service API for an API invoker. The method further includes receiving, from the first NF, an authorization response containing authorization information for the API invoker to access the service API. In an embodiment, the method may further include transmitting, to the API invoker, the authorization information.In an embodiment, the method may further include receiving, from the first NF, a notification indicating revocation of authorization of the API invoker, and transmitting, to the API invoker, a notification indicating revocation of authorization of the API invoker.According to a fifth aspect of the present disclosure, a method in a first NF is provided. The method includes receiving, from a second NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker.In an embodiment, the method may further include transmitting, to the second NF, a request for the access control policy or the security information.In an embodiment, the method may further include receiving, from an AEF, a request for the access control policy or the security information, and transmitting, to the AEF, the information on the access control policy or the security information.In an embodiment, the information on the access control policy or the security information may be received as a response to a request towards the second NF.In an embodiment, the security information may include one or more of a key, a root certificate of the API invoker, a root certificate of the second NF, or a certificate of the second NF.According to a sixth aspect of the present disclosure, a method in a second NF is provided. The method includes transmitting, to a first NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker.In an embodiment, the method may further include receiving, from the first NF, a request for the access control policy or the security information.According to a seventh aspect of the present disclosure, a method in a first NF is provided. The method includes receiving, from a second NF, a request for capability information of an AEF. The method further includes transmitting, to the second NF, the capability information. In an embodiment, the capability information may include a security method supported by the AEF.According to an eighth aspect of the present disclosure, a method in a second NF is provided. The method includes transmitting, to a first NF, a request for capability information of an AEF. The method further includes receiving, from the first NF, the capability information.According to a ninth aspect of the present disclosure, a method in a first NF is provided. The method includes receiving, from a second NF, a notification that an API invoker is no longer valid. The method further includes transmitting, to an AEF, a notification message indicating that the API invoker is no longer valid.In an embodiment, the method may further include receiving, from the AEF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted, and forwarding the notification acknowledgement message to the second NF.According to a tenth aspect of the present disclosure, a method in a second NF is provided. The method includes transmitting, to a first NF, a notification that an API invoker is no longer valid. The method further includes receiving, from the first NF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted.According to an eleventh aspect of the present disclosure, a network node is provided. The network node includes a communication interface, a processor, and a memory. The memory contains instructions executable by the processor whereby the network node is operative to, when implementing a first NF, perform the method according to any of the above first, third, fifth, seventh, or ninth aspect, or when implementing a second NF, perform the method according to any of the above second, fourth, sixth, eighth, or tenth aspect.According to a twelfth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium has computer-readable instructions stored thereon. The computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing a first NF, perform the method according to any of the above first, third, fifth, seventh, or ninth aspect, or when implementing a second NF, perform the method according to any of the above second, fourth, sixth, eighth, or tenth aspect.With the embodiments of the present disclosure, a first NF (e.g., an NF serving an AEF) and a second NF (e.g., an NF serving an API invoker) may exchange information required for authentication and / or authorization of the API invoker to access a service API exposed by the AEF, such that the API invoker can be authenticated and / or authorized properly in e.g., a CAPIF interconnection.BRIEF DESCRIPTION OF THE DRAWINGSThe above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the figures, in which:Fig. 1 is a schematic diagram showing interconnection between CAPIF providers;Figs. 2A and 2B are schematic diagrams each showing a functional architecture for CAPIF interconnection;Fig. 3 is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;Fig. 4 is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;Fig. 5 is a flowchart illustrating a method in a first NF according to another embodiment of the present disclosure;Fig. 6 is a flowchart illustrating a method in a second NF according to another embodiment of the present disclosure;Figs. 7A～7C are sequence diagrams showing procedures related to API invoker authorization according to an embodiment of the present disclosure;Fig. 8 is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;Fig. 9 is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;Figs. 10A and 10B are sequence diagrams showing procedures for obtaining policy / information according to an embodiment of the present disclosure;Fig. 11 is a flowchart illustrating a method in a first NF according to an embodiment of the present disclosure;Fig. 12 is a flowchart illustrating a method in a second NF according to an embodiment of the present disclosure;Fig. 13 is a flowchart illustrating a method in a first NF according to another embodiment of the present disclosure;Fig. 14 is a flowchart illustrating a method in a second NF according to another embodiment of the present disclosure;Fig. 15 are block diagrams of network nodes according to embodiments of the present disclosure;Fig. 16 shows an example of a communication system in accordance with some embodiments of the present disclosure;Fig. 17 is a block diagram of an exemplary host, which may be an embodiment of the host of Fig. 16, in accordance with various aspects described herein;Fig. 18 is a block diagram illustrating an exemplary virtualization environment in which functions implemented by some embodiments may be virtualized;Fig. 19 shows a communication diagram of an exemplary host communicating via an exemplary network node with an exemplary UE over a partially wireless connection in accordance with some embodiments of the present disclosure; andFigs. 20A～20F are figures used in appendixes.DETAILED DESCRIPTIONIn the present disclosure, a network function, or NF (i.e., NF instance) , can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The term “network node” refers to any physical or virtual node configured to implement a network function.References in the specification to "one embodiment, " "an embodiment, " "an example embodiment, " and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a" , "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" , "comprising" , "has" , "having" , "includes" and / or "including" , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.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 skills in the art to which this disclosure belongs.Fig. 3 is a flowchart illustrating a method 300 according to an embodiment of the present disclosure. The method 300 can be performed by a first NF, which may be an NF (e.g., a CCF) serving an AEF.At block 310, the first NF transmits, to a second NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker. Here, the second NF may be an NF (e.g., a CCF) serving the API invoker.In an example, the authorization delegation information may contain information needed for the second NF to authorize the service API access. For example, the authorization delegation information may contain information needed for generating a token that is later used for authorizing the API invoker to access a service API.In an example, the authorization delegation information may be transmitted in an interconnection API publish request or in response to a request (e.g., an authorization request) from the second NF.In an example, the first NF may transmit, to the second NF, a request for revoking authorization of the API invoker. The request may contain information on the API invoker, the AEF, and a service API the API invoker was authorized to invoke.Then, after the second NF revokes / invalidates the authorization of the API invoker, the first NF may receive a response from the second NF.Fig. 4 is a flowchart illustrating a method 400 according to an embodiment of the present disclosure. The method 400 can be performed by a second NF, which may be an NF (e.g., a CCF) serving an API invoker.At block 410, the second NF receives, from a first NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker. Here, the first NF may be an NF (e.g., a CCF) serving an AEF.In an example, the authorization delegation information may contain information needed for the second NF to authorize the service API access. For example, the authorization delegation information may contain information needed for generating a token that is later used for authorizing the API invoker to access a service API.In an example, the authorization delegation information may be received in an interconnection API publish request or as a response to a request (e.g., an authorization request) towards the first NF.In an example, the second NF may receive, from the API invoker, an authorization request for accessing a service API. The authorization request may contain information on the API invoker and / or information on the service API. Then, the second NF may transmit, to the API invoker, an authorization response containing authorization information for the API invoker to access the service API. The authorization information may include a token that is later used for authorizing the API invoker to access the service API.In an example, the second NF may receive, from the first NF, a request for revoking authorization of the API invoker. The request may contain information on the API invoker, the AEF, and the service API. Then, the second NF may revoke / invalidate the authorization of the API invoker in response to the request, and accordingly transmit a response to the first NF.Fig. 5 is a flowchart illustrating a method 500 according to an embodiment of the present disclosure. The method 500 can be performed by a first NF, which may be an NF (e.g., a CCF) serving an AEF.At block 510, the first NF receives, from a second NF, an authorization request for authorizing access to a service API for an API invoker. Here, the second NF may be an NF (e.g., a CCF) serving the API invoker. The authorization request may contain information on the API invoker and / or information on the service API.At block 520, the first NF transmits, to the second NF, an authorization response containing authorization information for the API invoker to access the service API. For example, the authorization information may include a token that is later used for authorizing the API invoker to access the service API.In an example, the first NF may transmit, to the second NF, a notification indicating revocation of authorization of the API invoker. For example, the first NF may revoke / invalidate the authorization of the API invoker.Fig. 6 is a flowchart illustrating a method 600 according to an embodiment of the present disclosure. The method 600 can be performed by a second NF, which may be an NF (e.g., a CCF) serving an API invoker.At block 610, the second NF transmits, to a first NF, an authorization request for authorizing access to a service API for an API invoker. Here, the first NF may be an NF (e.g., a CCF) serving an AEF. The authorization request may contain information on the API invoker and / or information on the service API.At block 620, the second NF receives, from the first NF, an authorization response containing authorization information for the API invoker to access the service API. For example, the authorization information may include a token that is later used for authorizing the API invoker to access the service API.In an example, the second NF may further transmit the authorization information to the API invoker.In an example, the second NF may receive, from the first NF, a notification indicating revocation of authorization of the API invoker, and transmit, to the API invoker, a notification indicating revocation of authorization of the API invoker.The above methods 300～600 will be further explained below with reference to Figs. 7A～7C. In each of Figs. 7A～7C, it is assumed that CCF-Aserves an AEF and CCF-B serves an API invoker which requests for access to a service API exposed by the AEF.Fig. 7A shows a procedure of service API publish for CAPIF interoperation. As shown, at Step 1, CCF-Agets service APIs to be shared with CCF-B from an API publish function. At Step 2, CCF-Asends an interconnection API publish request to CCF-B with details of at least one of service APIs or service API category information. CCF-Aalso determines whether CCF-B can authorize service API access and, if so, sends authorization delegation information to CCF-B in the interconnection API publish request. At Step 3, CCF-B stores the service API information or service API category provided by CCF-A. At Step 4, CCF-B provides an interconnection API publish response to CCF-Aindicating success or failure result and triggers notifications to subscribed API invokers.Fig. 7B shows a procedure of authorization of service API access. It is assumed here that an API invoker has discovered service APIs provided by an AEF, the API invoker and CCF-B are in a same trusted domain, the AEF and CCF-Aare in a same trusted domain, CCF-Aand CCF-B are connected to each other and have business agreement for service API authorization, and CCF-Ais the authorization function for service API access on the AEF.As shown in Fig. 7B, at Step 1, the API invoker sends an obtain service API authorization request to CCF-B for obtaining permission to access a service API by including API invoker identity information and any information required for authentication of the API invoker. At Step 2, after successful authentication / validation of the API invoker, if CCF-B determines that authorization of service API access cannot be done by itself alone, then CCF-B sends an obtain API authorization request to CCF-A. In the request, CCF-B can include information on the API invoker such that the CCF-Acan execute the authorization. On the other hand, If CCF-B has been permitted by CCF-Ato authorize service API access (e.g., in the authorization delegation information as described in Fig. 7A) , it executes the authorization procedure defined in clause 8.11.3 of TS 23.222 without interaction with CCF-A. At Steps 3 and 4, based on the API invoker′ssubscription information, authorization information to access the service API is sent to the API invoker (via CCF-B) in the obtain service API authorization response.Fig. 7C shows a procedure of revoking authorization of an API invoker. It is assumed here that CCF-Ais triggered to revoke an API invoker's authorization for service API access. As shown, at Step 1, if CCF-B has been delegated with service API authorization (e.g., in the authorization delegation information as described in Fig. 7A) , CCF-Asends a revoke API invoker authorization request to CCF-B with information on the API invoker, the AEF and the service API. At Step 2, CCF-B invalidates the API invoker's authorization to access the service API. At Step 3, CCF-B sends a revoke API invoker authorization response to CCF-A.As an alternative to Steps 1 to 3, if CCF-Ahas performed service API authorization, at Step 4, CCF-Asends a revoke API invoker authorization notify to CCF-B. Then, at Step 5, CCF-Ainvalidates the API invoker's authorization to access the service API. At Step 6, CCF-B sends a revoke API invoker authorization notify to the API invoker.Fig. 8 is a flowchart illustrating a method 800 according to an embodiment of the present disclosure. The method 800 can be performed by a first NF, which may be an NF (e.g., a CCF) serving an AEF.At block 810, the first NF receives, from a second NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker. Here, the second NF may be an NF (e.g., a CCF) serving the API invoker.For example, the access control policy may include one or more of volume limit, time limit, rate limit, etc., as shown in Table E-1 of TS 23.222. The security information may include information for authentication and / or authorization of the API invoker, such as a key, a root certificate of the API invoker, a root certificate of the second NF, and / or a certificate of the second NF.In an example, the information on the access control policy or the security information may be received as a response to a request towards the second NF.In an example, e.g., before the block 810, the first NF may transmit, to the second NF, a request for the access control policy or the security information.In an example, e.g., before the block 810, the first NF may receive, from an AEF, a request for the access control policy or the security information. The first NF may transmit, to the AEF, the information on the access control policy or the security information, e.g., after the block 810.Fig. 9 is a flowchart illustrating a method 900 according to an embodiment of the present disclosure. The method 900 can be performed by a second NF, which may be an NF (e.g., a CCF) serving an API invoker.At block 910, the second NF transmits, to a first NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker. Here, the first NF may be an NF (e.g., a CCF) serving an AEF.For example, the access control policy may include one or more of volume limit, time limit, rate limit, etc., as shown in Table E-1 of TS 23.222. The security information may include information for authentication and / or authorization of the API invoker, such as a key, a root certificate of the API invoker, a root certificate of the second NF, and / or a certificate of the second NF.In an example, e.g., before the block 910, the second NF may receive, from the first NF, a request for the access control policy or the security information. In an example, the information on the access control policy or the security information may be transmitted in response to a request from the first NF.The above methods 800 and 900 will be further explained below with reference to Figs. 10A and 10B. In each of Figs. 10A and 10B, it is assumed that CCF-Aserves an AEF and CCF-B serves an API invoker which requests for access to a service API exposed by the AEF.Fig. 10A shows a procedure for obtaining access control policy in CAPIF interoperation. It is assumed here that the AEF is hosting a service API but a policy to perform access control is not available at the AEF, CCF-B has available access control policies corresponding to one or more service APIs, and the AEF and CCF-Aare in a same trusted domain.As shown in Fig. 10A, at Step 1, the AEF sends an obtain access control policy request to CCF-Afor obtaining the policy to perform access control on service API invocations by including details of the hosted service API. At Step 2, after successful authentication / validation of the AEF, if CCF-Adetermines that the service API access control policy authorization cannot be done by itself alone, then CCF-Asends an obtain access control policy request to CCF-B. In the request, the CCF-Acan also send the API invoker ID received from the AEF. On the other hand, if CCF-Ahas enough access control policies available, it executes the procedure defined in clause 8.12.3 of TS 23.222 without interaction with CCF-B. At Steps 3 and 4, CCF-B determines an appropriate access control policy for service APIs upon the request sent by CCF-A, and sends the access control policy information to the AEF (via CCF-A) in an obtain access control policy response.Fig. 10B shows a procedure for obtaining security information in CAPIF interoperation. It is assumed here that the AEF has no security information available for authentication and / or authorization, CCF-B has security information available for authentication and / or authorization corresponding to one or more service APIs, and the AEF and CCF-Aare in a same trusted domain.As shown in Fig. 1 0B, at Step 1, the AEF sends an obtain security information request to CCF-Afor obtaining the authentication and / or authorization information to be used in service API invocations by including details of an API invoker and a hosted service API. At Step 2, after successful authentication / validation of the AEF, if CCF-Adetermines that it has no security information, then CCF-Asends an obtain security information request to CCF-B. On the other hand, if CCF-Ahas security information available, it executes the procedure defined in clause 8.14.3, clause 8.15.3 or clause 8.16.3 of TS 23.222 without interaction with CCF-B. At Steps 3 and 4, the security information required for service API invocations is sent to the AEF (via CCF-A) in an obtain security information response.Fig. 11 is a flowchart illustrating a method 1100 according to an embodiment of the present disclosure. The method 1100 can be performed by a first NF, which may be an NF (e.g., a CCF) serving an AEF.At block 1110, the first NF receives, from a second NF, a request for capability information of an AEF. Here, the second NF may be an NF (e.g., a CCF) serving the API invoker.At block 1120, the first NF transmits, to the second NF, the capability information.In an example, the capability information may include a security method supported by the AEF, e.g., Method 1, 2, or 3 defined in clause 6.5.2.1, 6.5.2.2, and 6.5.2.3 of TS 33.122.Fig. 12 is a flowchart illustrating a method 1200 according to an embodiment of the present disclosure. The method 1200 can be performed by a second NF, which may be an NF (e.g., a CCF) serving an API invoker.At block 1210, the second NF transmits, to a first NF, a request for capability information of an AEF. Here, the first NF may be an NF (e.g., a CCF) serving an AEF.At block 1220, the second NF receives, from the first NF, the capability information.In an example, the capability information may include a security method supported by the AEF, e.g., Method 1, 2, or 3 defined in clause 6.5.2.1, 6.5.2.2, and 6.5.2.3 of TS 33.122.Fig. 13 is a flowchart illustrating a method 1300 according to an embodiment of the present disclosure. The method 1300 can be performed by a first NF, which may be an NF (e.g., a CCF) serving an AEF.At block 1310, the first NF receives, from a second NF, a notification that an API invoker is no longer valid. Here, the second NF may be an NF (e.g., a CCF) serving the API invoker.At block 1320, the first NF transmits, to an AEF, a notification message indicating that the API invoker is no longer valid.In an example, e.g., after the block 1320, the first NF may further receive, from the AEF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted, and forward the notification acknowledgement message to the second NF.Fig. 14 is a flowchart illustrating a method 1400 according to an embodiment of the present disclosure. The method 1400 can be performed by a second NF, which may be an NF (e.g., a CCF) serving an API invoker.At block 1410, the second NF transmits, to a first NF, a notification that an Application Program Interface, API, invoker is no longer valid. Here, the first NF may be an NF (e.g., a CCF) serving an AEF.At block 1420, the second NF receives, from the first NF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted.In some embodiments, a NF node (e.g., first NF node or second NF node) is provided for implementing any of the above methods 300～600, 800～900, and 1100～1400. The NF node includes one or more units for performing the step (s) of any of the above methods 300～600, 800～900, and 1100～1400.Fig. 15 is a block diagram of a network node 1500 according to an embodiment of the present disclosure.The network node 1500 includes a communication interface 1510, a processor 1520 and a memory 1530.The memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 3. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF: transmit, to a second NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker.In an embodiment, the authorization delegation information may contain information needed for the second NF to authorize the service API access.In an embodiment, the authorization delegation information may be transmitted in an interconnection API publish request or in response to a request from the second NF.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the first NF: transmit, to the second NF, a request for revoking authorization of the API invoker.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF. Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 4. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF: receive, from a first NF, authorization delegation information enabling the second NF to authorize service API access for an API invoker.In an embodiment, the authorization delegation information may contain information needed for the second NF to authorize the service API access.In an embodiment, the authorization delegation information may be received in an interconnection API publish request or as a response to a request towards the first NF.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the second NF: receive, from the API invoker, an authorization request for accessing a service API, and transmit, to the API invoker, an authorization response containing authorization information for the API invoker to access the service API.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the second NF:receive, from the first NF, a request for revoking authorization of the API invoker, and revoke the authorization of the API invoker in response to the request.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 5. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF: receive, from a second NF, an authorization request for authorizing access to a service API for an API invoker; and transmit, to the second NF, an authorization response containing authorization information for the API invoker to access the service API.In an embodiment, the authorization request may contain information on the API invoker.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the first NF: transmit, to the second NF, a notification indicating revocation of authorization of the API invoker.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 6. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF: transmit, to a first NF, an authorization request for authorizing access to a service API for an API invoker; and receive, from the first NF, an authorization response containing authorization information for the API invoker to access the service API.In an embodiment, the authorization request may contain information on the API invoker.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the second NF: transmit, to the API invoker, the authorization information.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the second NF: receive, from the first NF, a notification indicating revocation of authorization of the API invoker, and transmit, to the API invoker, a notification indicating revocation of authorization of the API invoker.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 8. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF: receive, from a second NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the first NF: transmit, to the second NF, a request for the access control policy or the security information. In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the first NF: receive, from an AEF, a request for the access control policy or the security information, and transmit, to the AEF, the information on the access control policy or the security information.In an embodiment, the information on the access control policy or the security information may be received as a response to a request towards the second NF. In an embodiment, the security information may include one or more of a key, a root certificate of the API invoker, a root certificate of the second NF, or a certificate of the second NF.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 9. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF: transmit, to a first NF, information on an access control policy or security information for authentication and / or authorization associated with an API invoker.In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the second NF: receive, from the first NF, a request for the access control policy or the security information.In an embodiment, the information on the access control policy or the security information may be transmitted in response to a request from the first NF.In an embodiment, the security information may include one or more of a key, a root certificate of the API invoker, a root certificate of the second NF, or a certificate of the second NF.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker. In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 11. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF: receive, from a second NF, a request for capability information of an AEF; and transmit, to the second NF, the capability information.In an embodiment, the capability information may include a security method supported by the AEF.In an embodiment, the first NF may serve the AEF and the second NF may serve an API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 12. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF: transmit, to a first NF, a request for capability information of an AEF; and receive, from the first NF, the capability information.In an embodiment, the capability information may include a security method supported by the AEF.In an embodiment, the first NF may serve the AEF and the second NF may serve an API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 13. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a first NF: receive, from a second NF, a notification that an API invoker is no longer valid; and transmit, to an AEF, a notification message indicating that the API invoker is no longer valid. In an embodiment, the memory 1530 may further contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing the first NF: receive, from the AEF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted, and forward the notification acknowledgement message to the second NF.In an embodiment, the first NF may serve the AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.Alternatively, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 14. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to, when implementing a second NF: transmit, to a first NF, a notification that an API invoker is no longer valid; and receive, from the first NF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted.In an embodiment, the first NF may serve an AEF and the second NF may serve the API invoker.In an embodiment, the first NF and the second NF may each be a CCF.The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code / computer readable instructions, which when executed by the processor 1520 causes the network node 1500 to perform the actions, e.g., of the procedure described earlier in conjunction with any of Figs. 3-6, 8-9, and 11-14.The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in any of Figs. 3-6, 8-9, and 11-14.The processor may be a single CPU (Central Processing Unit) , but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and / or related chips sets and / or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs) . The processor may also comprise board memory for caching purposes. The computer program may be carried in a computer program product connected to the processor. The computer program product may comprise a non-transitory computer readable storage medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random Access Memory (RAM) , a Read-Only Memory (ROM) , or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories.Fig. 16 shows an example of a communication system 1600 in accordance with some embodiments. In the example, the communication system 1600 includes a telecommunication network 1602 that includes an access network 1604, such as a radio access network (RAN) , and a core network 1606, which includes one or more core network nodes 1608. The access network 1604 includes one or more access network nodes, such as network nodes 1610a and 1610b (one or more of which may be generally referred to as network nodes 1610) , or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1610 facilitate direct or indirect connection of user equipment (UE) , such as by connecting UEs 1612a, 1612b, 1612c, and 1612d (one or more of which may be generally referred to as UEs 1612) to the core network 1606 over one or more wireless connections.Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1600 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1600 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.The UEs 1612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1610 and other communication devices. Similarly, the network nodes 1610 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1612 and / or with other network nodes or equipment in the telecommunication network 1602 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1602.In the depicted example, the core network 1606 connects the network nodes 1610 to one or more hosts, such as host 1616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1606 includes one more core network nodes (e.g., core network node 1608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1608. Example core network nodes include functions of one or more of a Network Repository Function (NRF) , Mobile Switching Center (MSC) , Mobility Management Entity (MME) , Home Subscriber Server (HSS) , Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Server Function (AUSF) , Subscription Identifier De-concealing function (SIDF) , Unified Data Management (UDM) , Security Edge Protection Proxy (SEPP) , Network Exposure Function (NEF) , and / or a User Plane Function (UPF) .The host 1616 may be under the ownership or control of a service provider other than an operator or provider of the access network 1604 and / or the telecommunication network 1602, and may be operated by the service provider or on behalf of the service provider. The host 1616 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.As a whole, the communication system 1600 of Fig. 16 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM) ; Universal Mobile Telecommunications System (UMTS) ; Long Term Evolution (LTE) , and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G) ; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax) , Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.In some examples, the telecommunication network 1602 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunications network 1602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1602. For example, the telecommunications network 1602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)  / Massive IoT services to yet further UEs.In some examples, the UEs 1612 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1604. Additionally, a UE may be configured for operating in single-or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC) , such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio -Dual Connectivity (EN-DC) .In the example, the hub 1614 communicates with the access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612c and / or 1612d) and network nodes (e.g., network node 1610b) . In some examples, the hub 1614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1614 may be a broadband router enabling access to the core network 1606 for the UEs. As another example, the hub 1614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1610, or by executable code, script, process, or other instructions in the hub 1614. As another example, the hub 1614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1614 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1614 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.The hub 1614 may have a constant / persistent or intermittent connection to the network node 1610b. The hub 1614 may also allow for a different communication scheme and / or schedule between the hub 1614 and UEs (e.g., UE 1612c and / or 1612d) , and between the hub 1614 and the core network 1606. In other examples, the hub 1614 is connected to the core network 1606 and / or one or more UEs via a wired connection. Moreover, the hub 1614 may be configured to connect to an M2M service provider over the access network 1604 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1610 while still connected via the hub 1614 via a wired or wireless connection. In some embodiments, the hub 1614 may be a dedicated hub -that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 161 0b. In other embodiments, the hub 1614 may be a non-dedicated hub -that is, a device which is capable of operating to route communications between the UEs and network node 1610b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.Fig. 17 is a block diagram of a host 1700, which may be an embodiment of the host 1616 of Fig. 16, in accordance with various aspects described herein. As used herein, the host 1700 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1700 may provide one or more services to one or more UEs.The host 1700 includes processing circuitry 1702 that is operatively coupled via a bus 1704 to an input / output interface 1706, a network interface 1708, a power source 1710, and a memory 1712. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such that the descriptions thereof are generally applicable to the corresponding components of host 1700.The memory 1712 may include one or more computer programs including one or more host application programs 1714 and data 1716, which may include user data, e.g., data generated by a UE for the host 1700 or data generated by the host 1700 for a UE. Embodiments of the host 1700 may utilize only a subset or all of the components shown. The host application programs 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC) , High Efficiency Video Coding (HEVC) , Advanced Video Coding (AVC) , MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC) , MPEG, G. 711) , including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems) . The host application programs 1714 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1700 may select and / or indicate a different host for over-the-top services for a UE. The host application programs 1714 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP) , Real-Time Streaming Protocol (RTSP) , Dynamic Adaptive Streaming over HTTP (MPEG-DASH) , etc.Fig. 18 is a block diagram illustrating a virtualization environment 1800 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1800 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host) , then the node may be entirely virtualized.Applications 1802 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) are run in the virtualization environment 1800 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.Hardware 1804 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as hypervisors or virtual machine monitors (VMMs) ) , provide VMs 1808a and 1808b (one or more of which may be generally referred to as VMs 1808) , and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1806 may present a virtual operating platform that appears like networking hardware to the VMs 1808.The VMs 1808 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1806. Different embodiments of the instance of a virtual appliance 1802 may be implemented on one or more of VMs 1808, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV) . NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.In the context ofNFV, a VM 1808 may be a software implementation of a physical machine that runs programs as ifthey were executing on a physical, non-virtualized machine. Each of the VMs 1808, and that part of hardware 1804 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context ofNFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1808 on top of the hardware 1804 and corresponds to the application 1802.Hardware 1804 may be implemented in a standalone network node with generic or specific components. Hardware 1804 may implement some functions via virtualization. Alternatively, hardware 1804 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1810, which, among others, oversees lifecycle management of applications 1802. In some embodiments, hardware 1804 is coupled to one or more radio units that each includes one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1812 which may alternatively be used for communication between hardware nodes and radio units.Fig. 19 shows a communication diagram of a host 1902 communicating via a network node 1904 with a UE 1906 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1612a of Fig. 16) , network node (such as network node 1610a of Fig. 16) , and host (such as host 1616 of Fig. 16 and / or host 1700 of Fig. 17) discussed in the preceding paragraphs will now be described with reference to Fig. 19.Like host 1700, embodiments of host 1902 include hardware, such as a communication interface, processing circuitry, and memory. The host 1902 also includes software, which is stored in or accessible by the host 1902 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1906 connecting via an over-the-top (OTT) connection 1950 extending between the UE 1906 and host 1902. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1950.The network node 1904 includes hardware enabling it to communicate with the host 1902 and UE 1906. The connection 1960 may be direct or pass through a core network (like core network 1606 of Fig. 16) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.The UE 1906 includes hardware and software, which is stored in or accessible by UE 1906 and executable by the UE's processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1906 with the support of the host 1902. In the host 1902, an executing host application may communicate with the executing client application via the OTT connection 1950 terminating at the UE 1906 and host 1902. In providing the service to the user, the UE′sclient application may receive request data from the host′shost application and provide user data in response to the request data. The OTT connection 1950 may transfer both the request data and the user data. The UE′s client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1950.The OTT connection 1950 may extend via a connection 1960 between the host 1902 and the network node 1904 and via a wireless connection 1970 between the network node 1904 and the UE 1906 to provide the connection between the host 1902 and the UE 1906. The connection 1960 and wireless connection 1970, over which the OTT connection 1950 may be provided, have been drawn abstractly to illustrate the communication between the host 1902 and the UE 1906 via the network node 1904, without explicit reference to any intermediary devices and the precise routing of messages via these devices.As an example of transmitting data via the OTT connection 1950, in step 1908, the host 1902 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1906. In other embodiments, the user data is associated with a UE 1906 that shares data with the host 1902 without explicit human interaction. In step 1910, the host 1902 initiates a transmission carrying the user data towards the UE 1906. The host 1902 may initiate the transmission responsive to a request transmitted by the UE 1906. The request may be caused by human interaction with the UE 1906 or by operation of the client application executing on the UE 1906. The transmission may pass via the network node 1904, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1912, the network node 1904 transmits to the UE 1906 the user data that was carried in the transmission that the host 1902 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1914, the UE 1906 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1906 associated with the host application executed by the host 1902.In some examples, the UE 1906 executes a client application which provides user data to the host 1902. The user data may be provided in reaction or response to the data received from the host 1902. Accordingly, in step 1916, the UE 1906 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 1906. Regardless of the specific manner in which the user data was provided, the UE 1906 initiates, in step 1918, transmission of the user data towards the host 1902 via the network node 1904. In step 1920, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1904 receives user data from the UE 1906 and initiates transmission of the received user data towards the host 1902. In step 1922, the host 1902 receives the user data carried in the transmission initiated by the UE 1906.One or more of the various embodiments improve the performance of OTT services provided to the UE 1906 using the OTT connection 1950, in which the wireless connection 1970 forms the last segment. More precisely, the teachings of these embodiments may improve the data rate, latency, power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, improved content resolution, better responsiveness, extended battery lifetime.In an example scenario, factory status information may be collected and analyzed by the host 1902. As another example, the host 1902 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1902 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights) . As another example, the host 1902 may store surveillance video uploaded by a UE. As another example, the host 1902 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1902 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices) , or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1950 between the host 1902 and UE 1906, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1902 and / or UE 1906. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1950 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1950 may include message format, retransmission settings, preferred routing etc. ; the reconfiguring need not directly alter the operation of the network node 1904. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1902. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy' messages, using the OTT connection 1950 while monitoring propagation times, errors, etc.Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.The disclosure has been described above with reference to embodiments thereof. It should be understood that various modifications, alternations and additions can be made by those skilled in the art without departing from the spirits and scope of the disclosure. Therefore, the scope of the disclosure is not limited to the above particular embodiments but only defined by the claims as attached.The present disclosure further includes changes to 3GPP TS 23.222 as described below in Appendix A and changes to 3GPP TS 33.122 as described below in Appendix B.Appendix AAddition discussion:Figure 6.2.2-1 in TS 23.222 shows the architectural model for the CAPIF interconnection which allows API invokers of a CAPIF provider to utilize the service APIs from the 3rd party CAPIF provider.Figure 6.2.2-1: High level functional architecture for CAPIF interconnection with multiple CAPIF provider domains (see Fig. 2A)In above architecture, the API provider domain functions are registered in CCF within the same trusted domain. The CCFs are connected via CAPIF-6e, in order to share service APIs. The API provider domain functions don’t see the interconnected CCF in another domain. API invoker onboarded in a CAPIF provider can consume service APIs provided in another domain via CAPIF-2e.8.11.3 ProcedureFigure 8.11.3-1 illustrates the procedure for obtaining authorization to access the service API.Pre-condition:1. The API invoker is onboarded and has received an API invoker identity.Figure 8.11.3-1: Procedure for the API invoker obtaining authorization for service API access (see Fig. 20A)1. The API invoker sends an obtain service API authorization request to the CAPIF core function for obtaining permission to access the service API by including the API invoker identity information and any information required for authentication of the API invoker.2. The CAPIF core function validates the authentication of the API invoker (using authentication information) and if the service API authorization is performed locally checks whether the API invoker is permitted to access the requested service API.NOTE 1: The authentication process is specified in subclause 6.5.2.3 of 3GPP TS 33.122

[0012] .3. Based on the API invoker′ssubscription information the authorization information to access the service APIs is sent to the API invoker in the obtain service API authorization response.8.25.2.1 Interconnection API publish requestTable 8.25.2.1-1 describes the information flow interconnection API publish request from CAPIF core function to CAPIF core function.Table 8.25.2.1-1: Interconnection API publish request8.25.2.9 Interconnection update service API requestTable 8.25.2.9-1 describes the information flow interconnection update service API request from a CAPIF core function to another CAPIF core function.Table 8.25.2.9-1: Interconnection update service API request8.25.3.1 Service API publish for CAPIF interconnectionThis subclause describes the procedure for service API publish for CAPIF interoperation.Pre-condition:1. CCF-A and CCF-B connect to each other, and either belong to the single trust domain of the same CAPIF provider or trust domains of different CAPIF providers.2. CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.3. When CCF-A and CCF-B belong to trust domains of different CAPIF providers, the two CAPIF providers have business agreement for service API sharing.Figure 8.25.3.1-1: Interconnection API publish (see Fig. 7A)1. CCF-A gets the service APIs to be shared with CCF-B from the API publish function which is in the same CAPIF provider domain of CCF-A as described in subclause 8.3.3, or from another CCF as described in this procedure.2. Based on the shareable information for the service API or the service API category information, the CCF-A determines to publish the service API or the service API category information to the CCF-B. The CCF-A sends the interconnection API publish request to CCF-B with the details of at least one of service APIs or the category information of the service APIs, along with the identity information of CCF-A, shareable information and CAPIF provider domain information if allowed to share. The API topology hiding may be enabled. The CCF-A also determines whether the CCF-B can authorize service API access and sends the authorization delegation information to the CCF-B in the interconnection API publish request.3. CCF-B stores the service API information or service API category provided by the CCF-A.4. CCF-B provides an interconnection API publish response to the CCF-A indicating success or failure result and triggers notifications to subscribed API invokers as described in subclause 8.8.4.8.25.3. x1 API invoker obtaining authorization for service API access in CAPIF interconnectionPre-condition:1. The API invoker has discovered service APIs provided by an AEF via procedure defined in step 1 and 2 of clause 8.25.3.2.2. The API invoker and the CCF-B are in the same trusted domain.3. The AEF and the CCF-A are in the same trusted domain.4. The CCF-A and the CCF-B are connected to each other, and they have business agreement for service API authorization.5. The CCF-A is the authorization function for service API access on the AEF.Figure 8.25.3. x1-1: Procedure for the API invoker obtaining authorization for service API access (see Fig. 7B)1. The API invoker sends an obtain service API authorization request to the CCF-B for obtaining permission to access the service API by including the API invoker identity information and any information required for authentication of the API invoker.2. After successful authentication validation of the API invoker, if the CCF-B determines that the service API access authorization cannot be done by itself alone, then the CCF-B sends an obtain API authorization request to the CCF-A. In the request, the CCF-B can also send information about the API invoker so that the CCF-A can execute the authorization.NOTE: If the CCF-B was previously permitted by the CCF-A to authorize service API access, it executes the procedure defined in clause 8.11.3 without interaction with the CCF-A.3-4. Based on the API invoker′s subscription information, the authorization information to access the service APIs is sent to the API invoker (via the CCF-B) in the obtain service API authorization response.8.25.3. x2 Procedure for CAPIF revoking API invoker authorization in CAPIF interconnectionPre-conditions:1. The CCF-A is triggered to revoke API invoker authorization for service API access.Figure 8.25.3. x2-1: Procedure for revoking API invoker authorization in CAPIF interconnection (see Fig. 7C)1. If the CCF-B was delegated with service API authorization, the CCF-A sends revoke API invoker authorization request to the CCF-B with the details of the API invoker, the AEF and the service API.2. Upon receiving the information to revoke the API invoker′s authorization for service API invocation, the CCF-B invalidates the API invoker authorization corresponding to the service API.3. The CCF-B sends a revoke API invoker authorization response to the CCF-A.4. Instead of step 1 to 3, if the CCF-A performed service API authorization, the CCF-A sends a revoke API invoker authorization notify to the CCF-B.5. The CCF-A invalidates the API invoker authorization corresponding to the service API.6. The CCF-B sends a revoke API invoker authorization notify to the API invoker whose authorization to access the service API has been revoked.8.25.3. x3 Procedure for obtaining access control policy in CAPIF interconnectionPre-condition:1. The AEF is hosting the service API but the policy to perform access control is not available with AEF.2. The CCF-B has available access control policies corresponding to one or more service APIs.3. The AEF and the CCF-A are in the same trusted domain.(see Fig. 10A)1. The AEF sends an obtain access control policy request to the CCF-A for obtaining the policy to perform the access control on service API invocations by including the details of the hosted service API.2. After successful authentication validation of the AEF, if the CCF-A determines that the service API access control policy authorization cannot be done by itself alone, then the CCF-A sends an obtain access control policy request to the CCF-B. In the request, the CCF-A can also send the API invoker ID received from the AEF.NOTE 1: If the CCF-A has enough access control policy available, it executes the procedure defined in clause 8.12.3 without interaction with the CCF-B.3-4. The CCF-B determines appropriate access control policy for service APIs upon the request sent by the CCF-A. The access control policy information is sent to the AEF (via the CCF-A) in the obtain access control policy response.NOTE 2: To maintain synchronization between the AEF and the CCF for the policy cached at AEF, the AEF can subscribe to the policy update event at the CCF-A according to the procedure in clause 8.8.3 and receive notifications about any updated policy at the CCF-A according to the procedure in clause 8.8.4. Correspondingly, the CCF-A can subscribe to policy update event at the CCF-B if service API authorization is performed by the CCF-B.8.25.3. x4 Procedure for obtaining security information in CAPIF interconnectionPre-condition:1. The AEF has no security information available for authentication and / or authorization2. The CCF-B has security information available for authentication and / or authorization corresponding to one or more service APIs.3. The AEF and the CCF-A are in the same trusted domain.(see Fig. 10B)1. The AEF sends an obtain security information request to the CCF-A for obtaining the authentication and / or authorization information to be used in service API invocations by including the details of the API invoker and hosted service API.2. After successful authentication validation of AEF, if the CCF-A determines that it has no security information, then the CCF-A sends an obtain security information request to the CCF-B.NOTE 1: If the CCF-A has security information available, it executes the procedure defined in clause 8.14.3, clause 8.15.3 or clause 8.16.3 without interaction with the CCF-B.3-4. The security information required for service API invocations is sent to the AEF (via the CCF-A) in the obtain security information response.NOTE 2: The CCF-A can subscribe to API invoker onboarding event at the CCF-B according to the procedure in clause 8.8.3 and receive notifications about any onboarded API invoker and its security related onboarding information at the CCF-B according to the procedure in clause 8.8.4.Appendix B*******Start of 1st Change*******6.3.1.2 Security method negotiationThe API invoker and the CAPIF core function shall negotiate a security method that shall be used by the API invoker and the API exposing function for CAPIF-2e interface authentication and protection. After successful mutual authentication on CAPIF-1e interface, based on the API invoker′s subscribed service APIs, access scenarios (whether the API invoker access the AEF prior to service API invocation or upon the service API invocation) and AEF capabilities, the CAPIF core function shall choose the security method and sends the chosen security methods along with the information required for authentication of the API invoker at the AEF to the API invoker. The information may include the validity time of the CAPIF-2e credentials. This is depicted in figure 6.3.1-1.Pre-conditions:1. The API invoker is onboarded with the CAPIF core function.Figure 6.3.1-1: Selection of security method to be used in CAPIF-2 / 2e reference point (see Fig. 20B)1. Mutual authentication based on client and server certificates shall be established using TLS between the API invoker and the CAPIF core function. The client certificate that was provided to the API invoker as the result of successful onboarding is used based on the description in subclause 6.1 of the present document.2. The API invoker may send CAPIF-2 / 2e security capability information to the CAPIF core function in the Security Method Request message, indicating the list of security methods that the API invoker supports over CAPIF-2 / 2e reference point for each AEF. The API invoker may include address of CAPIF core function serving each AEF.3. The CAPIF core function shall select a security method to be used over CAPIF-2 / 2e reference point for each requested AEF, taking into account the information from the API invoker in step 2, access scenarios and AEF capabilities. The CAPIF core function can learn the AEF capabilities during the AEF publish procedure specified in clause 8.3.3, 8.6.3, 8.25.3.1 or 8.25.3.6 of TS 23.222 [3] . If the CAPIF core function does not have the AEF capability information, then the CAPIF core function shall learn the AEF capability information from the CAPIF core function serving the AEF.4. The CAPIF core function shall send Security Method Response message to the API invoker, indicating the selected security method for each AEF, any security information related to the security method. The API invoker shall use this method in the subsequent communication establishment with the API exposing function over CAPIF-2 / 2e reference point, as described in subclause 6.5 of the present document.*******Next Change*******6.5.2.1 Method 1 -Using TLS-PSKThe API invoker and the API exposing function shall follow the procedure in this sub-clause to establish dedicated secure session using TLS connection based on Pre-Shared Key (PSK) . CAPIF-1e authentication shall be used to bootstrap a Pre-Shared key for authenticating a TLS connection for CAPIF-2e. It is assumed that both the API invoker and the CAPIF core function are pre-provisioned with certificates. The TLS profile as specified in Annex E of TS 33.310 [2] shall be used.Figure 6.5.2.1-1 details the message flow between the API invoker, the CAPIF core function and the API exposing function, to establish secure CAPIF-2e interface using a pre-shared key for authentication.Figure 6.5.2.1-1: CAPIF-2e interface authentication and protection using TLS-PSK (see Fig. 20C)1. CAPIF-1e authentication and secure session is established as specified in subclause 6.3.1 of the present document. The CAPIF core function shall provide the validity timer value for the key AEFPSK.2. After successful establishment of TLS on CAPIF-1e, the API invoker and the CAPIF core function shall derive the key AEFPSK.The Key AEFPSK shall be bound to an AEF and shall be derived as specified in Annex A. The API invoker and the CAPIF core function starts the validity timer for the key AEFPSK.3. The API Invoker shall send Authentication Initiation Request to the AEF, including the CAPIF core function assigned API invoker ID.Steps 1 and 2 of this procedure may be skipped if the API invoker is already in possession of a valid key AEFPSK. In this case, the API invoker begins the procedure at step 3.NOTE: Void.4. The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker, ifthe AEF does not have a valid key. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PSK: AEFPSK) to the AEF over CAPIF-3 reference point. The CAPIF core function shall provide the remaining validity timer value for the key AEFPSK. If the CCF serving the API invoker and the CCF serving the AEF are different, then the procedure specified in clause 8.25.3. x4 of TS 23.222 shall be followed.5. After fetching the relevant security information (AEFPSK) for the authentication, the AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment. The AEF starts the validity timer based on the value received from the CAPIF core function in step 4.6. The API Invoker and the AEF shall perform mutual authentication using the key AEFPSK and establish TLS session over the CAPIF-2e.After successful establishment of TLS on CAPIF-2e reference point, the API exposing function shall authorize the API invoker′s service API invocation request based on authorization information obtained from CAPIF core function as specified in subclause 8.16 of TS 23.222 [3] .*******Next Change*******6.5.2.2 Method 2 -Using PKIThe API invoker and the API exposing function shall follow the procedure in this subclause to establish dedicated secure session over CAPIF-2e using TLS based on certificate based mutual authentication. It is assumed that both API invoker and API exposing function are pre-provisioned with certificates.Figure 6.5.2.2-1 details the message flow between the API invoker, the CAPIF core function and the API exposing function related to this security method.Figure 6.5.2.2-1: CAPIF-2e interface authentication and protection using certificate based mutual authentication (see Fig. 20D)1. The API invoker shall send Authentication Initiation Request to the AEF, including API invoker ID.2. The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PKI) to the AEF over CAPIF-3 reference point. CAPIF core function may return API invoker′s root CA certificate for the AEF to validate the API invoker′s certificate. If the CCF serving the API invoker and the CCF serving the AEF are different, then the procedure specified in clause 8.25.3. x4 of TS 23.222 shall be followed.3. After fetching the relevant security information for the authentication, AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment procedure.4. Then the API Invoker and the AEF shall perform mutual authentication using certificates and establish TLS session over the CAPIF-2e. Certificate based authentication shall follow the profiles given in 3GPP TS 33.310 [2] , clauses 6.1.3a and 6.1.4a. The structure of the PKI used for the certificate is out of scope of the present document.After successful establishment of TLS on CAPIF-2e reference point, the API exposing function shall authorize the API invoker′s service API invocation request based on authorization information obtained from CAPIF core function as specified in subclause 8.16 of TS 23.222 [3] .*******Next Change*******6.5.2.3 Method 3 -TLS with OAuth tokenThis method details establishment of secure channel over CAPIF-1e, CAPIF-2e reference points, and uses the OAuth 2.0 [4] token based mechanism to authorize and honour API invoker′s northbound API invocations to the API exposing function. Figure 6.5.2.3-1 details security information flows between the API invoker, the CAPIF core function and the API exposing function. It is assumed that the API invoker, the CAPIF core function and the AEF are pre-provisioned with the appropriate credentials and related information to establish a secure session.As per OAuth 2.0 [4] , the CAPIF core function shall perform the functionality of the authorization server and provide the token endpoint, the API invoker shall perform the function of the client functionality, while the API exposing function shall perform the resource server functions. The API invoker client (client endpoint) shall be registered as a confidential client type with an authorization grant type of ′client credentials′ . The authorization shall be previously arranged in the CAPIF core function. The access token shall follow the profile described in annex C.NOTE: How the authorization is pre-arranged (pre-configured) with the CAPIF core function is out of scope of the present documentFigure 6.5.2.3-1: CAPIF-2e interface authentication and protection using Access Tokens (see Fig. 20E)1. CAPIF-1e authentication and secure session establishment is performed as specified in subclause 6.3.1.2. After successful establishment of TLS session over CAPIF-1e, as described in subclause 6.3.1 of the present document, the API invoker shall send an Access Token Request message to the CAPIF core function as per the OAuth 2.0 [4] specification.3. The CAPIF core function shall verify the Access Token Request message per OAuth 2.0 [4] specification.4. If the CAPIF core function successfully verifies the Access Token Request message, the CAPIF core function shall generate an access token specific to the API invoker and return it in an Access Token Response message.Steps 1 to 4 of this procedure may be skipped if the API invoker is already in possession of a valid OAuth access token. In this case, the API invoker begins the procedure at step 5.NOTE 1: The API invoker may include the CAPIF core function assigned API invoker ID and the Onboard_Secret in the OAuth access token request message for the CAPIF core function to validate the access token request.NOTE 2: Void.If the CCF serving the API invoker and the CCF serving the AEF are different and the CCF serving the API invoker does not have the enough authorization information, then the CCF serving the API invoker can request an access token request to the CCF serving the AEF, or the CCF serving the API invoker can request authorization information from the CCF serving the AEF and then issue an access token by using the authorization information. In the request, the CCF serving the API invoker can also send information about the API invoker so that the CCF serving the AEF can execute the authorization.5. On CAPIF-2e, the API invoker authenticates to the AEF by establishing a TLS session with the API exposing function based on the authentication and authorization method (i.e. Server (AEF) side certificate authentication or certificate-based mutual authentication) as indicated by CAPIF core function. The following procedure shall be performed prior to establishment of TLS session.The API invoker shall send Authentication Initiation Request to the AEF, including API invoker ID.The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker. The CAPIF Core Function provides the security information related to the chosen security method (TLS with OAuth token) to the AEF over CAPIF-3 reference point. The CAPIF core function may return API invoker′s root CA certificate for the AEF to validate the API invoker′s certificate. If the CCF serving the API invoker and the CCF serving the AEF are different, then the procedure specified in clause 8.25.3.x4 of TS 23.222 shall be followed.After fetching the relevant security information for the authentication, the AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment procedure.6. With successful authentication to the AEF on CAPIF-2e, the API invoker shall initiate invocation of a 3GPP northbound API with the AEF. The access token received from the CAPIF core shall be sent along with the northbound API invocation request as per OAuth 2.0 [4] .7. The API exposing function shall validate the access token. The AEF verifies the integrity of the access token by verifying the CAPIF core function signature If validation of the access token is successful, the AEF shall verify the API invoker′sNorthbound API invocation request against the authorization claims in access token, ensuring that the API Invoker has access permission for the requested service API. If the token is signed by the CCF serving the API invoker and the AEF does not know the root certificate of the CCF serving the API invoker, the AEF shall learn the root certificate of the CCF serving the API invoker from the CCF serving the AEF.8. After successful verification of the access token and authorization claims of the API invoker, the requested northbound API shall be invoked and the appropriate response shall be returned to the API invoker.*******Next Change*******6.8 Security procedure for API invoker offboardingPre-conditions:1. The API invoker has been onboarded successfully.Figure 6.8-1: Security procedure for APl invoker offboarding (see Fig. 20F)0. TLS session is established successfully between the CAPIF core function and the API invoker.1. An event occurs within the API invoker to trigger the offboarding action.NOTE: The definition of events that trigger offboarding is outside the scope of the present document.2. The API invoker shall send Offboard API invoker request message to the CAPIF core function, including the CAPIF core function specific API invoker ID which was assigned by the CAPIF core function during the onboarding procedure.3. The CAPIF core function shall verify the API invoker ID received in step 2 and check that the corresponding profile exists for this API invoker. With successful verification of the API invoker ID and its profile, the CAPIF core function shall cancel the enrolment of the API invoker and delete the API invoker profile. This includes deletion of API invoker certificate, service API authentication and authorization information, and onboard secret (if applicable) . Depending on the operator policy, the CAPIF core function may retain the information of the offboarded API invoker.4. The CAPIF core function sends Offboard API invoker response message, indicating the successful offboarding of the API invoker.5. The API invoker shall delete the information, such as API invoker ID, Service API authentication  / authorization information, API invoker certificate, Onboard_Secret (if applicable) .6. The CAPIF core function shall tear down the TLS session with the API invoker.7. The CAPIF core function shall send Event notification message to the API exposing function to indicate that this API invoker is no longer valid. In the case of CAPIF interworking, the CAPIF core function serving the API invoker sends this notification message to the CAPIF core function serving the API exposing function. The CAPIF core function serving the API exposing function shall delete the security related information associated with this API invoker and send Event notification message to the API exposing function.8. The API exposing function shall delete the security related information associated with this API invoker depending on the method that was used previously to authenticate the API invoker, e.g. AEFPSK (TLS-PSK method as described in subclause 6.5.2.1) , root certificate to validate the API invoker certificate (PKI method as described in subclause 6.5.2.2) , access token (OAuth 2.0 method as described in subclause 6.5.2.3 of the present document, respectively) .9. The API exposing function shall tear down the TLS connection with the API invoker.10. The API exposing function shall return Event notification acknowledge message to indicate that the security related information associated with this API invoker is successfully deleted and thus the API invoker no longer an acknowledged user. In the case of CAPIF interworking, the acknowledge message is sent to the CAPIF core function serving the API invoker via the CAPIF core function serving the API exposing function.*******Next Change*******6. XSecurity procedures for CAPIF-6 / 6e reference pointsTo ensure security of the interface between CAPIF core functions, namely CAPIF-6 / 6e:- 3GPP TS 33.210

[0010] shall be applied to secure messages on the reference points specified otherwise; and- 3GPP TS 33.310 [2] may be applied regarding the use of certificates with the security mechanisms of 3GPP TS 33.210 [X] unless otherwise specified in the present document.SEG as specified in 3GPP TS 33.210

[0010] may be used in the trusted domain to terminate the IPsec tunnel.*******End of Changes*******

Claims

1.A method (300) in a first Network Function, NF, comprising:transmitting (310) , to a second NF, authorization delegation information enabling the second NF to authorize service Application Program Interface, API, access for an API invoker.2.The method (300) of claim 1, wherein the authorization delegation information contains information needed for the second NF to authorize the service API access.3.The method (300) of claim 1 or 2, wherein the authorization delegation information is transmitted in an interconnection API publish request or in response to a request from the second NF.4.The method (300) of any of claims 1-3, further comprising:transmitting, to the second NF, a request for revoking authorization of the API invoker.5.The method (300) of any of claims 1-4, wherein the first NF serves an API Exposing Function, AEF, and the second NF serves the API invoker.6.The method (300) of any of claims 1-5, wherein the first NF and the second NF are each a Common API Framework ‘CAPIF’ Core Function, CCF.7.A method (400) in a second Network Function, NF, comprising:receiving (410) , from a first NF, authorization delegation information enabling the second NF to authorize service Application Program Interface, API, access for an API invoker.8.The method (400) of claim 7, further comprising:receiving, from the API invoker, an authorization request for accessing a service API; andtransmitting, to the API invoker, an authorization response containing authorization information for the API invoker to access the service API.9.The method (400) of claim 7 or 8, further comprising:receiving, from the first NF, a request for revoking authorization of the API invoker; andrevoking the authorization of the API invoker in response to the request.10.A method (500) in a first Network Function, NF, comprising:receiving (510) , from a second NF, an authorization request for authorizing access to a service Application Program Interface, API, for an API invoker; andtransmitting (520) , to the second NF, an authorization response containing authorization information for the API invoker to access the service API.11.The method (500) of claim 10, wherein the authorization request contains information on the API invoker.12.The method (500) of claim 10 or 11, further comprising:transmitting, to the second NF, a notification indicating revocation of authorization of the API invoker.13.The method (500) of any of claims 10-12, wherein the first NF serves an API Exposing Function, AEF, and the second NF serves the API invoker.14.The method (500) of any of claims 10-13, wherein the first NF and the second NF are each a Common API Framework ‘CAPIF’ Core Function, CCF.15.A method (600) in a second Network Function, NF, comprising:transmitting (610) , to a first NF, an authorization request for authorizing access to a service Application Program Interface, API, for an API invoker; andreceiving (620) , from the first NF, an authorization response containing authorization information for the API invoker to access the service API.16.The method (600) of claim 15, further comprising:transmitting, to the API invoker, the authorization information.17.The method (600) of claim 15 or 16, further comprising:receiving, from the first NF, a notification indicating revocation of authorization of the API invoker; andtransmitting, to the API invoker, a notification indicating revocation of authorization of the API invoker.18.A method (800) in a first Network Function, NF, comprising:receiving (810) , from a second NF, information on an access control policy or security information for authentication and / or authorization associated with an Application Program Interface, API, invoker.19.The method (800) of claim 18, further comprising:transmitting, to the second NF, a request for the access control policy or the security information.20.The method (800) of claim 19, further comprising:receiving, from an API Exposing Function, AEF, a request for the access control policy or the security information; andtransmitting, to the AEF, the information on the access control policy or the security information.21.The method (800) of any of claims 18-20, wherein the information on the access control policy or the security information is received as a response to a request towards the second NF.22.The method (800) of any of claims 18-21, wherein the security information comprises one or more of a key, a root certificate of the API invoker, a root certificate of the second NF, or a certificate of the second NF.23.The method (800) of any of claims 18-22, wherein the first NF serves an API Exposing Function, AEF, and the second NF serves the API invoker.24.The method (800) of any of claims 18-24, wherein the first NF and the second NF are each a Common API Framework ‘CAPIF’ Core Function, CCF.25.A method (900) in a second Network Function, NF, comprising:transmitting (910) , to a first NF, information on an access control policy or security information for authentication and / or authorization associated with an Application Program Interface, API, invoker.26.The method (900) of claim 25, further comprising:receiving, from the first NF, a request for the access control policy or the security information.27.A method (1100) in a first Network Function, NF, comprising:receiving (1110) , from a second NF, a request for capability information of an Application Program Interface ‘API’ Exposing Function, AEF; andtransmitting (1120) , to the second NF, the capability information.28.The method (1100) of claim 27, wherein the capability information comprises a security method supported by the AEF.29.The method (1100) of claim 27 or 28, wherein the first NF serves the AEF and the second NF serves an API invoker.30.The method (1100) of any of claims 27-29, wherein the first NF and the second NF are each a Common API Framework ‘CAPIF’ Core Function, CCF.31.A method (1200) in a second Network Function, NF, comprising:transmitting (1210) , to a first NF, a request for capability information of an Application Program Interface ‘API’ Exposing Function, AEF; andreceiving (1220) , from the first NF, the capability information.32.A method (1300) in a first Network Function, NF, comprising:receiving (1310) , from a second NF, a notification that an Application Program Interface, API, invoker is no longer valid; andtransmitting (1320) , to an API Exposing Function, AEF, a notification message indicating that the API invoker is no longer valid.33.The method (1300) of claim 32, further comprising:receiving, from the AEF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted; andforwarding the notification acknowledgement message to the second NF.34.The method (1300) of claim 32 or 33, wherein the first NF serves the AEF and the second NF serves the API invoker.35.The method (1300) of any of claims 32-34, wherein the first NF and the second NF are each a Common API Framework ‘CAPIF’ Core Function, CCF.36.A method (1400) in a second Network Function, NF, comprising:transmitting (1410) , to a first NF, a notification that an Application Program Interface, API, invoker is no longer valid; andreceiving (1420) , from the first NF, a notification acknowledgement message indicating that security related information associated with the API invoker has been deleted.37.A network node (1500) , comprising a communication interface (1510) , a processor (1520) , and a memory (1530) , the memory (1530) comprising instructions executable by the processor (1520) whereby the network node (1500) is operative to, when implementing a first Network Function, NF, perform the method according to any of claims 1-6, 10-14, 18-24, 27-30, or 32-35, or when implementing a second NF, perform the method according to any of claims 7-9, 15-17, 25-26, 31, or 36.38.A computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing a first Network Function, NF, perform the method according to any of claims 1-6, 10-14, 18-24, 27-30, or 32-35, or when implementing a second NF, perform the method according to any of claims 7-9, 15-17, 25-26, 31, or 36.

Images