Demonstrating proof of possession to SCP in indirect communication scenarios to allow reusing access tokens only by the legitimate owner

Abstract

An apparatus (220) is configured to receive a service request (200- B1) comprising a client credentials assertion token from a network function consumer (210); determine (200-B2) whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token; determine to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and determine to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

Description

Demonstrating Proof of Possession To SCP In Indirect Communication Scenarios To Allow Reusing Access Tokens Only By The Legitimate OwnerTECHNICAL FIELD

[0001] The examples and non-limiting example embodiments relate generally to communications and, more particularly, to a demonstrating proof of possession to a service communication proxy in indirect communication scenarios to allow reusing access tokens only by the legitimate owner.BACKGROUND

[0002] It is known for a communication device to gain access to a communication network via an access network node.SUMMARY

[0003] In accordance with an aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; determine whether the client credentials assertion token comprises demonstrating proof of possession information; determine whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; determine to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and determine to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

[0004] In accordance with an aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: transmit, to a service communication proxy, a service request for aservice, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information; receive, from the service communication proxy, a response to service request for the service; and receive, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

[0005] In accordance with an aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and transmit, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

[0006] In accordance with an aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and transmit, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The foregoing aspects and other features are explained in the following description, taken in connection with the accompanying drawings.

[0008] FIG. 1 is a block diagram of one possible and non-limiting system in which the example embodiments may be practiced.

[0009] FIG. 2 is a signaling diagram, based on the examples described herein.

[0010] FIG. 3 is an example apparatus configured to implement the examples described herein.

[0011] FIG. 4 shows a representation of an example of non-volatile memory media used to store instructions that implement the examples described herein.

[0012] FIG. 5 is an example method, based on the examples described herein.

[0013] FIG. 6 is an example method, based on the examples described herein.

[0014] FIG. 7 is an example method, based on the examples described herein.

[0015] FIG. 8 is an example method, based on the examples described herein.

[0016] FIG. 9 shows Model A directed to authorization aspects in direct deployment.

[0017] FIG. 10 shows Model B directed to authorization aspects in direct deployment.

[0018] FIG. 11 shows Model C directed to authorization aspects in indirect deployment, based on the examples described herein.

[0019] FIG. 12 shows Model D directed to authorization aspects in indirect deployment, based on the examples described herein.DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0020] Turning to FIG. 1, this figure shows a block diagram of one possible and nonlimiting example in which the examples may be practiced. A user equipment (UE) 110, radio access network (RAN) node 170, and network element(s) 190 are illustrated. In the example of FIG. 1, the user equipment (UE) 110 is in wireless communication with a wireless network 100. A UE is a wireless device that can access the wireless network 100. The UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127. Each of the one or more transceivers 130 includes a receiver, Rx, 132 and a transmitter, Tx, 133. The one or more buses 127 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The UE 110 includes a module 140, comprising one of or both parts 140-1 and / or 140- 2, which may be implemented in a number of ways. The module 140 may be implemented in hardware as module 140-1, such as being implemented as part of the one or more processors120. The module 140-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 140 may be implemented as module 140-2, which is implemented as computer program code 123 and is executed by the one or more processors 120. For instance, the one or more memories 125 and the computer program code 123 may be configured to, with the one or more processors 120, cause the user equipment 110 to perform one or more of the operations as described herein. The UE 110 communicates with RAN node 170 via a wireless link 111.

[0021] The RAN node 170 in this example is a base station that provides access for wireless devices such as the UE 110 to the wireless network 100. The RAN node 170 may be, for example, a base station for 5G, also called New Radio (NR). In 5G, the RAN node 170 may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface (such as connection 131) to a 5G core network (5GC) (such as, for example, the network element(s) 190). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface (such as connection 131) to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) 196 and distributed unit(s) (DUs) (gNB-DUs), of which DU 195 is shown. Note that the DU 195 may include or be coupled to and control a radio unit (RU). The gNB-CU 196 is a logical node hosting radio resource control (RRC) protocols, at least one service data adaptation protocol (SDAP) and at least one packet data convergence protocol (PDCP) of the gNB or RRC and PDCP protocols of the en-gNB that control the operation of one or more gNB-DUs. The gNB-CU 196 terminates the Fl interface connected with the gNB-DU 195. The Fl interface is illustrated as reference 198, although reference 198 also illustrates a link between remote elements of the RAN node 170 and centralized elements of the RAN node 170, such as between the gNB-CU 196 and the gNB-DU 195. The gNB-DU 195 is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU 196. One gNB-CU 196 supports one or multiple cells. One cell may be supported with one gNB-DU 195, or one cell may be supported / shared with multiple DUs under RAN sharing. The gNB-DU 195 terminates the Fl interface 198 connected with the gNB-CU 196. Note that the DU 195 is considered to include the transceiver 160, e.g., as part of a RU, but some examples of this may have the transceiver 160 as part of a separate RU, e.g., under control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolvedNodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

[0022] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / W I / F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include the processor(s) 152, one or more memories 155, and network interfaces 161. Note that the DU 195 may also contain its own memory / memories and processor(s), and / or other hardware, but these are not shown.

[0023] The RAN node 170 includes a module 150, comprising one of or both parts 150-1 and / or 150-2, which may be implemented in a number of ways. The module 150 may be implemented in hardware as module 150-1, such as being implemented as part of the one or more processors 152. The module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 150 may be implemented as module 150-2, which is implemented as computer program code 153 and is executed by the one or more processors 152. For instance, the one or more memories 155 and the computer program code 153 are configured to, with the one or more processors 152, cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the module 150 may be distributed, such as being distributed between the DU 195 and the CU 196, or be implemented solely in the DU 195.

[0024] The one or more network interfaces 161 communicate over a network such as via the links 176 and 131. Two or more gNBs 170 may communicate using, e.g., link 176. The link 176 may be wired or wireless or both and may implement, for example, an Xn interface for 5G, an X2 interface for LTE, or other suitable interface for other standards.

[0025] The one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for gNB implementation for 5G, with the other elements of the RAN node 170 possibly being physically in a different location fromthe RRH / DU 195, and the one or more buses 157 could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU 196) of the RAN node 170 to the RRH / DU 195. Reference 198 also indicates those suitable network link(s).

[0026] A RAN node / gNB can comprise one or more transmission reception points (TRPs) to which the methods described herein may be applied. FIG. 1 shows that the RAN node 170 comprises TRP 51 and TRP 52, in addition to the TRP represented by transceiver 160. Similar to transceiver 160, TRP 51 and TRP 52 may each include a transmitter and a receiver. The RAN node 170 may host or comprise other TRPs not shown in FIG. 1.

[0027] A relay node in NR is called an integrated access and backhaul (IAB) node. A mobile termination part of the IAB node facilitates the backhaul (parent link) connection. In other words, the mobile termination part comprises the functionality which carries UE functionalities. The distributed unit part of the IAB node facilitates the so called access link (child link) connections (i.e. for access link UEs, and backhaul for other IAB nodes, in the case of multi-hop IAB). In other words, the distributed unit part is responsible for certain base station functionalities. The IAB scenario may follow the so called split architecture, where the central unit hosts the higher layer protocols to the UE and terminates the control plane and user plane interfaces to the 5G core network.

[0028] It is noted that the description herein indicates that “cells” perform functions, but it should be clear that equipment which forms the cell may perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a 360 degree area so that the single base station’s coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three 120 degree cells per carrier and two carriers, then the base station has a total of 6 cells.

[0029] The wireless network 100 may include a network element or elements 190 that may include core network functionality, and which provides connectivity via a link or links 181 with a further network, such as a telephone network and / or a data communications network (e.g., the Internet). Such core network functionality for 5G may include location management functions (LMF(s)) and / or access and mobility management function(s) (AMF(S)) and / oruser plane functions (UPF(s)) and / or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (mobility management entity) / SGW (serving gateway) functionality. Such core network functionality may include SON (self- organizing / optimizing network) functionality. These are merely example functions that may be supported by the network element(s) 190, and note that both 5G and LTE functions might be supported. The RAN node 170 is coupled via a link 131 to the network element 190. The link 131 may be implemented as, e.g., an NG interface for 5G, or an SI interface for LTE, or other suitable interface for other standards. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N / W I / F(s)) 180, interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. Computer program code 173 may include SON and / or MRO functionality 172.

[0030] The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, or a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171, and also such virtualized entities create technical effects.

[0031] The computer readable memories 125, 155, and 171 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, non-transitory memory, transitory memory, fixed memory and removable memory. The computer readable memories 125, 155, and 171 may be means for performing storage functions. The processors 120, 152, and 175 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as nonlimiting examples. The processors 120, 152, and 175 may be means for performing functions, such as controlling the UE 110, RAN node 170, network element(s) 190, and other functionsas described herein.

[0032] In general, the various example embodiments of the user equipment 110 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback devices having wireless communication capabilities, internet appliances including those permitting wireless internet access and browsing, tablets with wireless communication capabilities, head mounted displays such as those that implement virtual / augmented / mixed reality, as well as portable units or terminals that incorporate combinations of such functions. The UE 110 can also be a vehicle such as a car, or a UE mounted in a vehicle, a UAV such as e.g. a drone, or a UE mounted in a UAV. The user equipment 110 may be terminal device, such as mobile phone, mobile device, sensor device etc., the terminal device being a device used by the user or not used by the user.

[0033] UE 110, RAN node 170, and / or network element(s) 190, (and associated memories, computer program code and modules) may be configured to implement (e.g. in part) the methods described herein. Thus, computer program code 123, module 140-1, module 140-2, and other elements / features shown in FIG. 1 of UE 110 may implement user equipment related aspects of the examples described herein. Similarly, computer program code 153, module 150-1, module 150-2, and other elements / features shown in FIG. 1 of RAN node 170 may implement gNB / TRP related aspects of the examples described herein. Computer program code 173 and other elements / features shown in FIG. 1 of network element(s) 190 may be configured to implement network element related aspects of the examples described herein.

[0034] Having thus introduced a suitable but non-limiting technical context for the practice of the example embodiments, the example embodiments are now described with greater specificity.

