Patent Description:
Authorization is needed in various communication networks to ensure that only users and network entities that have a right to access certain services can do that. Proper authorization needs to be ensured for example in core networks of cellular communication systems, such as in <NUM> core networks developed by the 3rd Generation Partnership Project, 3GPP. The 3GPP still develops <NUM> core networks and there is a need to provide improved methods, apparatuses and computer programs for improving authorization in <NUM> core networks. Such improvements may be useful in other communication networks as well. 3GPP TS <NUM> V16. <NUM> relates to security architecture and procedures for <NUM> systems.

The invention is defined by claims <NUM> and <NUM>. Some example embodiments are defined in the dependent claims.

According to a first aspect of the present invention, there is provided an apparatus, comprising an intermediary network function and comprising means for receiving, by the intermediary network function, a subscription request from a network function consumer requesting data of a network function producer via a messaging framework, wherein the subscription request comprises a client credential assertion of the network function consumer and an access token, means for authorizing and authenticating, by the intermediary network function, the network function consumer upon successful validation of the access token and the client credential assertion, means for transmitting, by the intermediary network function, an access token request to an authorization server (<NUM>) to get another access token, wherein said another access token is to be used to validate the network function consumer to access services of the network function producer, and the access token request comprises the client credential assertion of the network function consumer requesting data of the network function producer; and means for receiving, by the intermediary network function, an access token response from the authorization server, wherein the access token response comprises the another access token, wherein the access token response comprises identifiers of two subscribing network entities, said two subscribing network entities further comprising the network function consumer and the messaging framework.

According to a second aspect of the invention there is provided an apparatus comprising an authorization server comprising means for receiving, by the authorization server, an access token request from an intermediary network function, wherein the access token request comprises a client credential assertion of a network function consumer requesting data of a network function producer via a messaging framework, means for generating, by the authorization server, an access token to be used to validate the network function consumer to data of the network function producer upon checking the client credential assertion of the network function consumer; and means for transmitting, by the authorization server, an access token response to the intermediary network function, wherein the access token response comprises the access token and identifiers of two subscribing network entities, said two subscribing network entities further comprising the network function consumer and the messaging framework.

Authorization may be improved by providing a procedure for a Data Collection Coordination Function, DCCF, so that the DCCF may validate authentication and authorization aspects between a Network Function consumer, NFc, and a Network Function producer, NFp, before passing any data back to the NFc, possibly via a Messaging Framework, MF.

<FIG> illustrates an exemplary data management framework in accordance with at least some example embodiments of the present invention. The exemplary data management framework of <FIG> comprises data consumer <NUM>, DCCF <NUM>, MF <NUM>, data source <NUM>, and authorization server <NUM>. Data consumer <NUM> may be referred to as a NFc. For instance, data consumer <NUM> may be a Network Data Analytics Function, NWDAF, as defined in a 3rd Generation Partnership Project, 3GPP, standard specification TS <NUM>, and the NWDAF may calculate analytics based on data collected from different data sources, such as an Access and Mobility management Function AMF, Session Management Function SMF, Policy Control Function, PCF, Unified Data Management, UDM, Application Function, AF, and Operations Administration and Maintenance, OAM. The NWDAF may offer analytics identified by a 3GPP defined analytics identifier to consumers using the service-based architecture defined for the <NUM> core network for example.

DCCF <NUM> may find the right data producer, i.e., data source <NUM>, identify the serving network function per User Equipment, UE, control data replication and consolidate subscriptions. DCCF Adaptor, DA, may coordinate requests and/or data delivery. MF <NUM> may forward data from data source <NUM> to data consumer <NUM>, possibly via Producer Adaptor, 3PA, and Consumer Adaptor, 3CA, and may duplicate data to be sent to different entities such as different data consumers <NUM>, or a data repository and data consumer <NUM>. Data source <NUM> may be referred to as a NFp. Authorization server <NUM> may be a Network Repository Function, NRF. Some embodiments of the present invention may be applied in an OAuth2. <NUM> framework for authorization of Network Function, NF, service access as defined in a 3GPP standard specification TS <NUM>.

DCCF <NUM> may introduce a new path for NFc1 <NUM> to access the data from data sources <NUM>, i.e., NFps. Due to the introduction of DCCF <NUM> between NFc1 <NUM> and NFp <NUM>, security mechanisms need to be enhanced. For instance, if NFc1 <NUM> is not allowed to access data from NFp <NUM>, it should be ensured that DCCF <NUM> does not provide NFp <NUM> related data to NFc1 <NUM>.