[0035] Demonstrating Proof of Possession (DPoP) as specified in IETF RFC 9449 is a technique to cryptographically bind access tokens to a particular client when they are issued. It is requiring the application using the token to prove possession of the same private key that was used to obtain the token. DPoP proof is a signature over some data of the HTTP requestto which it is attached with a timestamp, a unique identifier, an optional server-provided nonce, and a hash of the associated access token when an access token is present within the request. The proposed detection mechanism of this RFC is not available in 3GPP standards to the best of inventor’s knowledge. The herein described solution extends the proposal in the IETF RFC 9449 (and the concepts in RFC 8705) mentioned DPoP for usage in indirect communication scenarios.

[0036] IETF RFC 8705 addresses the binding of the OAuth 2.0 access token with the TLS certificate issue. For the purpose of sender-constrained access tokens, the (OAuth2.0) client is identified towards the (OAuth2.0) resource server by the fingerprint of its TLS EE certificate public key. During processing of an access token request, the (OAuth2.0) authorization server obtains the (OAuth2.0) client's TLS EE certificate public key (from the TLS stack) and associates its fingerprint with the respective access tokens. The (OAuth2.0) resource server in the same way obtains the TLS EE certificate public key from the TLS stack and compares its fingerprint with the fingerprint associated with the access token.

[0037] IETF RFC 8705 only addresses direct communication (i.e., both for client - authorization server and client - resource server links) since it is relying on mTLS, and not addressing all challenges with indirect communication via generic HTTP / 2 proxies, HTTP / 2 load balancers or L7 Web application and API protection (WAAP) services etc. or, especially, with the indirect communication cases (i.e., Model C and D) in 3GPP 5GC SBA via SCP.

[0038] IETF RFC 8705 assumes that the same TLS profile with the same TLS EE client certificates were / are used between (OAuth2.0) client and (OAuth2.0) authorization server, and between (OAuth2.0) client and (OAuth2.0) resource server. Also, CCA tokens are used in OAuth2.0 for 5GC SBA where the X.509 public key certificates associated to CCA tokens signing (with JWS) may be signed by different subCA than used for signing the TLS EE certificates.

[0039] Mitigation against an access token theft attack in direct and indirect communications in a service based architecture solves the problem of binding the access token with the NFc public key for direct communication only. However, this does not solve the problem at the SCP. The herein described methods address the indirect communication scenario, i.e., when SCP is involved.

[0040] The problem: In indirect communication, an access token can be stolen that NFccached after it was received from SCP. The access token can also be stolen from the NFp (i.e. when it was used but is valid for more than one time usage at this NFp, e.g. leaked from NFp) or from the NRF (e.g. by an insider) that issued a token to SCP.

[0041] How to avoid in indirect scenarios that a stolen / acci dentally shared access token can be reused by (non-legitimate) other network functions NFc’ to consume NF services for which another NF got the access token? How to provide proof for NFp on this scenario, i.e., since not directly connected to NFc via mTLS?

[0042] In current 3GPP specifications, specifically in the profiled OAuth 2.0 framework for SBA, there is no binding between the access token used for authorization, and the EE TLS certificate used for authentication. Also, there is no binding between the CCA token (selfsigned by NFc; used for NFc authentication) and access tokens (signed by NRF). Thus, if an access token granted to NFA to consume services of a producer NFc, is leaked to another network function NFB with a valid certificate, that NFB could consume the services of NFc, even if it is not authorized to do so.

[0043] The approach of 3GPP to this problem, at the moment, is to rely on ‘good’ implementations that do not allow the leakage of access tokens and prevent what can be denominated as the ‘token reply’ problem. I.e., the assumption made by 3GPP is that SCPs are trusted, and SCPs have mTLS in between.

[0044] Hence, theft and misuse of the access token is possible, i.e., when SCP share the token to the NFc for caching, so that NFc can reuse the token in the further communication. If this access token is leaked to other NFc’ and the NFc’ reuses the token, then there is no option for anyone to validate whether the token is allowed to be used by NFc’ .

[0045] Further there can be scenarios wherein the access token can be leaked and used for another NF producer than the one that the access token was originally generated for.

[0046] RFC 8705 as currently specified does not solve the problem in 5G SBA for several reasons (1-5): 1. Indirect communication introduced in 3GPP Rel 16 for 5GC SBA. The communication between NFc and NFp is done via one or more SCPs (service communication proxies). So, TLS mutual authentication is performed between NFs and between SCPs (and between NFs and NRF with Model C), not between NFs. Furthermore, NF consumers (and NF producers) may use different TLS profiles toward NRF(s) and SCPc (and SCPp) (forexample interSCP routing) nodes where NF consumers as TLS clients may also support X.509 certificate rotation. 2. 3GPP specified CCA (Client Credentials Assertion) token solution to enable the client authentication in indirect communication-based deployments (with Model C and D). RFC8705 does not cover this feature. 3. 5G SBA uses HTTP / 2, and according to RFC 9113 ‘TLS 1.3 post-handshake authentication’ is to be avoided. 4. JWT access tokens in 3GPP 5GC SBA are self-contained and thus NF producer (as “Protected Resource” in RFC 8705 terms) does not integrate with NRF as “Authorization Server” to determine the state of the access token nor to obtain via introspection or similar any metainformation about the access tokens (granted by this NRF). 5. In 3GPP 5GC SBA, NRF as “Authorization Server” does not support / utilize Dynamic Client Registration Protocol (defined in RFC 7591) to obtain client metadata for NF consumers nor support dynamically registering OAuth 2.0 client metadata with “Authorization Servers”.

[0047] RFC 9449 as currently specified does not solve the problem in 5G SBA for several reasons (1-6): 1. (see the reasons given for RFC 8705). 2. The OAuth2.0 authorization framework for 3GPP 5GC SBA use Client Credential grant in access token requests while in RFC 9449 an authorization grant type (e.g., an authorization code or refresh token) is used. 3. The RFC 9449 defines that a primary use case of DPoP as per RFC 9449 is for public clients (e.g., single-page applications and applications on a user's device) that do not use client authentication. 4. 3GPP specified CCA (Client Credentials Assertion) token solution to enable the client authentication in indirect communication-based deployments (with Model C and D). The DPoP mechanism in RFC9449 is not meant for client authentication as stated in clause 3 of RFC 9449. 5. RFC 9449 introduces a new DPoP HTTP header (i.e., containing the DPoP Proof JWT type) and DPoP -Nonce HTTP header which are not used in 3GPP 5GC SBA. 6. In 3GPP 5GC SBA, NRF as “Authorization Server” does not support / utilize Dynamic Client Registration Protocol (defined in RFC 7591) to obtain or registering client metadata for NF consumers (i.e., support dynamically registering OAuth 2.0 client metadata with “Authorization Servers").

[0048] Also, 3GPP TS 33.501 and TS 29.510 define optional usage of specific JWT access tokens for accessing Nnrf services (e.g., with Nnrf service API scopes for Nnrf_NFManagement and Nnrf_NFDiscovery services for NFs; including SCP). The same solutions can be reused for Nnrf services authorization purposes as well, however, here the (OAuth2.0) resource server is NRF (i.e., this can be different from the NRF granting JWTaccess tokens for the target NF producers).

[0049] CCA tokens (i.e., delivered in “3gpp-Sbi-Client-Credentials” HTTP custom header) as such are only standardized and used in 3GPP 5GC SBA for NF consumer authentication, not for (service) authorization, so it does not solve the JWT access token theft problem either.

[0050] In indirect communication, NFc asks for a service via SCP and can optionally add its CCA for authentication. The SCP authenticates NFc during mTLS by the presented NFc certificate and asks for the access token on behalf of NFc.

[0051] The idea described herein is to use a proof of possession concept (which may be referred to as DPoP) by which NRF as authorization server can create a JWT access token that is surely bound to the legitimate NFc and cannot be used by any other NFc’.

[0052] The examples described herein in particular relate to the following enhancements: enhanced DPoP(s) in the CCA and SCP validating the same to avoid access token theft, and Enhanced DPoP(s) to cover all certificate / pub keys.

[0053] It is proposed to include one or multiple DPoP(s) in NFc CCA (by NFc) and in the JWT access token generated for NFc (by NRF). Demonstrating proof of possession (DPoP) can be done by mTLS public key or hashes of mTLS public key or certificates.

[0054] If different TLS profiles with different TLS EE client certificates are used for NRF and SCPc, multiple DPoPs are needed.

[0055] The flow is as follows:

[0056] NFc generates DPoP with public key certificate of NFc and a thumbprint, i.e., including a public key. NFc uses for this the same public key certificate as for the mTLS setup.

[0057] NFc is adding one or multiple DPoP(s) in the self-generated CCA token. In case of multiple TLS EE certificates provisioned for NFc, NFc may include multiple DPoPs (or a set of DPoP).

[0058] SCP forwards NFc details (DPoP, public key cert) in the access token request

[0059] DPoP is received by NRF from SCP (Model D)

[0060] NRF validates DPoP(s) and generates JWT access token including the received DPoP(s) and provides it to SCP

[0061] JWT access tokens are sender-constrained by adding the DPoP(s).

[0062] SCP is requesting the service at NFp (on behalf of NFc) with the received access token (including DPoP(s))

[0063] NFp validates the DPoP information in the JWT access token

[0064] NFp provides the service for NFc via SCP; SCP also provides back to NFc the access token including DPoP to NFc if subsequent requests are allowed with the same access token

[0065] NFc may cache and reuse the access token including DPoPs for a subsequent request to NFp via SCP

[0066] SCP Validating the DPoP and ensuring access token is not stolen.

[0067] Later on, if the same access token granted for NFc (and not granted for NFc’) is used by a non-legitimate NFc’ and the non-legitimate NFc’ sends the access token and the CCA token for the NFc’ with a service request to SCP, the SCP proceeds as follows (1-2): 1. SCP validates the access token is really belongs to NFc’ or not by matching the CCA’s DPoP with access Token DPoP. If it is matched, SCP allows the request. Otherwise, SCP reject the request. 2. Alternative, SCP informs on the discard of the token and requests a new token.

[0068] Another case is if NFc’ also adds a stolen CCA token for the NFc. In this case, then the SCP must reject the request as the DPoP in the CCA token does not match with the TLS EE client certificate for this NFc’ .

[0069] NFc TLS EE client certificate public key and any additional DPoP(s) is bound with the JWT access token.

[0070] NFp validates the JWT access token (i.e., NFc TLS EE client certificate pub key etc.) against the CCA token also including DPoP(s) information, and only then it provides the requested service. Both CCA tokens and access tokens are sender-constrained

[0071] By validating the JWT access token, it is ensured that it has not been stolen or abused, thus it is meant for the real NF consumer that sent the request.

[0072] CCA token supports the following parameters, such that the CCA token includes (1- 4): 1. the NF instance ID of the NF Service Consumer (subject); 2. A timestamp (iat) and an expiration time (exp); 3. The NF type of the expected audience (audience), i.e., the type "NRF" and / or the NF Type of the NF Service Producer. Both “NRF” and the NF Type of the target NF Service Producer are included in the expected audience when Model D is used; and 4. one or multiple “DPoP (proof(s))” (e.g., mTLS public key or hashes of mTLS public key or certificates) can be included depending on if different TLS profiles with different TLS EE client certificates are used for NRF and SCPc.

[0073] The NF Service Consumer digitally signs the generated CCA token based on its private key as described in RFC 7515

[0045] , The signed CCA token shall include one of the following fields (1-2): 1. the X.509 URL (x5u) to refer to a resource for the X.509 public key certificate or certificate chain used for signing the client credentials assertion token, or 2. the X.509 Certificate Chain (x5c) include the X.509 public key certificate or certificate chain used for signing the client credentials assertion token.

[0074] FIG. 2 is a diagram showing a signaling exchange between the NFc-1 210, SCP1 220, NFp 230, and an authorization server 240 (for example an NRF).

[0075] A (200-A). NFs (consumer and producer) profiles registration.

[0076] NFc 210 during the profile registration (200-A) at the NRF 240 (or at the 0AM) also registers its public key (or a hash or fingerprint of the public key) or multiple public keys if separate TLS profiles with different TLS EE client certificates are used for NRF and SCPc. Since the profile registration should occur via mTLS (not mandatory), NRF 240 may have the public key or public keys from the corresponding TLS certificate(s). In case a different private and public key pair is used by AS-NRF(s) for JWT access token signing that the one present in the mTLS, that can also be updated at the NRF as a part of NF profile registration.

[0077] In case this information is not available at the NRF 240, it can request (out-of-band) from the 0AM the corresponding information using the NFc NF Instance ID information.

[0078] It is assumed that in the future all the NFs (both the consumer and the producers) register at the NRF 240.

[0079] Al (200-Al): mutual authentication (mTLS) between all hops is assumed.

[0080] B (200-B1, 200-B2, 200-B3). Access token request to the NRF 240 by the NFc 210 and the SCP 220.

[0081] NFc 210, when sending the initial Nnf service request at 200-B1 also includes its CCA token along with the DPoP(s). In case of both, Model C and Model D, the initial Nnf service request contains the CCA token (with specific Audience claim depending on the Model C or D that is applied).

[0082] Even though the CCA token is short lived, but still in the case where it may be assumed that even the CCA token is stolen, the following procedure is valid:

[0083] SCP 220 when receiving the access token request from the NFc 210 (in Model C) or receiving the initial Nnf service request and then correspondingly generating the access token request 200-B3 (only in Model D), firstly at 200-B2 the SCP 220 verifies whether the CCA token is indeed signed and belongs to the NFc 210 sending the message 200-B1.

[0084] In Model C, the NFc has a direct connection to the NRF and thus access token requests are not routed via SCP. In Model C, the initial service request contains both the CCA token and the access token. In case that the SCPc uses Model C and the NFc did not include the access token then the SCPc does not request new access tokens from NRF but returns an error response to the NFc.

[0085] Since SCPc has direct mTLS with the NFc, it can verify if the public key present in the TLS EE client certificate for the HTTPS connection is same as the one present (or can be found if multiple exists) in the CCA token. In case different keys are used for TLS and CCA token signing, SCP 220 verifies if the NF Instance ID and NF Type information present in the TLS certificate information is the same as the one present in CCA token. Only after successful verification, SCP 220 at 200-B3 either forward the access token request to NRF (Model C) or generates the access token request (Model D) and sends it to NRF 240, including in some examples the information of the public key of the NFc 210 in the access token request 200-B3. In general, all DPoP information is only in the CCA token that is passed to the NRF with the access token request.

[0086] C (200-C1, 200-C2). Access token generation and proof of possession verification by NRF

[0087] When NRF 240 receives the access token request 200-B3 along with the CCA token of the NFc 210, after performing the stated verification in the Clause 13.3.8 in TS 33.501 and verifying that the public key present in CCA token is indeed belonging to the NFc 210 whose NF instance ID is present in the access token request 200-B3 (using the NF profile registration information), at 200-C1 appends the DPoP information, i.e. public key(s) present in the CCA token in the access token claims. Alternatively, at 200-C1 NRF 240 may also add a signed HASH of public key or NFc certificate fingerprint or other “DPoP (proof)” information of the NFc 210 (e.g., one or multiple hashes of public key or certificate fingerprints etc. depending on the usage of shared / dedicated TLS profiles for HTTPS connections with NRF vs. SCPc) in the JWT access token.

[0088] If NFc 210 is using different certificates for CCA token and mTLS, then CCA token may contain the additional public key / certificate for mTLS (or hash), the NRF 240 shall also include the same in the ATI.

[0089] In the case the NF Service consumer would not register at the NRF, even then the CCA token generated by the NFc including DPoP serves as a proof of procession of private key, and the corresponding public key in DPoP is added (at 200-C1) by NRF 240 in the access token.

[0090] At 200-C2, the authorization server 240 transmits to the SCP 220 the generated access token including the generated DPoP.

[0091] D (200-D1, 200-D2, 200-D3, 200-D4). Service request sending to the NF Service Producer 230.

[0092] NF Service Producer 230 when receiving this request 200-D1 along with the CCA token of NFc 210 (including DPoP), can verify at 200-D2 whether the public key present in the access token is the same as the one in the CCA token. In case of successful verification, service is provided.

[0093] After this (D.3), namely the service being provided at 200-D3, and transmission of the service response from NFp 230 to SCP 220 at 200-D3, at 200-D4 SCP 220 provides the token to NFc 210 for caching so that NFc 210 can reuse the cached token (in D.4).

[0094] E (200-E1, 200-E2, 200-E3). Once NFc 210 provides the token again in the furthercommunication (at 200-E1), the SCP 220 needs to (at 200-E2 and 200-E3) authenticate and authorize the NFc 210 and validate it access token is not stolen. For this, SCP 220 shall check (i-iii):

[0095] i. If access token contains DPoP(s). If not, the SCP shall discard the access token.

[0096] ii. If access token contains DPoP(s), the SCP shall validate if information in DPoP(s), e.g., hash of public key / certificate is matching (at 200-E2) with the hash of public key / certificate present in the NFc certificate provided via mTLS or CCA token.

[0097] iii. If they match, the SCP reuse the token provided by NFc. If it does not match (at 200-E1), then SCP 220 determines that token is not used by NFc but NFc’ and discards the request.

[0098] FIG. 2 shows the call flow and signaling diagram based partially on Model D, with the SCP 220 transmitting the access token request 200-B3 to authorization server 240, and authorization server transmitting the access token response 200-C2 to SCP 220. FIG. 2 is also adapted to Model C, with access token request 270 with CCA 272 having DPoP 274, and access token response 280 with AT 282 having DPoP 284. AT request 270 is transmitted from NFc 210 to authorization server 240, and AT response 280 is transmitted from authorization server 240 to NFc 210. In Model C, NFc 210 may request access tokens (e.g. at 270) prior to sending the initial service request at 200-B1 to the SCP 220 (such that messages 270 and 280 are transmitted prior to message 200-B1), and such call flow order may be the preferred embodiment.

[0099] As shown in FIG. 2, service request 200-B1 includes CCA 251 with DPoP 252. Access token request 200-B3 includes CCA 254 with DPoP 255. Access token response 200- C2 includes AT 256 with DPoP 257. Service request 200-D1 includes AT 258 with DPoP 259 and CCA 260 with DPoP 261. Service response 200-D4 includes AT 262 with DPoP 263. Subsequent service request 200-E1 includes CCA 264 with DPoP 265 and AT 266 with DPoP 267. CCA 251, CCA 254, CCA 260, CCA 264, and CCA 272 may be the same or different, or have some of the same information, as determined by NFc 210, SCP 220, NFp 230 and / or authorization server 240. AT 256, AT 258, AT 262, AT 266, and AT 282 may be the same or different, or have some of the same information, as determined by NFc 210, SCP 220, NFp 230 and / or authorization server 240. DPoP 252, DPoP 255, DPoP 257, DPoP 259, DPoP 261, DPoP 265, DPoP 267, DPoP 274, and DPoP 284 may be the same or different, orhave some of the same information, as determined by NFc 210, SCP 220, NFp 230 and / or authorization server 240.

[0100] In Model D, the SCP 220 requests access tokens while in Model C, NFc 210 requests access tokens directly from the authorization server 240 and not via SCP 220. In Model D, the access token with demonstrating proof of possession information is the granted access token by NRF 240 as authorization server. The access token with demonstrating proof of possession information granted by NRF 240 contains the DPoPs from the CCA token from NFc 210 that are received via the SCP 220.

[0101] In Model C (using a direct mTLS connection with NFc 210), NRF as auth server 240 needs prior to granting the access token with demonstrating proof of possession information validate that (one of) the DPoP(s) in the client credentials assertion token comprising the one or more DPoPs match with the actual TLS EE client cert of the NFc 210.

[0102] Thus in Model D only the CCA token with DPoPs is sent in the initial Nnf request to the SCPc). In Model C, the NFc requests access tokens directly from the NRF as an authorization server and the NFc uses a different CCA token for this compared to the service request via SCPc. Thus in Model C, the set of DPoPs in the CCA token to the NRF contains also the DPoP used for NFc to SCPc in case the one or more TLS profiles used by the NFc for the NRF are different from the one or more TLS profiles used by the NFc for the SCPc, and / or in case the one or more TLS EE certificates used by the NFc for the NRF are different from the one or more TLS EE certificates used by the NFc for the SCPc.

[0103] In summary, the client credentials assertion (CCA) is a token signed by the NF service consumer 210. The CCA token enables the NF service consumer 210 to authenticate towards a receiving end point (for example NRF 240 or NF service producer 230) by including the signed CCA token in a service request. The CCA token includes the NF Service Consumer’s NF Instance ID and demonstrating proof of possession (e.g., mTLS public key) (DPoP) that can be checked against the NF Service Consumer’s certificate by the NF Service Producer 230 (in Model B) or by SCP 220 (in Models C and D). The CCA includes one or multiple DPoP (proof(s)) that allow the NRF to link NFc TLS EE client certificate information used for mTLS between NFc and SCP (or between NFc and NRF) with the JWT access token generated for the NF Service Consumer identified by the NF instance ID.