Another issue is that if NFc1 <NUM> is allowed to access data from NFp <NUM>, NFc1 <NUM> may ask for data that can be produced by NFp <NUM> and in such a case DCCF <NUM> may request said data from NFp <NUM>. So DCCF <NUM> may coordinate data distribution, possibly via MF <NUM>. However, another NFc (not shown in <FIG>) may not be allowed to access data provided by NFp <NUM>. So if said another NFc asks for the same data as NFc1 <NUM>, DCCF <NUM> and/or MF <NUM> may already have said data but then DCCF <NUM> should be able to ensure that it will not provide data that has been already obtained from NFp <NUM> to said another NF.

Moreover, Client Credentials Assertion, CCA, as defined for example in a 3GPP standard specification TS <NUM>, of NFc1 <NUM> may be required for indirect communication so that NFp <NUM> can authenticate NFc1 <NUM>. So in case of DCCF <NUM> based communication, when data source <NUM> changes (e.g., UE mobility scenarios), DCCF <NUM> should somehow get a new CCA of NFc1 <NUM> to authenticate NFc1 <NUM> with the new data source.

Embodiments of the present invention address the above mentioned issues. More specifically, embodiments of the present invention enable a procedure where DCCF <NUM> can validate authentication and authorization aspects between NFc1 <NUM> and NFp <NUM> before passing any data back to NFc1 <NUM>, possibly via MF <NUM>.

<FIG> illustrates a first signalling example in accordance with at least some example embodiments. On the vertical axes are disposed, from the left to the right, NFc1 <NUM>, DCCF <NUM>, MF <NUM>, NFp <NUM> and authorization server <NUM>, i.e., the NRF. Time advances from the top towards the bottom. <FIG> illustrates an example, wherein NFc1 <NUM> sends a subscription request to DCCF <NUM>, to request access to services/data of NFp <NUM>, but DCCF <NUM> and/or MF <NUM> does not have the requested data of NFp <NUM>.

At phase <NUM>, if NFc1 <NUM> wants to communicate with DCCF <NUM> to retrieve data of NFp <NUM>, such as an AMF or SMF, NFc1 <NUM> may retrieve an access token from authorization server <NUM> to get authorized at DCCF <NUM> later on. So NFc1 <NUM> may transmit an access token request "Nnrf_AccessToken_Get Request, Target=DCCF" and receive an access token response comprising an access token to be used to validate, authorize and authenticate NFc1 <NUM> at DCCF <NUM> via "Nnrf_AccessToken_Get Response (expires_in, access_token)".

At phase <NUM>, NFc1 <NUM> may initiate a subscription request to DCCF <NUM> to retrieve data of NFp <NUM>, possibly via a data management framework comprising DCCF <NUM> and MF <NUM>. NFc1 <NUM> may include the access token received at phase <NUM> in a subscription request, e.g., in an authorization header of the subscription request. NFc1 <NUM> may also include a CCA of NFc1 <NUM> irrespective of direct or indirect communication. In some embodiments, a target NF type in the CCA will include DCCF <NUM>, authorization server <NUM>, and NFp <NUM>. NFc1 <NUM> If NFc1 <NUM> is not certain of the possible NFtype of the NFp <NUM> then the NFc1 <NUM> can add the all possible NFtype of the NFp <NUM> which can be applicable. For example, the subscription request may be "Ndccf_EventExposure_Subscribe (Nxxx_Service, Parameters), CCA {Nftype=DCCF, AMF, NRF}, Token" That is to say, NFc1 <NUM> requesting data via DCCF <NUM>, comprising a CCA of NFc1 <NUM> and the access token to be used to validate NFc1 <NUM> at DCCF <NUM>.

If NFc1 <NUM>, such as a NWDAF or any other NF, and DCCF <NUM> are in direct communication, a CCA of NFc1 <NUM> would not be required for DCCF <NUM> and the target NF type = DCCF may be skipped. However, communication from NFc1 <NUM> to other NFs via DCCF <NUM> is indirect communication and hence, in some embodiments, the CCA of NFc1 <NUM> may need to be included to the subscription request at phase <NUM> irrespective of whether there is a Service Communication Proxy, SCP, between NFc1 <NUM> and DCCF <NUM>. That is to say, the CCA of NFc1 <NUM> may need to be included to the subscription request at phase <NUM> irrespective of whether NFc1 <NUM> and DCCF <NUM> are directly connected, said direct connection referring to a case where there are no SCP between NFc1 <NUM> and DCCF <NUM>. So in case of a direct connection the subscription request may go from NFc1 <NUM> to DCCF <NUM> without traversing an SCP.