[0104] The verification of the CCA shall be performed by the receiving node, i.e., NRF,SCPc, or NF Service Producer such that the receiving node verifies that the NF instance ID of the NFc and at least one of the DPoP(s) in the CCA matches the NF instance ID in the public key certificate used for signing the CCA (i.e., NF instance ID in URI-ID). If the receiving node is SCPc, the SCPc validates that the NFc TLS EE client certificate information (e.g., thumbprint or public key) match one of the DPoP(s) in the CCA and the NF instance ID of the NFc in CCA match the NF instance ID in NFc TLS EE client certificate (i.e., NF instance ID in URI-ID).

[0105] Advantages and technical effects of the herein described solution include Mitigating the reuse of access tokens by non-legitimate NF consumers, given the threat of service producers providing a service to a nonlegitimate NF. The herein described solution provides that access tokens are used only by legitimate NFs.

[0106] One of the key differences is that with the solution described herein for DPoP or set of DPoPs, the client and resource server can have indirect communication over "HTTPS proxy" that is the SCP in this case. This "HTTPS proxy" can also be HTTPS LB / L7 Web application and API protection (WAAP) services (which is not basically possible with RFC8705 / RFC9449 based setups which always implement direct mTLS between the client and resource server. Also, the client has the same TLS profile used for the authorization server and resource server meaning the same TLS EE client certificate is used for both mTLS connections.

[0107] Further implementation details:

[0108] The “public key” here can refer to the public key present in the TLS EE / X.509 certificate, or the cryptographic (SHA256) hash of the public key certificate (e.g., the digest / fingerprint / thumbprint of the X.509 certificate); refer to the table below for the different options covered by the examples described herein (however, other options may appear later but need to be protected by this); for example, in the table below, there’re summarized a set of different implementation alternatives for creating sender-constrained JWT access tokens and CCA tokens where “DPoP” (proof) denotes to the sender-constrained identity information about (and the demonstration of holding the associated private key by) the NF consumers included in CCA tokens (signed by NF consumers) and / or JWT access tokens (granted and signed by NRF as the OAuth2.0 authorization server).

[0109] Here, “DPoP” (proof) does not specifically refer to RFC 9449 (concepts), however,some similarities may appear. Here, it is proposed to include “DPoP” (proof) in CCA tokens and JWT access tokens in a separate custom claim. Neither “x5t#S256” (X.509 Certificate SHA-256 Thumbprint header parameter) defined in IETF RFC 7515 nor “cnf’ confirmation method claim with “x5t#S256” member defined in RFC 8705 or “cnf’ confirmation method claim with “jkt” JWK Thumbprint confirmation method member defined in RFC 9449 can alone be used for this purpose.

[0110] Note: “x5t” (X.509 Certificate SHA-1 Thumbprint header parameter) defined in IETF RFC 7515 has already been deprecated due to the well-known security issues with SHA- 1 such as SHA1 collision.[OHl] Note: NFc self-signed CCA tokens with “x5u” / “x5c” header parameters using (sub)CA signed X.509 certificates for CCA token signing keys (JWS) may be prone to be used for (forged) identity theft of a victim NFc when fraudulent / malicious NFc is able to replace the victim’s “x5u” / “x5c” header parameters with the forged ones (e.g., self-signed X.509 certificates) and after that create new digital signature for the used CCA token unless NRF / NFp (or SCPc) also validates the trust path for and the requester NFc identity (in Subject claim) in the CCA token signing X.509 certificates.

[0112] Multiple-purpose certificate / single-purpose certificate explained:

[0113] Note: Multi-purpose X.509 PKI certificates can be used for NFs (and in X.509 PKI certificate validation) as identified with keyUsage and extendedKeyUsage in X.509 PKI certificates, for example (i-iii): i) TLS EE client / server certificates (for mTLS) with “KU: digital Signature” and “EKU: id-kp-client-auth” / “EKU: id-kp-server-auth” (allowed NF Types in X.509 certificates: all NFs incl. NRF, SEPP, SCP) and / or ii) QAuth2,0 with JWT access tokens (i.e., here for JWS signing keys with AS-NRFs) with “KU: digital Signature” (or “KU: nonrepudiation”) and (opt.) “EKU: id-kp-oauthAccessTokenSigning” (allowed NF Types in X.509 certificates: NRF); and / or iii) QAuth2,0 with CCA tokens (i.e., here for CCA token signing keys with NF consumers) with “KU: digital Signature” (or “KU: nonrepudiation”) and (opt.) “EKU: id-kp-jwt” (allowed NF Types in X.509 certificates: all NF consumers).

[0114] Multi-purpose X.509 PKI certificates are required for AS-NRFs (i.e., with mTLS and JWT access tokens), however, multi-purpose X.509 PKI certificates are not required for NF producers (i.e., unless those are also NF consumers thus requiring support for CCAtokens), SCP (with Model C / D), SEPP or NRF nodes without OAuth2.0 AS role (i.e., if those are not AS-NRFs with OAuth2.0 Authorization Server role).

[0115] Single or multi-purpose X.509 PKI certificates with “anyExtendedPurpose” for EKU are currently not recommended to be used with JWS token signing for JWT access tokens or CCA tokens.

[0116] In case that the single-purpose or multi-purpose X.509 PKI certificates are distributed manually (via 0AM) to NF producers then the KU+EKU validation during JWS signature validation for JWT access tokens can be skipped as per local policy.

[0117] In summary: NFc can use the same cert for CCA, mTLS to SCP, mTLS to NRF (in case of model C), in this case it is a multipurpose certificate, otherwise single-purpose certificate.

[0118] In the table different scenarios are sketched as implementation details to illustrate the idea described herein.

[0119] The cases covered are that NFc can have (i-iii): i. single X.509 certificate, i.e., the same is used for NRF and SCP (e.g., TLS EE client+server certificate #X1 is used for establishing both TLS NFc-SCP and TLS NFc-NRF), ii. two X.509 certificates, i.e., if using different TLS EE client certificates for NRF and SCP, iii. four X.509 certificates, i.e., if using different TLS EE certificates for TLS EE client and TLS EE server (i.e., 2x for both NRF and SCP).

[0120] The method described herein addresses the problem in a single PLMN (i.e., intradomain SBA and non-roaming scenario), wherein the public key of the NF Service Consumer can be obtained via the CCA tokens used in indirect communication.

[0121] NRF validates the CCA token signature using the NF consumer provided public key (via “x5u” or “x5c” header parameter), and also verifies whether the “DPoP (proof)” (e.g., one or multiple public keys / thumbprints) in the CCA token present in the previously registered NF profile (see Note).

[0122] In some examples, it is assumed that all NFs in intra-domain SBA (i.e., both NF consumers and NF producers) have to be registered into NRF (or any other repository). This is also one of the most important pre-requisites for NF consumers (Model B and C) or SCPc (Model D) requesting JWT access tokens. With Model D, SCPc does not or need not to check whether NF consumers have already been registered to NRF.

[0123] This (public key) information is either available during NF registration (currentlyNF producer registration is only via direct communication, i.e., in principle mutual TLS is used), or the information can be obtained out-of-band from the OAM by using the NF Instance ID of the NFc present in the CCA tokens.

[0124] Once verified, NRF adds the TLS EE client certificate public key(s) and / or other “DPoP (proof)” information of the NFc (e.g., one or multiple hashes of public key or certificate fingerprints etc. depending on the usage of shared / dedicated TLS profiles for HTTPS connections with NRF vs. SCPc) in the generated JWT access token (i.e., as “DPoP (proof)” material(s)) and binds the JWT access token in such a way that only the NFc which provides the proof of procession of the corresponding TLS EE client certificate private key(s) can use that JWT access token.

[0125] During the Nnf service request processing for the NFc originated Nnf requests sent to NFp (along with the CCA tokens) via one or multiple SCPs, NFp verifies JWS signature etc. details and whether the “DPoP (proof)” (e.g., one or more public keys / thumbprints etc.) present in the JWT access token matches with the one / one of the thumbprints (if multiple attached) present in the CCA token (see Note below). Only in the case of successful verification (i.e., the verification of the public key present in the access token claims against the CCA tokens) NFp provides the Nnf service for this requester NFc.

[0126] Refer to the table above for the different combinations of “DPoP (proof)” material(s) covered in CCA tokens and (granted) JWT access tokens.

[0127] After this, SCPc provides the JWT access token to NFc for caching so that NFc can reuse the cached JWT access token. Once NFc provides the JWT access token again in the further communication with initial / sub-sequent Nnf service requests, the SCPc needs to authenticate and authorize the NFc and validate that the (re-)used access token in Authorization header is not stolen.

[0128] For this, CCA token is enhanced to include the TLS EE client certificate public key from mTLS because when NRF is generating access token claim, it can also add TLS EE client certificate public key of the NFc in the access token claim. Please note, NFc may use different certificates for CCA tokens and mTLS (i.e., further using multiple TLS EE client and server certificates for different TLS profiles; also, NFc may use TLS EE client certificate rotation where the validity time for the ephemeral TLS EE client certificates is shorter than used for TLS EE server certificates).

[0129] For this, SCPc shall enable “sender-constrained” JWT access tokens based service authorization policy for intra-domain SB A and then check the following (1-4):

[0130] 1 . Nnf service request is for intra-domain SB A; if Nnf service request is for intra- domain SBA then continue with the following checks.

[0131] 2. Nnf service request parameters matches both the contents of the CCA token and the JWT access token sent by the NF Service Consumer (in Authorization header)

[0132] 3. SCP checks if the received JWT access token is sender-constrained (i.e., whether it contains hash of public key(s)). 3a) If JWT access token is NOT sender-constrained, the SCP shall discard the JWT access token (i.e., remove the content in Authorization header) based on the enabled service authorization policy to only use “sender-constrained” JWT access tokens. Depending on the implementation, the SCPs then either requests a new access token in case of Model D (and later return that to NFc in the service response) or forward the Nnf request without the authorization header in the case of Model C or can even reject the Nnf request with an error status. 3b) If JWT access token is sender-constrained (i.e., contains hash of public key / certificate(s)), the SCP shall validate if hash of public key / certificate is matching with the hash of public key / certificate present in the NFc certificate provided via mTLS or CCA tokens, and then 3b 1) If they match, the SCP keeps the JWT access token in Authorization header unchanged as provided by NFc, 3b2) If it does not match, then SCP determine that the JWT access token is stolen and discard the JWT access token (i.e., remove the content in Authorization header) and either request new token from NRF (Model D) or forward the Nnf request without Authorization header (Model C).

[0133] 4. SCP may inform the NFc to delete the JWT access token, e.g., by using “jti” JWT ID claim (with other context information necessary) or using other methods.

[0134] The SCPc applies all the above checks and mechanisms only when it determines that Nnf service request was for intra-PLMN (i.e., Non roaming).

[0135] FIG. 3 is an example apparatus 300, which may be implemented in hardware, configured to implement the examples described herein. The apparatus 300 comprises at least one processor 302 (e.g. an FPGA and / or CPU), one or more memories 304 including computer program code 305, the computer program code 305 having instructions to carry out the methods described herein, wherein the at least one memory 304 and the computer programcode 305 are configured to, with the at least one processor 302, cause the apparatus 300 to implement circuitry, a process, component, module, or function (implemented with control module 306) to implement the examples described herein. The memory 304 may be a non- transitory memory, a transitory memory, a volatile memory (e.g. RAM), or a non-volatile memory (e.g. ROM).

[0136] DPoP signaling 330 may implement the examples described herein related to demonstrating proof of possession to SCP in indirect communication scenarios to allow reusing access tokens only by the legitimate owner.

[0137] The apparatus 300 includes a display and / or I / O interface 308, which includes user interface (UI) circuitry and elements, that may be used to display aspects or a status of the methods described herein (e.g., as one of the methods is being performed or at a subsequent time), or to receive input from a user such as with using a keypad, camera, touchscreen, touch area, microphone, biometric recognition, one or more sensors, etc. The apparatus 300 includes one or more communication e.g. network (N / W) interfaces (I / F(s)) 310. The communication I / F(s) 310 may be wired and / or wireless and communicate over the Internet / other network(s) via any communication technique including via one or more links 324. The link(s) 324 may be the link(s) 131 and / or 176 from FIG. 1. The link(s) 131 and / or 176 from FIG. 1 may also be implemented using transceiver(s) 316 and corresponding wireless link(s) 326. The communication I / F(s) 310 may comprise one or more transmitters or one or more receivers.

[0138] The transceiver 316 comprises one or more transmitters 318 and one or more receivers 320. The transceiver 316 and / or communication I / F(s) 310 may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de)modulator, and encoder / decoder circuitries and one or more antennas, such as antennas 314 used for communication over wireless link 326.

[0139] The control module 306 of the apparatus 300 comprises one of or both parts 306-1 and / or 306-2, which may be implemented in a number of ways. The control module 306 may be implemented in hardware as control module 306-1, such as being implemented as part of the one or more processors 302. The control module 306-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module 306 may be implemented as control module 306-2, which isimplemented as computer program code (having corresponding instructions) 305 and is executed by the one or more processors 302. For instance, the one or more memories 304 store instructions that, when executed by the one or more processors 302, cause the apparatus 300 to perform one or more of the operations as described herein. Furthermore, the one or more processors 302, the one or more memories 304, and example algorithms (e.g., as flowcharts and / or signaling diagrams), encoded as instructions, programs, or code, are means for causing performance of the operations described herein.

[0140] The apparatus 300 to implement the functionality of control 306 may be or correspond to UE 110, RAN node 170 (e.g. gNB), or network element(s) 190 (e.g. AMF 190). Thus, processor 302 may correspond to processor(s) 120, processor(s) 152 and / or processor(s) 175, memory 304 may correspond to one or more memories 125, one or more memories 155 and / or one or more memories 171, computer program code 305 may correspond to computer program code 123, computer program code 153, and / or computer program code 173, control module 306 may correspond to module 140-1, module 140-2, module 150-1, and / or module 150-2, and communication I / F(s) 310 and / or transceiver 316 may correspond to transceiver 130, antenna(s) 128, transceiver 160, antenna(s) 158, N / W I / F(s) 161, and / or N / W I / F(s) 180. Alternatively, apparatus 300 and its elements may not correspond to either of UE 110, RAN node 170, or network element(s) 190 and their respective elements, as apparatus 300 may be part of a self-organizing / optimizing network (SON) node or other node, such as a node in a cloud.

[0141] The apparatus 300 may also be distributed throughout the network (e.g. 100) including within and between apparatus 300 and any network element (such as a network control element (NCE) 190 and / or the RAN node 170 and / or UE 110).

[0142] Apparatus 300 may correspond to any of the apparatuses described herein, including Nfc 210, SCP 220, NFp 230, or authorization server (NRF) 240.

[0143] Interface 312 enables data communication and signaling between the various items of apparatus 300, as shown in FIG. 3. For example, the interface 312 may be one or more buses such as address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. Computer program code (e.g. instructions) 305, including control 306 may comprise object-oriented software configured topass data or messages between objects within computer program code 305, or computer program code (e.g. instructions) 305, including control 306 may include functional, scripting, or procedural code. The apparatus 300 need not comprise each of the features mentioned, or may comprise other features as well. The various components of apparatus 300 may at least partially reside in a common housing 328, or a subset of the various components of apparatus 300 may at least partially be located in different housings, which different housings may include housing 328.

[0144] FIG. 4 shows a schematic representation of non-volatile memory media 400a (e.g. computer / compact disc (CD) or digital versatile disc (DVD)) and 400b (e.g. universal serial bus (USB) memory stick) and 400c (e.g. cloud storage for downloading instructions and / or parameters 402 or receiving emailed instructions and / or parameters 402) storing instructions and / or parameters 402 which when executed by a processor allows the processor to perform one or more of the steps of the methods described herein. Instructions and / or parameters 402 may represent a non-transitory computer readable medium.

[0145] FIG. 5 is an example method 500 based on the examples described herein. At 510, the method includes receiving, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token. At 520, the method includes determining whether the client credentials assertion token comprises demonstrating proof of possession information. At 530, the method includes determining whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information. At 540, the method includes determining to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token. At 550, the method includes determining to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token. Method 500 may be performed with service communication proxy 220 or apparatus 300.

[0146] FIG. 6 is an example method 600 based on the examples described herein. At 610,the method includes transmitting, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information. At 620, the method includes receiving, from the service communication proxy, a response to service request for the service. At 630, the method includes receiving, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information. Method 600 may be performed with network function consumer 210, apparatus 300, or UE 110.

[0147] FIG. 7 is an example method 700 based on the examples described herein. At 710, the method includes receiving, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information. At 720, the method includes transmitting, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information. Method 700 may be performed with authorization server 240 (e.g. NRF 240) or apparatus 300.

[0148] FIG. 8 is an example method 800 based on the examples described herein. At 810, the method includes receiving, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information. At 820, the method includes transmitting, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token. Method 800 may be performed with network function producer 230 or apparatus 300.

[0149] FIG. 9 shows Model A directed to authorization aspects in direct deployment. At 902, the consumer 210 and producer 230 perform authorization based on the NF Service Producer local authorization policy. At 904, the consumer 210 transmits a service request to the producer 230. At 906, the producer transmits a service response 906 to the consumer 210.

[0150] FIG. 10 shows Model B directed to authorization aspects in direct deployment. At 1002, the consumer transmits to the NRF 240 discovery. AT 1004, the NRF 240 transmits tothe consumer one or more NF profiles. At 1006, the consumer 210 requests a token from the NRF 240. At 1008, the NRF 240 authorizes and grants an access token to the consumer. At 1010, the consumer 210 transmits a service request with the access token to the producer 230. At 1012, the producer 230 transmits a service response to the consumer 210.

[0151] FIG. 11 shows Model C directed to authorization aspects in indirect deployment, based on the examples described herein. At 1102, the consumer 210 transmits discovery to the NRF 240. At 1104, the NRF 240 transmits one or more NF profiles to the consumer 210. At 1106, the consumer 210 requests a token from the NRF 240, including DPoP 1120 within the request. At 1108, the NRF 240 authorizes and grants and transmits an access token and DPoP 1122 to the consumer 210. At 1110, the consumer 210 transmits to the SCP 220 a service request (with access token and optional CCA), including DPoP 1124 within the request. At 1112, the SCP 220 transmits to the consumer 210 a response with DPoP 1126. At 1114, the SCP 220 and NRF optionally perform discovery. At 1116, the SCP 220 transmits to the producer 230 a service request (with an access token and optional CCA) with DPoP 1128. At 1118, the producer 230 transmits to the SCP 220 a response with DPoP 1130. DPoP 1120, DPoP 1122, DPoP 1124, DPoP 1126, DPoP 1128, and DPoP 1130 may comprise the same information or at least a portion of the same information, as determined by consumer 210, NRF 240, SCP 220, and producer 230.

[0152] FIG. 12 shows Model D directed to authorization aspects in indirect deployment, based on the examples described herein. At 1202, the consumer 210 transmits a service request (including optional CCA) to SCP 220 with DPoP 1220. At 1204, the SCP 220 transmits a response to the consumer 210 with DPoP 1222. At 1206, the SCP 220 transmits discovery to NRF 240. At 1208, the NRF 240 transmits one or more NF profiles to SCP 220. At 1210, the SCP 220 transmits to the NRF 240 a request for a token (with optional CCA) with DPoP 1224. At 1212, the NRF 240 authorizes the token request and grants and transmits the access token to the SCP 220 with DPoP 1226. At 1214, the SCP 220 transmits to the producer 230 a service request (with an access token and optional CCA) with DPoP 1228. At 1216, the producer 230 transmits a response to the SCP 220 with DPoP 1230. DPoP 1220, DPoP 1222, DPoP 1224, DPoP 1226, DPoP 1228, and DPoP 1230 may comprise the same information or at least a portion of the same information, as determined by consumer 210, NRF 240, SCP 220, and producer 230.

[0153] The following examples are provided and described herein.

[0154] Example 1. An apparatus including: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; determine whether the client credentials assertion token comprises demonstrating proof of possession information; determine whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; determine to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and determine to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

[0155] Example 2. The apparatus of example 1, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine to discard the service request, in response to the client credentials assertion token not comprising demonstrating proof of possession information.

[0156] Example 3. The apparatus of any of examples 1 to 2, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a network function instance identifier of the network function consumer within the client credentials assertion token matches a network function instance identifier within the transport layer security end entity client certificate of the network function consumer; and determine to discard the service request, in response to the network function instance identifier of the network function consumer within the client credentials assertion token not matching the network function instance identifier within the transport layer security end entity client certificate of the network function consumer.