At phase <NUM>, DCCF <NUM> may validate the access token and the CCA received from NFc1 <NUM> and validate NFc1 <NUM>. That is to say, DCCF <NUM> may authorize and authenticate NFc1 <NUM> upon successful validation of the access token and the CCA of NFc1 <NUM>.

At phase <NUM>, DCCF <NUM> may check whether data is already available for distribution to NFc1 <NUM> via MF <NUM>. If the data is not available, then the DCCF 120may discover the data source, such as NFp <NUM>, based on the existing mechanism (via NRF, UDM etc) defined in TS <NUM>. To contact the data source, i.e., NFp <NUM>, DCCF <NUM> needs to get a another token (said another access token) from the NRF. DCCF <NUM> may transmit an access token request to authorization server <NUM>, wherein the requested said another access token is to be used to validate NFc1 <NUM> to access services of NFp <NUM> and the access token request comprises the CCA of NFc1 <NUM> requesting access to services of NFp <NUM>. For instance, if DCCF <NUM> checks and finds that data of NFp <NUM> is not already available for distribution to NFc1 <NUM> via MF <NUM>, DCCF <NUM> may discover NFp <NUM>, i.e., the data source, via an NRF or UDM. But to contact NFp <NUM> properly, DCCF <NUM> may need to get said another access token from authorization server <NUM>. For this, DCCF <NUM> may form the access token request so that the access token comprises an identity of NFc1 <NUM> and/or an identity of MF <NUM>. Alternatively, or in addition, DCCF <NUM> may form the access token request so that the access token request comprises at least the CCA of NFc1 <NUM>, and possibly the CCA of DCCF <NUM> as well. The access token request may be for example "Nnrf_AccessToken_Get Request (. Target=AMF, SubscribingNF=NWDAF Id, and MessageFramework Id. ) CCA-NFc1.

At phase <NUM>, authorization server <NUM> may generate a digitally signed access token for an access token response, possibly with information about the subscribing NFs (SubscribingNFInfo) included as a new claim to the access token response. Said information about the subscribing NFs may comprise identifiers of NFc1 <NUM> and MF <NUM>. That is to say, authorization server <NUM> may generate, at phase <NUM>, said another access token to be used to validate NFc1 <NUM> to access service of NFp 140NFc1 <NUM>. Thus, authorization server <NUM> may authorize DCCF <NUM> to subscribe to access to services, i.e., data, of NFp <NUM> on behalf of NFc1 <NUM> and MF 130NFc1 <NUM>. Indirectly, authorization server <NUM> may also authorize NFp <NUM> to send notifications to NFc1 <NUM>, DCCF <NUM> and MF <NUM>. That is to say, said another access token may authorize NFc1 <NUM>, DCCF <NUM> and MF <NUM> to receive notifications from NFp <NUM>.

At phase <NUM>, authorization server <NUM> may transmit an access token response to DCCF <NUM>, the access token response comprising said another access token. The access token response may be for example "Nnrf_AccessToken_Get Response (expires_in, access_token{ Token-<NUM>})". The access token response may also comprise identifiers of two subscribing network entities, said two subscribing network entities comprising NFc1 <NUM> and MF <NUM>, so that a single token may be used to avoid unnecessary consumption of resources. For instance, the access token response may comprise AccessTokenClaims according to the following table.

Alternatively, authorization server <NUM> may provide two access tokens, one for NFc1 <NUM> to access NFp <NUM> and another one for DCCF <NUM> and/or MF <NUM> to access NFp <NUM>.

At phase <NUM>, DCCF <NUM> may transmit a subscription request to NFp <NUM>, to validate NFc1 <NUM> to access services of NFp <NUM>, the subscription request to NFp <NUM> comprising the CCA of NFc1 <NUM> and said another access token. Said subscription request to NFp <NUM> may be for example "Namf_EventExposure_Subscribe, CCA-NWDAF, CCA-DCCF, Token-<NUM>". That is to say, DCCF <NUM> may provide two CCA headers to NFp <NUM>, the first which is received from NFc1 <NUM> and the second one is self-generated by DCCF <NUM>. At phase <NUM>, NFp <NUM> must check said another access token/claim(s) before providing a service to DCCF <NUM> or sending notifications to MF <NUM>. NFp <NUM> may then validate NFc1 <NUM> to access services of NFp <NUM> via DCCF <NUM>. DCCF <NUM> may also include the callback Uniform Resource Identifier, URI, of MF <NUM> to the subscription request to NFp <NUM> so that NFp <NUM> can send a notification/data to MF <NUM> directly.

At phase <NUM>, NFp <NUM> may transmit a subscription response to DCCF <NUM>. If the validation was successful, the subscription response may comprise a callback URI pointing to NFp <NUM> only which can be used for further communication to NFp <NUM> from DCCF <NUM>. Therefore, authorization server <NUM> may authorize MF <NUM> to collect data on behalf of DCCF <NUM>.

At phase <NUM>, DCCF <NUM> and MF <NUM> may create a subscription if the subscription response indicates successful subscription/validation. Otherwise DCCF <NUM> may reject the subscription request. At phase <NUM>, DCCF <NUM> may transmit a subscription response to NFc1 <NUM>. At phase <NUM>, NFp <NUM> may transmit at least one notification to MF <NUM> and, at phase <NUM>, said at least one notification may be forwarded to NFc1 <NUM> via MF <NUM>. Once the association is established then MF <NUM> may start sending stored data or newly received data from NFp <NUM> towards NFc1 <NUM>.

<FIG> illustrates a second signalling example in accordance with at least some example embodiments. Similarly as in <FIG>, on the vertical axes are disposed, from the left to the right, NFc1 <NUM>, DCCF <NUM>, MF <NUM>, NFp <NUM> and authorization server <NUM>, such as a NRF. In addition, another NFc2 <NUM> is shown in <FIG>. Time advances from the top towards the bottom. <FIG> illustrates an example, wherein said another NFc2 <NUM> may transmit a subscription request to DCCF <NUM> for the same data source, i.e., NFp <NUM>, and data is already available in DCCF <NUM> and/or MF <NUM>. That is to say, <FIG> demonstrates data access authorization when DCCF <NUM> has already subscribed to NFp <NUM>.

NFc1 <NUM> may, before phase <NUM>, start collecting data from NFp <NUM>. That is to say, the second signalling example of <FIG> may take place after the first signalling example shown in <FIG>. Phases <NUM> - <NUM> may correspond to phases <NUM> - <NUM> in <FIG>, respectively. When another NFc2 <NUM> wants to collect data from NFp <NUM>, said another NFc2 <NUM> may, at phase <NUM>, transmit a subscription request "Subscribe, CCA {Nftype=DCCF, AMF}, Token" to DCCF <NUM>, to request access to services, i.e., data, of NFp <NUM>. At phase <NUM>, DCCF <NUM> may authorize and authenticate another NFc2 <NUM> upon validating an access token received in the subscription request of another NFc2 <NUM>. In addition, DCCF <NUM> may determine that DCCF <NUM> and/or MF <NUM> does not have the requested data of NFp <NUM>. DCCF <NUM> may therefore retrieve an access token, wherein the access token is to be used to access services of NFp <NUM> by another NFc2 <NUM>, from authorization server by transmitting, at phase <NUM>, an access token request "Nnrf_ AccessToken_Get Request (. Target=AMF, SubscribingNF=NFc-<NUM>, InstanceId/SetId, and MessageFramework Id. ) CCA-NFc-<NUM>, CCA-DCCF" and receiving, at phase <NUM>, an access token response "Nnrf_AccessToken_Get Response (expires_in, access_token{ Token-<NUM>})" comprising the access token to be used to access services of NFp <NUM> by another NFc2 <NUM>.

To validate, authenticate and authorize another NFc2 <NUM> at NFp <NUM>, possibly via the CCA of NFc2 <NUM>, DCCF <NUM> may use, at phase <NUM>, the callback URI provided by NFp <NUM> to send a notification request or subscription update request message to NFp <NUM> for example with access tokens and CCA headers "Namf_EventExposure_SubscribeModify or Notification_ReAuthCallback, CCA-NWDAF, CCA-DCCF, Token-<NUM>". That is to say, DCCF <NUM> may, at phase <NUM>, transmit a subscription update request or Notification_ReAuthCallback request to NFp 140to validate another NFc2 <NUM> to access services of NFp <NUM>.