[0157] Example 4. The apparatus of any of examples 1 to 3, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the network function consumer, a response to the service request for the service, in response to the information associated with the transport layer security end entity client certificate matchingat least the portion of the demonstrating proof of possession information of the client credentials assertion token, wherein the response comprises an access token.

[0158] Example 5. The apparatus of example 4, wherein the response comprises the access token due to an access token not having been received from the network function consumer within the service request.

[0159] Example 6. The apparatus of any of examples 4 to 5, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: request, due to an exception, the access token.

[0160] Example 7. The apparatus of example 6, wherein the response comprises the access token, based on the apparatus requesting the access token due to the exception.

[0161] Example 8. The apparatus of any of examples 1 to 7, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether an access token was received in the service request; transmit, to an authorization server, an access token request for an access token, in response to no access token being received in the service request, the access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and receive, from the authorization server, the access token with demonstrating proof of possession information.

[0162] Example 9. The apparatus of example 8, wherein the access token request is associated with a model D, and the service request is associated with a model C or model D.

[0163] Example 10. The apparatus of any of examples 8 to 9, wherein the demonstrating proof of possession information of the access token is the same as the demonstrating proof of possession information of the client credentials assertion token.

[0164] Example 11. The apparatus of any of examples 8 to 10, wherein the demonstrating proof of possession information of the access token is different from and comprise a portion of the demonstrating proof of possession information of the client credentials assertion token.

[0165] Example 12. The apparatus of any of examples 8 to 11, wherein the authorization server comprises a network repository function (NRF).

[0166] Example 13. The apparatus of any of examples 8 to 12, wherein the instructions,when executed by the at least one processor, cause the apparatus at least to: transmit, to a network function producer, a producer service request comprising a client credentials assertion token comprising demonstrating proof of possession information, and the access token with demonstrating proof of possession information received from the authorization server; and receive, from the network function producer, a response to the producer service request that gives access to the service provided from the network function producer, based on at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the producer service request matching at least a portion of the demonstrating proof of possession information of the access token received from the authorization server.

[0167] Example 14. The apparatus of example 13, wherein the response to the producer service request that gives access to the service provided from the network function producer is received from the network function producer when a public key present in the access token matches a public key present in the client credentials assertion token.

[0168] Example 15. The apparatus of any of examples 13 to 14, wherein the client credentials assertion token of the producer service request comprises an indication of an expected audience that is at least partially a target network function producer type.

[0169] Example 16. The apparatus of any of examples 13 to 15, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the network function consumer, a response to the service request, the response comprising an access token with demonstrating proof of possession information, wherein the response indicates that the network function consumer is given access to the service provided with the network function producer.

[0170] Example 17. The apparatus of example 16, wherein the access token with demonstrating proof of possession information of the response transmitted to the network function consumer is the access token with demonstrating proof of possession information received from the authorization server.

[0171] Example 18. The apparatus of any of examples 8 to 17, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the authorization server, a subsequent access token request for new access token, the subsequent access token request comprising a client credentials assertion token comprising demonstratingproof of possession information; and receive, from the authorization server, the new access token with demonstrating proof of possession information.

[0172] Example 19. The apparatus of any of examples 8 to 18, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the network function consumer or another network function consumer, a subsequent service request for the service comprising a client credentials assertion token comprising demonstrating proof of possession information and an access token; wherein the subsequent service request for the service is subsequent to the service request for the service; determine whether the information associated with the transport layer security end entity client certificate of the network function consumer or the another network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request; determine to discard the subsequent service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request; determine whether the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request matches the demonstrating proof of possession information of the access token received from the authorization server; and determine to discard the subsequent service request, in response to the demonstrating proof of possession information of the client credentials assertion token of the subsequent service requests not matching the demonstrating proof of possession information of the access token received from the authorization server.

[0173] Example 20. The apparatus of example 19, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine that the another network function consumer is a non-legitimate network function consumer, in response to determining to discard the subsequent service request.

[0174] Example 21. The apparatus of any of examples 8 to 20, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request received from the network function consumer, due to at least one first transport layer profile used with the network function consumer for the authorization server being different from at least one second transport layer profile used with the network functionconsumer for the apparatus.

[0175] Example 22. The apparatus of any of examples 8 to 21, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request received from the network function consumer, due to at least one first transport layer end entity certificate used with the network function consumer for the authorization server being different from at least one second transport layer end entity certificate used with the network function consumer for the apparatus.

[0176] Example 23. The apparatus of any of examples 1 to 22, wherein the demonstrating proof of possession information of the client credentials assertion token comprises at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates, or one or more hashes of a mutual transport layer security certificate.

[0177] Example 24. The apparatus of any of examples 1 to 23, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether at least a portion of the demonstrating proof of possession information of the client credentials assertion token matches at least a portion of demonstrating proof of possession information of an access token received with the service request; determine to process the service request, in response to the demonstrating proof of possession information of the client credentials assertion token at least partially matching the demonstrating proof of possession information of the access token received with the service request; and determine to discard the service request, in response to any of the demonstrating proof of possession information of the client credentials assertion token not matching any of the demonstrating proof of possession information of the access token received with the service request.

[0178] Example 25. The apparatus of any of examples 1 to 24, wherein the apparatus comprises a service communication proxy, or a service communication proxy comprises the apparatus.

[0179] Example 26. An apparatus including: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: transmit, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof ofpossession information; receive, from the service communication proxy, a response to service request for the service; and receive, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

[0180] Example 27. The apparatus of example 26, wherein the response to the service request received from the service communication proxy comprises the access token with demonstrating proof of possession information.

[0181] Example 28. The apparatus of example 27, wherein the service request is associated with a model D.

[0182] Example 29. The apparatus of any of examples 26 to 28, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to an authorization server, an access token request for the access token, the access token request comprising the client credentials assertion token comprising the demonstrating proof of possession information; and receive, from the authorization server, the access token comprising the demonstrating proof of possession information.

[0183] Example 30. The apparatus of example 29, wherein the access token request is associated with a model C.

[0184] Example 31. The apparatus of any of examples 29 to 30, wherein: the access token request for the access token is transmitted to the authorization server before the apparatus transmits the service request to the service communication proxy; and the service request comprises both the client credentials assertion token comprising demonstrating proof of possession information and the access token comprising demonstrating proof of possession information.

[0185] Example 32. The apparatus of any of examples 29 to 31, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request transmitted to the service communication proxy, due to at least one first transport layer profile used with the apparatus for the authorization server being different from at least one second transport layer profile used with the apparatus for the service communication proxy.

[0186] Example 33. The apparatus of any of examples 29 to 32, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request transmitted to the service communication proxy, due to at least one first transport layer end entity certificate used with the apparatus for the authorization server being different from at least one second transport layer end entity certificate used with the apparatus for the service communication proxy.

[0187] Example 34. The apparatus of any of examples 26 to 33, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the service communication proxy, a subsequent service request for the service comprising: the client credentials assertion token comprising the demonstrating proof of possession information, and the access token with the demonstrating proof of possession information; wherein the subsequent service request for the service is subsequent to the service request for the service.

[0188] Example 35. The apparatus of example 34, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the service communication proxy, an indication to reuse the access token with the demonstrating proof of possession information to access the service, when the demonstrating proof of possession information of the client credentials assertion token matches the demonstrating proof of possession information of the access token.

[0189] Example 36. The apparatus of any of examples 26 to 35, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token comprise at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates , or one or more hashes of a mutual transport layer security certificate.

[0190] Example 37. The apparatus of any of examples 26 to 36, wherein: the apparatus comprises a network function consumer, or a network function consumer comprises the apparatus, or the apparatus comprises a user equipment, or a user equipment comprises the apparatus.

[0191] Example 38. An apparatus including: at least one processor; and at least one memorystoring instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and transmit, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

[0192] Example 39. The apparatus of example 38, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine the demonstrating proof of possession information in the access token with all or parts of the demonstrating proof of possession information of the client credentials assertion token.

[0193] Example 40. The apparatus of any of examples 38 to 39, wherein: the access token request is associated with a model C when the access token request is received from the network function consumer; and the access token request is associated with a model D when the access token request is received from the service communication proxy.

[0194] Example 41. The apparatus of any of examples 38 to 40, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches with information associated with a transport layer security end entity client certificate of the network function consumer; wherein the access token with demonstrating proof of possession information is transmitted to the network function consumer in response to determining that the portion of the demonstrating proof of possession information of the client credentials assertion token matches with the information associated with the transport layer security end entity client certificate of the network function consumer.

[0195] Example 42. The apparatus of example 41, wherein the information associated with the transport layer security end entity client certificate of the network function consumer comprises a network function identifier.

[0196] Example 43. The apparatus of any of examples 38 to 42, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches with a network function instance identifier in a public key certificate used for signing the client credentials assertion token; wherein the access token withdemonstrating proof of possession information is transmitted to the network function consumer in response to determining that the portion of the demonstrating proof of possession information of the client credentials assertion token matches with the network function instance identifier in the public key certificate used for signing the client credentials assertion token.

[0197] Example 44. The apparatus of any of examples 38 to 43, wherein the demonstrating proof of possession information of the access token is configured to be used to determine whether a network function consumer is given access to a service provided with a network function producer, based on network function consumer demonstrating proof of possession information of any client credentials assertion token matching the demonstrating proof of possession information of the access token.

[0198] Example 45. The apparatus of any of examples 38 to 44, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token of the comprise at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates, or one or more hashes of a mutual transport layer security certificate.

[0199] Example 46. The apparatus of any of examples 38 to 45, wherein the apparatus comprises a network repository function (NRF).

[0200] Example 47. The apparatus of any of examples 38 to 46, wherein the apparatus comprises an authorization server, or an authorization server comprises the apparatus.

[0201] Example 48. The apparatus of any of examples 38 to 47, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of demonstrating proof of possession information of a service request associated with the service communication proxy, due to at least one first transport layer profile used with the network function consumer for the apparatus being different from at least one second transport layer profile used with the network function consumer for the service communication proxy.

[0202] Example 49. The apparatus of any of examples 38 to 48, wherein the demonstrating proof of possession information of the client credentials assertion token of the access tokenrequest comprises at least a portion of the demonstrating proof of possession information of a service request associated with the service communication proxy, due to at least one first transport layer end entity certificate used with the network function consumer for the apparatus being different from at least one second transport layer end entity certificate used with the network function consumer for the service communication proxy.

[0203] Example 50. An apparatus including: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and transmit, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.

[0204] Example 51. The apparatus of example 50, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the service request matches at least a portion demonstrating proof of possession information of the access token; wherein the response to the service request that gives the network function consumer access to the service provided with the apparatus is transmitted to the service communication proxy in response to at least the portion of the demonstrating proof of possession information of the client credentials assertion token of the service request matching at least the portion of the demonstrating proof of possession information of the access token.

[0205] Example 52. The apparatus of any of examples 50 to 51, wherein the response to the service request that gives the network function consumer access to the service provided with the apparatus is transmitted to the service communication proxy when a public key present in the access token matches a public key present in the client credentials assertion token.

[0206] Example 53. The apparatus of any of examples 50 to 52, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token comprise at least one or more of: one ormore mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates , or one or more hashes of a mutual transport layer security certificate.

[0207] Example 54. The apparatus of any of examples 50 to 53, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches a network function instance identifier in a public key certificate used for signing the client credentials assertion token; determine to process the service request, in response to the portion of the demonstrating proof of possession information of the client credentials assertion token matching the network function instance identifier in a public key certificate used for signing the client credentials assertion token; and determine to discard the service request, in response to any of the demonstrating proof of possession information of the client credentials assertion token not matching the network function instance identifier in the public key certificate used for signing the client credentials assertion token.

[0208] Example 55. The apparatus of any of examples 50 to 54, wherein the apparatus comprises a network function producer, or a network function producer comprises the apparatus.

[0209] Example 56. A method including: receiving, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; determining whether the client credentials assertion token comprises demonstrating proof of possession information; determining whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; determining to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and determining to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

[0210] Example 57. A method including: transmitting, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information; receiving, from the service communication proxy, a response to service request for the service; and receiving, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

[0211] Example 58. A method including: receiving, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and transmitting, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

[0212] Example 59. A method including: receiving, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and transmitting, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.

[0213] Example 60. An apparatus including: means for receiving, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; means for determining whether the client credentials assertion token comprises demonstrating proof of possession information; means for determining whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; means for determining to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and means for determining to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portionof the demonstrating proof of possession information of the client credentials assertion token.

[0214] Example 61. An apparatus including: means for transmitting, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information; means for receiving, from the service communication proxy, a response to service request for the service; and means for receiving, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

[0215] Example 62. An apparatus including: means for receiving, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and means for transmitting, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

[0216] Example 63. An apparatus including: means for receiving, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and means for transmitting, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.

[0217] Example 64. A computer readable medium including instructions stored thereon for performing at least the following: receiving, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; determining whether the client credentials assertion token comprises demonstrating proof of possession information; determining whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; determining to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the clientcredentials assertion token; and determining to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

[0218] Example 65. A computer readable medium including instructions stored thereon for performing at least the following: transmitting, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information; receiving, from the service communication proxy, a response to service request for the service; and receiving, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

[0219] Example 66. A computer readable medium including instructions stored thereon for performing at least the following: receiving, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and transmitting, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

[0220] Example 67. A computer readable medium including instructions stored thereon for performing at least the following: receiving, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and transmitting, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.

[0221] References to a ‘computer’, ‘processor’, etc. should be understood to encompass not only computers having different architectures such as single / multi-processor architectures and sequential or parallel architectures but also specialized circuits such as field- programmable gate arrays (FPGAs), application specific circuits (ASICs), signal processing devices and other processing circuitry. References to computer program, instructions, codeetc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

[0222] The memories as described herein may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, non-transitory memory, transitory memory, fixed memory and removable memory. The memories may comprise a database for storing data.

[0223] As used herein, the term ‘circuitry’ may refer to the following: (a) hardware circuit implementations, such as implementations in analog and / or digital circuitry, and (b) combinations of circuits and software (and / or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s) / software including digital signal processor(s), software, and memories that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. As a further example, as used herein, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

[0224] It should be understood that the foregoing description is only illustrative. Various alternatives and modifications may be devised by those skilled in the art. For example, features recited in the various dependent claims and examples could be combined with each other in any suitable combination(s). In addition, features from different example embodiments described above could be selectively combined into a new example embodiment. Accordingly, this description is intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.

[0225] The following acronyms and abbreviations that may be found in the specification and / or the drawing figures are given as follows (the abbreviations and acronyms may beappended / combined with each other or with other characters using e.g. a dash, hyphen, slash, letter, or number, and may be case insensitive):3 GPP third generation partnership project4G fourth generation5G fifth generation5GC 5G core network5GS 5G systemAMF access and mobility management functionAPI application programming interfaceAS authorization server (e.g. AS-NRF)ASIC application-specific integrated circuitAT access tokenCA certificate authorityCCA client credentials assertionCD compact / computer disc cnf confirmationCPU central processing unitCU central unit or centralized unitDPoP demonstrating proof of possessionDSP digital signal processorDU distributed unitDVD digital versatile discEE end entityEKU extended key usage eNB evolved Node B (e.g., an LTE base station) exp expirationEN-DC E-UTRAN new radio - dual connectivity en-gNB node providing NR user plane and control plane protocol terminations towards the UE, and acting as a secondary node in EN- DCE-UTRA evolved UMTS terrestrial radio access, i.e., the LTE radio access technologyE-UTRAN E-UTRA networkF 1 interface between the CU and the DUFPGA field-programmable gate array gNB base station for 5G / NR, i.e., a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC hNRF authorization server in the hPLMN hPLMN home public land mobile networkHTTP hypertext transfer protocolHTTPS HTTP secureIAB integrated access and backhaul iat issued at timeID identifierIETF Internet Engineering T ask F orceI / F interfaceI / O input / output jkt JSON web key SHA-256 thumbprintJOSE JSON object signing and encryptionJSON JavaScript object notation jti JWT IDJWS JSON web signatureJWT JSON web token kp key usage purposeKU key usageL7 layer 7LB load balancingLMF location management functionLTE long term evolution (4G)MAC medium access controlMME mobility management entityMRO mobility robustness optimization mTLS mutual transport layer securityN indication of a service-based interface (e.g. Nnrf is the service based interface for a network repository function (nrf))NCE network control elementNF network functionNFc NF service consumerNFp NF service producer ng or NG new generation ng-eNB new generation eNBNG-RAN new generation radio access networkNnf service request by any network function nfNR new radioNRF network repository functionNW networkN / W networkOAM operations and management, or operations, administration and maintenanceOAuth open authorization opt. optionallyPDA personal digital assistantPDCP packet data convergence protocolPHY physical layerPKI public key infrastructurePLMN public land mobile networkRAM random access memoryRAN radio access networkRel releaseRFC request for commentsRLC radio link controlROM read-only memoryRRC radio resource controlRU radio unitRx, RX receive, or receiver, or receptionSBA service-based architectureSBI service based interface (e.g. in “3gpp-Sbi-Client-Credentials”)SCP service communication proxySCPc service communication proxy related to the NF service consumerSCPp service communication proxy related to the NF service producerSDAP service data adaptation protocolSEPP security edge protection proxySGW serving gatewaySHA-1 secure hash algorithm 1SHA256 secure hash algorithm 256-bitSID study item descriptionSMF session management functionSON self-organizing / optimizing networkTLS transport layer securityTRP transmission reception pointTS technical specificationTx, TX transmit, or transmitter, or transmissionUAV unmanned aerial vehicleUE user equipment (e.g., a wireless, typically mobile device)UI user interfaceUMTS Universal Mobile Telecommunications SystemUPF user plane functionUR1 uniform resource identifierURL uniform resource locatorUSB universal serial busUTRAN UMTS terrestrial radio access networkWAAP web application and API protectionX.509 International Telecommunication Union standard defining the format of public key certificates x5c X.509 certificate chain x5u X.509 URLX2 network interface between RAN nodes and between RAN and the core network (depending on context)Xn network interface between NG-RAN nodes

Claims

CLAIMSWhat is claimed is:

1. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer, service request for a service, the service request comprising a client credentials assertion token; determine whether the client credentials assertion token comprises demonstrating proof of possession information; determine whether information associated with a transport layer security end entity client certificate of the network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token, when the client credentials assertion token comprises demonstrating proof of possession information; determine to process the service request, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token; and determine to discard the service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token.

2. The apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to:determine to discard the service request, in response to the client credentials assertion token not comprising demonstrating proof of possession information.

3. The apparatus of any of claims 1 to 2, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a network function instance identifier of the network function consumer within the client credentials assertion token matches a network function instance identifier within the transport layer security end entity client certificate of the network function consumer; and determine to discard the service request, in response to the network function instance identifier of the network function consumer within the client credentials assertion token not matching the network function instance identifier within the transport layer security end entity client certificate of the network function consumer.

4. The apparatus of any of claims 1 to 3, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the network function consumer, a response to the service request for the service, in response to the information associated with the transport layer security end entity client certificate matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token, wherein the response comprises an access token.

5. The apparatus of claim 4, wherein the response comprises the access token due to an access token not having been received from the network function consumer within the service request.

6. The apparatus of any of claims 4 to 5, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: request, due to an exception, the access token.

7. The apparatus of claim 6, wherein the response comprises the access token, based on the apparatus requesting the access token due to the exception.

8. The apparatus of any of claims 1 to 7, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether an access token was received in the service request; transmit, to an authorization server, an access token request for an access token, in response to no access token being received in the service request, the access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and receive, from the authorization server, the access token with demonstrating proof of possession information.

9. The apparatus of claim 8, wherein the access token request is associated with a model D, and the service request is associated with a model C or model D.

10. The apparatus of any of claims 8 to 9, wherein the demonstrating proof of possession information of the access token is the same as the demonstrating proof of possession information of the client credentials assertion token.

11. The apparatus of any of claims 8 to 10, wherein the demonstrating proof of possession information of the access token is different from and comprise a portion of the demonstrating proof of possession information of the client credentials assertion token.

12. The apparatus of any of claims 8 to 11, wherein the authorization server comprises a network repository function (NRF).

13. The apparatus of any of claims 8 to 12, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to a network function producer, a producer service request comprising a client credentials assertion token comprising demonstrating proof of possession information, and the access token with demonstrating proof of possession information received from the authorization server; and receive, from the network function producer, a response to the producer servicerequest that gives access to the service provided from the network function producer, based on at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the producer service request matching at least a portion of the demonstrating proof of possession information of the access token received from the authorization server.