At phase <NUM>, NFp <NUM> may validate the CCA of another NFc2 <NUM> and the access token received at phase <NUM>, and authorize another NFc2 <NUM> to access services of NFp <NUM>. If authorization is completed successfully, NFp <NUM> may, at phase <NUM>, transmit a subscription update response indicating success to DCCF <NUM>. Upon receiving the subscription update response, DCCF <NUM> may at phase <NUM> create a subscription in MF <NUM> so that data requested by another NFc2 <NUM> and collected from NFp <NUM> may be sent towards another NFc2 <NUM>. At phase <NUM>, DCCF <NUM> may transmit a subscription response to another NFc2 <NUM>. When new data is received from NFp <NUM> at phase <NUM>, MF <NUM> may send notifications at phases <NUM> and <NUM> based on a list of authorized NFcs to another NFc2 <NUM> and NFc1 <NUM>, respectively.

In some embodiments, a data source may change, for instance in UE mobility scenarios. As an example, a change of a data source, i.e., NFp <NUM>, may occur if UE session is moving from AMF (Set1) or NFp <NUM> to AMF2 (Set2) or another NFp. Therefore, DCCF <NUM> may need to make sure said another NFp authenticates and authorizes NFc1 <NUM> so that MF <NUM> continues to send data to NFc1 <NUM>. DCCF <NUM> may determine a change of the data source from NFp <NUM> to said another NFp for example by subscribing to the UDM to be notified when the NFp serving specific UEs changes.

Upon determining the change, DCCF <NUM> may send at least one notification about the change to NFc1 <NUM>, e.g., with a cause DATA_SOURCE_CHANGE and a new data source detail. After receiving the at least one notification, NFc1 <NUM> may send a subscription update request to DCCF <NUM>, for example without data. The subscription update request may comprise at least a new CCA of NFc1 <NUM>, wherein the new CCA may further comprise a type of said another NFp. For instance, the subscription update request may be "Target NFtype= NFp (example AMF, SMF) and NFtype=DCCF (for indirect communication)". NFc1 <NUM> may also add the access token to the subscription update request for DCCF <NUM>. Alternatively, or in addition, a new callback URI may also be added for the subscription update request.

DCCF <NUM> may authenticate NFc1 <NUM> based on the CCA of NFc1 <NUM> (for indirect communication) and authorize NFc1 <NUM> based on the access token. DCCF <NUM> may also contact said another NFp so that said another NFp can authenticate and authorize NFc1 <NUM> following the steps described in <FIG>. That is to say, DCCF <NUM> may transmit a subscription request to said another NFp to validate NFc1 <NUM> to access service of said another NFp, the subscription request comprising the CCA of NFc1 <NUM>, CCA of DCCF <NUM> and a new token DCCF <NUM> should have received from authorization server/NRF <NUM> to be checked by the said another NFp.

Even though DCCF <NUM> is used as an example, embodiments of the present invention may also be applied for any intermediary NF in general. That is to say, DCCF <NUM> is an intermediary NF and may be replaced with any other intermediary NF, such as an UDM or NWDAF. Similarly, NFc1 <NUM> and NFc2 <NUM> may be any NF consumers, such as a NWDAF or Network Exposure Function, NEF. For instance, a NEF may access an AMF and/or SMF based notification via an UDM. In some embodiments, NFc1 <NUM> may be a NEF while DCCF <NUM> and/or MF <NUM> may be an UDM. Alternatively, NWDAF1 may ask another NWDAF2 to collect data for NWDAF1 and in such a case NWDAFs may also be configured to act as the intermediate function and handle the authorization for NWDAF1 (as NFc1 <NUM>) to access services from NFp <NUM>.

<FIG> illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device <NUM>, which may comprise, for example, DCCF <NUM> or authorization server <NUM>, or a device controlling functioning thereof. Comprised in device <NUM> is processor <NUM>, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processor and a multi-core processor comprises more than one processor. Processor <NUM> may comprise, in general, a control device. Processor <NUM> may comprise more than one processor. Processor <NUM> may be a control device. Processor <NUM> may comprise at least one Application-Specific Integrated Circuit, ASIC. Processor <NUM> may comprise at least one Field-Programmable Gate Array, FPGA. Processor <NUM> may comprise an Intel Xeon processor for example. Processor <NUM> may be means for performing method steps in device <NUM>, such as determining, causing transmitting and causing receiving. Processor <NUM> may be configured, at least in part by computer instructions, to perform actions.

A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

When computer instructions configured to cause processor <NUM> to perform certain actions are stored in memory <NUM>, and device <NUM> overall is configured to run under the direction of processor <NUM> using computer instructions from memory <NUM>, processor <NUM> and/or its at least one processor may be considered to be configured to perform said certain actions.