14. The apparatus of claim 13, wherein the response to the producer service request that gives access to the service provided from the network function producer is received from the network function producer when a public key present in the access token matches a public key present in the client credentials assertion token.

15. The apparatus of any of claims 13 to 14, wherein the client credentials assertion token of the producer service request comprises an indication of an expected audience that is at least partially a target network function producer type.

16. The apparatus of any of claims 13 to 15, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the network function consumer, a response to the service request, the response comprising an access token with demonstrating proof of possession information, wherein the response indicates that the network function consumer is given access to the service provided with the network function producer.

17. The apparatus of claim 16, wherein the access token with demonstrating proof of possession information of the response transmitted to the network function consumer is the access token with demonstrating proof of possession information received from the authorization server.

18. The apparatus of any of claims 8 to 17, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the authorization server, a subsequent access token request for new access token, the subsequent access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and receive, from the authorization server, the new access token with demonstratingproof of possession information.

19. The apparatus of any of claims 8 to 18, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the network function consumer or another network function consumer, a subsequent service request for the service comprising a client credentials assertion token comprising demonstrating proof of possession information and an access token; wherein the subsequent service request for the service is subsequent to the service request for the service; determine whether the information associated with the transport layer security end entity client certificate of the network function consumer or the another network function consumer matches at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request; determine to discard the subsequent service request, in response to the information associated with the transport layer security end entity client certificate not matching at least the portion of the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request; determine whether the demonstrating proof of possession information of the client credentials assertion token of the subsequent service request matches the demonstrating proof of possession information of the access token received from the authorization server; and determine to discard the subsequent service request, in response to the demonstrating proof of possession information of the client credentials assertion token of the subsequent service requests not matching the demonstrating proof of possession information of the access token received from the authorization server.

20. The apparatus of claim 19, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to:determine that the another network function consumer is a non-legitimate network function consumer, in response to determining to discard the subsequent service request.

21. The apparatus of any of claims 8 to 20, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request received from the network function consumer, due to at least one first transport layer profile used with the network function consumer for the authorization server being different from at least one second transport layer profile used with the network function consumer for the apparatus.

22. The apparatus of any of claims 8 to 21, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request received from the network function consumer, due to at least one first transport layer end entity certificate used with the network function consumer for the authorization server being different from at least one second transport layer end entity certificate used with the network function consumer for the apparatus.

23. The apparatus of any of claims 1 to 22, wherein the demonstrating proof of possession information of the client credentials assertion token comprises at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates, or one or more hashes of a mutual transport layer security certificate.

24. The apparatus of any of claims 1 to 23, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether at least a portion of the demonstrating proof of possessioninformation of the client credentials assertion token matches at least a portion of demonstrating proof of possession information of an access token received with the service request; determine to process the service request, in response to the demonstrating proof of possession information of the client credentials assertion token at least partially matching the demonstrating proof of possession information of the access token received with the service request; and determine to discard the service request, in response to any of the demonstrating proof of possession information of the client credentials assertion token not matching any of the demonstrating proof of possession information of the access token received with the service request.

25. The apparatus of any of claims 1 to 24, wherein the apparatus comprises a service communication proxy, or a service communication proxy comprises the apparatus.

26. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: transmit, to a service communication proxy, a service request for a service, the service request comprising a client credentials assertion token comprising demonstrating proof of possession information; receive, from the service communication proxy, a response to service request for the service; and receive, from the service communication proxy or an authorization server, an access token comprising demonstrating proof of possession information.

27. The apparatus of claim 26, wherein the response to the service request received from the service communication proxy comprises the access token with demonstrating proof of possession information.

28. The apparatus of claim 27, wherein the service request is associated with a model D.

29. The apparatus of any of claims 26 to 28, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to an authorization server, an access token request for the access token, the access token request comprising the client credentials assertion token comprising the demonstrating proof of possession information; and receive, from the authorization server, the access token comprising the demonstrating proof of possession information.

30. The apparatus of claim 29, wherein the access token request is associated with a model C.

31. The apparatus of any of claims 29 to 30, wherein: the access token request for the access token is transmitted to the authorization server before the apparatus transmits the service request to the service communication proxy; and the service request comprises both the client credentials assertion token comprising demonstrating proof of possession information and the access token comprising demonstrating proof of possession information.

32. The apparatus of any of claims 29 to 31, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of the service request transmitted to the service communication proxy, due to at least one first transport layer profile used with the apparatus for the authorization server being different from at least one second transport layer profile used with the apparatus for the service communication proxy.

33. The apparatus of any of claims 29 to 32, wherein the demonstrating proof of possession information of the client credentials assertion token of the access tokenrequest comprises at least a portion of the demonstrating proof of possession information of the service request transmitted to the service communication proxy, due to at least one first transport layer end entity certificate used with the apparatus for the authorization server being different from at least one second transport layer end entity certificate used with the apparatus for the service communication proxy.

34. The apparatus of any of claims 26 to 33, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the service communication proxy, a subsequent service request for the service comprising: the client credentials assertion token comprising the demonstrating proof of possession information, and the access token with the demonstrating proof of possession information; wherein the subsequent service request for the service is subsequent to the service request for the service.

35. The apparatus of claim 34, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the service communication proxy, an indication to reuse the access token with the demonstrating proof of possession information to access the service, when the demonstrating proof of possession information of the client credentials assertion token matches the demonstrating proof of possession information of the access token.

36. The apparatus of any of claims 26 to 35, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token comprise at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates , or one or more hashes of a mutual transport layer security certificate.

37. The apparatus of any of claims 26 to 36, wherein: the apparatus comprises a network function consumer, or a network function consumer comprises the apparatus, or the apparatus comprises a user equipment, or a user equipment comprises the apparatus.

38. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network function consumer or a service communication proxy, an access token request comprising a client credentials assertion token comprising demonstrating proof of possession information; and transmit, to the network function consumer or the service communication proxy, an access token with demonstrating proof of possession information.

39. The apparatus of claim 38, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine the demonstrating proof of possession information in the access token with all or parts of the demonstrating proof of possession information of the client credentials assertion token.

40. The apparatus of any of claims 38 to 39, wherein: the access token request is associated with a model C when the access token request is received from the network function consumer; and the access token request is associated with a model D when the access token request is received from the service communication proxy.

41. The apparatus of any of claims 38 to 40, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches with information associated with a transport layer security end entity client certificate of the network function consumer; wherein the access token with demonstrating proof of possession information is transmitted to the network function consumer in response to determining that the portion of the demonstrating proof of possession information of the client credentials assertion token matches with the information associated with the transport layer security end entity client certificate of the network function consumer.

42. The apparatus of claim 41, wherein the information associated with the transport layer security end entity client certificate of the network function consumer comprises a network function identifier.

43. The apparatus of any of claims 38 to 42, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches with a network function instance identifier in a public key certificate used for signing the client credentials assertion token; wherein the access token with demonstrating proof of possession information is transmitted to the network function consumer in response to determining that the portion of the demonstrating proof of possession information of the client credentials assertion token matches with the network function instance identifier in the public key certificate used for signing the client credentials assertion token.

44. The apparatus of any of claims 38 to 43, wherein the demonstrating proof of possession information of the access token is configured to be used to determine whether a network function consumer is given access to a service provided with anetwork function producer, based on network function consumer demonstrating proof of possession information of any client credentials assertion token matching the demonstrating proof of possession information of the access token.

45. The apparatus of any of claims 38 to 44, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token of the comprise at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates , or one or more hashes of a mutual transport layer security certificate.

46. The apparatus of any of claims 38 to 45, wherein the apparatus comprises a network repository function (NRF).

47. The apparatus of any of claims 38 to 46, wherein the apparatus comprises an authorization server, or an authorization server comprises the apparatus.

48. The apparatus of any of claims 38 to 47, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of demonstrating proof of possession information of a service request associated with the service communication proxy, due to at least one first transport layer profile used with the network function consumer for the apparatus being different from at least one second transport layer profile used with the network function consumer for the service communication proxy.

49. The apparatus of any of claims 38 to 48, wherein the demonstrating proof of possession information of the client credentials assertion token of the access token request comprises at least a portion of the demonstrating proof of possession information of a service request associated with the service communication proxy, due to at least one first transport layer end entity certificate used with the network functionconsumer for the apparatus being different from at least one second transport layer end entity certificate used with the network function consumer for the service communication proxy.

50. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a service communication proxy, a service request comprising: a client credentials assertion token comprising demonstrating proof of possession information, and an access token with demonstrating proof of possession information; and transmit, to the service communication proxy, a response to the service request that gives a network function consumer access to a service provided with the apparatus, based on the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token.

51. The apparatus of claim 50, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether at least a portion of the demonstrating proof of possession information of the client credentials assertion token of the service request matches at least a portion demonstrating proof of possession information of the access token; wherein the response to the service request that gives the network function consumer access to the service provided with the apparatus is transmitted to the service communication proxy in response to at least the portion of the demonstrating proof of possession information of the client credentials assertion token of the service request matching at least the portion of the demonstrating proof of possession information of the access token.

52. The apparatus of any of claims 50 to 51, wherein the response to the service request that gives the network function consumer access to the service provided with the apparatus is transmitted to the service communication proxy when a public key present in the access token matches a public key present in the client credentials assertion token.

53. The apparatus of any of claims 50 to 52, wherein the demonstrating proof of possession information of the client credentials assertion token and the demonstrating proof of possession information of the access token comprise at least one or more of: one or more mutual transport layer security public keys, or one or more hashes of a mutual transport layer security public key, or one or more mutual transport layer security certificates , or one or more hashes of a mutual transport layer security certificate.

54. The apparatus of any of claims 50 to 53, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether a portion of the demonstrating proof of possession information of the client credentials assertion token matches a network function instance identifier in a public key certificate used for signing the client credentials assertion token; determine to process the service request, in response to the portion of the demonstrating proof of possession information of the client credentials assertion token matching the network function instance identifier in a public key certificate used for signing the client credentials assertion token; and determine to discard the service request, in response to any of the demonstrating proof of possession information of the client credentials assertion token not matching the network function instance identifier in the public key certificate used for signing the client credentials assertion token.

55. The apparatus of any of claims 50 to 54, wherein the apparatus comprises a network function producer, or a network function producer comprises the apparatus.

Images