Device <NUM> may comprise a transmitter <NUM>. Device <NUM> may comprise a receiver <NUM>. Transmitter <NUM> and receiver <NUM> may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP. Transmitter <NUM> may comprise more than one transmitter. Receiver <NUM> may comprise more than one receiver. Transmitter <NUM> and/or receiver <NUM> may be configured to operate in accordance with a suitable communication standard.

Device <NUM> may comprise User Interface, UI, <NUM>. UI <NUM> may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device <NUM> to vibrate, a speaker and a microphone. A user may be able to operate device <NUM> via UI <NUM>, for example to configure device <NUM> and/or functions it runs.

Device <NUM> may comprise further devices not illustrated in <FIG>. In some example embodiments, device <NUM> lacks at least one device described above. For example, device <NUM> may not have UI <NUM>.

Processor <NUM>, memory <NUM>, transmitter <NUM>, receiver <NUM> and/or UI <NUM> may be interconnected by electrical leads internal to device <NUM> in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device <NUM>, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the example embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

<FIG> is a flow graph of a first method in accordance with at least some example embodiments. The phases of the illustrated first method may be performed by DCCF <NUM>, or by a control device configured to control the functioning thereof, possibly when installed therein.

The first method may comprise, at step <NUM>, receiving, by an intermediary network function, a subscription request from a network function consumer requesting data of a network function producer, wherein the subscription request comprises a client credential assertion of the network function consumer and an access token. The first method may also comprise, at step <NUM>, authorizing and authenticating, by the intermediary network function, the network function consumer upon successful validation of the access token and the client credential assertion validation. Finally, the first method may comprise, at step <NUM>, transmitting, by the intermediary network function, an access token request to an authorization server to get another access token, wherein said another access token is to be used to validate the network function consumer to access services of the network function producer, and the access token request comprises the client credential assertion of the network function consumer requesting data of the network function producer.

<FIG> is a flow graph of a second method in accordance with at least some example embodiments. The phases of the illustrated second method may be performed by authorization server <NUM>, such as an NRF, or by a control device configured to control the functioning thereof, possibly when installed therein.

The second method may comprise, at step <NUM>, receiving, by an authorization server, an access token request from an intermediary network function, wherein the access token request comprises a client credential assertion of a network function consumer requesting data of a network function producer via a messaging framework. The second method may also comprise, at step <NUM>, generating, by the authorization server, an access token to be used to validate the network function consumer to data of the network function producer upon checking the client credential assertion of the network function consumer. Finally, the second method may comprise, at step <NUM>, transmitting, by the authorization server, an access token response to the intermediary network function, wherein the access token response comprises the access token.

It is to be understood that the example embodiments disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular example embodiments only and is not intended to be limiting.

Reference throughout this specification to one example embodiment or an example embodiment means that a particular feature, structure, or characteristic described in connection with the example embodiment is included in at least one example embodiment. Thus, appearances of the phrases "in one example embodiment" or "in an example embodiment" in various places throughout this specification are not necessarily all referring to the same example embodiment.

In addition, various example embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such example embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations.

In an example embodiment, an apparatus, such as, for example, DCCF <NUM> or authorization server <NUM>, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.

In an example embodiment, a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof. In an exemplary example embodiment, a computer program product, embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.

In an example embodiment, an apparatus, such as, for example, DCCF <NUM> or authorization server <NUM>, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of example embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

At least some example embodiments find industrial application at least in <NUM> core networks, and possibly in other core networks in the future as well.

Claim 1:
An apparatus comprising an intermediary network function (<NUM>) comprising:
- means for receiving, by the intermediary network function, a subscription request from a network function consumer (<NUM>) requesting data of a network function producer (<NUM>) via a messaging framework (<NUM>), wherein the subscription request comprises a client credential assertion of the network function consumer and an access token;
- means for authorizing and authenticating, by the intermediary network function, the network function consumer upon successful validation of the access token and the client credential assertion;
- means for transmitting, by the intermediary network function, an access token request to an authorization server (<NUM>) to get another access token, wherein said another access token is to be used to validate the network function consumer to access services of the network function producer, and the access token request comprises the client credential assertion of the network function consumer requesting data of the network function producer; and
- means for receiving, by the intermediary network function, an access token response from the authorization server, wherein the access token response comprises the another access token, wherein the access token response comprises identifiers of two subscribing network entities, said two subscribing network entities further comprising the network function consumer and the messaging framework.