The display of SCPs in indirect communication scenarios is certified to allow access tokens to be reused only by the legitimate owner.

Abstract

An apparatus (220) is configured to: receive a service request (200-B1) from a network function consumer (210), the service request including a client credential assertion token; determine (200-B2) whether information associated with a transport layer security terminal entity client certificate of the network function consumer matches at least a portion of the display ownership proof information of the client credential assertion token; in response to the match between the information associated with the transport layer security terminal entity client certificate and at least a portion of the display ownership proof information of the client credential assertion token, determine to process the service request; and in response to the mismatch between the information associated with the transport layer security terminal entity client certificate and at least a portion of the display ownership proof information of the client credential assertion token, determine to discard the service request.

Description

Technical Field

[0001] The example and non-limiting example embodiments generally relate to communication, and more specifically, to demonstrating ownership of a service communication agent in an indirect communication scenario to allow the reuse of an access token only by the legitimate owner. Background Technology

[0002] It is known that communication devices gain access to the communication network through access network nodes. Summary of the Invention

[0003] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: receive a service request for a service from a network function consumer, the service request including a client credential assertion token; determine whether the client credential assertion token includes display ownership information; when the client credential assertion token includes display ownership information, determine whether information associated with a Transport Layer Security (TLS) End Entity (TLSE) client certificate of the network function consumer matches at least a portion of the display ownership information of the client credential assertion token; in response to the information associated with the TLSSE client certificate matching at least a portion of the display ownership information of the client credential assertion token, determine to process the service request; and in response to the information associated with the TLSSE client certificate not matching at least a portion of the display ownership information of the client credential assertion token, determine to discard the service request.

[0004] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: transmit a service request for a service to a service communication agent, the service request including a client credential assertion token, the client credential assertion token including proof of ownership information; receive a response to the service request for the service from the service communication agent; and receive an access token including proof of ownership information from the service communication agent or an authorization server.

[0005] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: receive an access token request from a network function consumer or service communication agent, the access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and transmit an access token having proof of ownership information to the network function consumer or the service communication agent.

[0006] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: receive a service request from a service communication agent, the service request including: a client credential assertion token having proof of ownership information and an access token having proof of ownership information; and, based on the proof of ownership information of the client credential assertion token and the proof of ownership information of the access token, transmit a response to the service communication agent in response to the service request, the response granting a network function consumer access to services provided by the apparatus. Attached Figure Description

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

[0008] Figure 1 This is a block diagram of one possible, non-limiting system in which exemplary embodiments can be practiced.

[0009] Figure 2 This is a signaling diagram based on the example described in this article.

[0010] Figure 3 It is an example device configured to implement the examples described herein.

[0011] Figure 4 A representation of an example of a non-volatile memory medium for storing instructions implementing the examples described herein is shown.

[0012] Figure 5 This is an example method based on the examples described in this article.

[0013] Figure 6 This is an example method based on the examples described in this article.

[0014] Figure 7 This is an example method based on the examples described in this article.

[0015] Figure 8 This is an example method based on the examples described in this article.

[0016] Figure 9 Model A is shown for the authorization aspect in direct deployment.

[0017] Figure 10 Model B is shown for the authorization aspect in direct deployment.

[0018] Figure 11 Model C for the authorization aspect in indirect deployments is shown, based on the example described in this paper.

[0019] Figure 12Model D for the authorization aspect in indirect deployments is shown, based on the example described in this paper. Detailed Implementation

[0020] Go to Figure 1 The figure illustrates a block diagram of one possible and non-limiting example of an example in which practical examples can be implemented. It shows a user equipment (UE) 110, a radio access network (RAN) node 170, and network elements 190. Figure 1 In the example, User Equipment (UE) 110 wirelessly communicates with Wireless Network 100. The UE is a wireless device that can access Wireless Network 100. UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected via 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 optic cables, or other optical communication devices. 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. UE 110 includes a module 140, which includes one or both of portions 140-1 and / or 140-2, which may be implemented in various ways. Module 140 may be implemented in hardware as module 140-1, such as being implemented as part of one or more processors 120. Module 140-1 can also be implemented as an integrated circuit or via other hardware such as a programmable gate array. In another example, module 140 can be implemented as module 140-2, which is implemented as computer program code 123 and executed by one or more processors 120. For example, one or more memories 125 and computer program code 123 can be configured to perform one or more operations as described herein with the user device 110 using one or more processors 120. UE 110 communicates with RAN node 170 via wireless link 111.

[0021] In this example, RAN node 170 is a base station that provides access to wireless network 100 for wireless devices such as UE 110. RAN node 170 can be, for example, a base station for 5G (also known as New Radio (NR)). In 5G, RAN node 170 can be an NG-RAN node, which is defined as a gNB or ng-eNB. A gNB is a node that provides NR user plane and control plane protocol termination to the UE and is connected to the 5G core network (5GC) (such as, for example, network element 190) via an NG interface (such as connection 131). An ng-eNB is a node that provides E-UTRA user plane and control plane protocol termination to the UE and is connected to the 5GC via an NG interface (such as connection 131). An NG-RAN node can include multiple gNBs, and can also include centralized unit (CU) (gNB-CU) 196 and distributed unit (DU) (gNB-DU), where DU 195 is shown. Note that DU 195 can include or be coupled to and control a radio unit (RU). gNB-CU 196 is a logical node that hosts the Radio Resource Control (RRC) protocol, at least one Service Data Adaptation Protocol (SDAP), and at least one Packet Data Convergence Protocol (PDCP) of a gNB or the RRC and PDCP protocols of an en-gNB, controlling the operation of one or more gNB-DUs. gNB-CU 196 terminates the F1 interface connected to gNB-DU 195. The F1 interface is shown as reference numeral 198, although reference numeral 198 also shows the link between remote elements of RAN node 170 and centralized elements of RAN node 170, such as between gNB-CU 196 and gNB-DU 195. gNB-DU 195 is a logical node that hosts the RLC, MAC, and PHY layers of a gNB or en-gNB, and its operation is partially controlled by gNB-CU 196. A gNB-CU 196 supports one or more cells. A cell can be supported by one gNB-DU 195, or a cell can be supported / shared by multiple DUs under RAN sharing. The gNB-DU 195 terminates the F1 interface 198 connected to the gNB-CU 196. Note that the DU 195 is considered to include transceiver 160, for example, as part of an RU; however, some examples may have transceiver 160 as part of a separate RU, for example, under the control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolved NodeB) base station for LTE (Long Term Evolution) or any other suitable base station or node.

[0022] RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / WI / F) 161, and one or more transceivers 160 interconnected via 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. CU 196 may include processor 152, one or more memories 155, and network interfaces 161. Note that DU 195 may also contain its own memory and processor and / or other hardware, but these are not shown.

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

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

[0025] 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, optical fiber or other optical communication equipment, wireless channels, etc. For example, one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for a gNB implementation of 5G, wherein other elements of the RAN node 170 may be physically located differently from the RRH / DU 195, and one or more buses 157 may be partially implemented as, for example, fiber optic cables or other suitable network connections to connect other elements of the RAN node 170 (e.g., centralized unit (CU), gNB-CU 196) to the RRH / DU 195. Reference numeral 198 also indicates those suitable network links.

[0026] A RAN node / gNB may include one or more Transmitter Receiver Points (TRPs) to which the methods described herein may be applied. Figure 1 In addition to the TRP represented by transceiver 160, RAN node 170 also includes TRP 51 and TRP 52. Similar to transceiver 160, TRP 51 and TRP 52 may each include a transmitter and a receiver. RAN node 170 may host or include... Figure 1 Other TRPs not shown in the diagram.

[0027] In NR, relay nodes are called Integrated Access and Backhaul (IAB) nodes. The mobile terminal portion of an IAB node facilitates backhaul (parent link) connections. In other words, the mobile terminal portion includes the functionality carrying the UE's capabilities. The distribution unit portion of an IAB node facilitates so-called access link (sub-link) connections (i.e., for the UE in the case of multi-hop IAB, for the access link, and for the backhaul of other IAB nodes). In other words, the distribution unit portion is responsible for certain base station functions. IAB scenarios can follow a so-called split architecture, where the centralized unit hosts higher-layer protocols to the UE and terminates at the control plane and user plane interfaces of the 5G core network.

[0028] It should be noted that the description in this document indicates that a "cell" performs a function, but it should be clear that the equipment forming the cell can perform the stated function. A cell constitutes part of a base station. That is, each base station can have multiple cells. For example, for a single carrier frequency and associated bandwidth, there can be three cells, each covering one-third of a 360-degree area, such that the coverage area of ​​a single base station is approximately elliptical or circular. Furthermore, each cell can correspond to a single carrier, and a base station can use multiple carriers. Therefore, if each carrier has three 120-degree cells and two carriers, the base station has a total of six cells.

[0029] Wireless network 100 may include one or more network elements 190, which may include core network functions and provide connectivity to another network (such as a telephone network and / or a data communication network (e.g., the Internet)) via one or more links 181. Such core network functions for 5G may include (multiple) Location Management Functions (LMF) and / or (multiple) Access and Mobility Management Functions (AMF) and / or (multiple) User Plane Functions (UPF) and / or (multiple) Session Management Functions (SMF). Such core network functions for LTE may include MME (Mobility Management Entity) / SGW (Serving Gateway) functions. Such core network functions may include SON (Self-Organizing / Optimizing Network) functions. These are merely example functions that can be supported by network element 190, and note that both 5G and LTE functions can be supported. RAN node 170 is coupled to network element 190 via link 131. Link 131 may be implemented as, for example, an NG interface for 5G, or an S1 interface for LTE, or other suitable interfaces for other standards. Network element 190 includes one or more processors 175 interconnected via one or more buses 185, one or more memories 171, and one or more network interfaces (N / WI / F) 180. The one or more memories 171 include computer program code 173. The computer program code 173 may include SON and / or MRO functions 172.

[0030] Wireless network 100 can implement network virtualization, which is the process of combining hardware and software network resources and network functions into a single software-based management entity or virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is classified as external, combining many networks or parts of networks into virtual units, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities created by network virtualization are still implemented to some extent using hardware such as processors 152 or 175 and memories 155 and 171, and such virtualized entities also produce technical effects.

[0031] Computer-readable storage devices 125, 155, and 171 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic storage devices and systems, optical storage devices and systems, non-transitory memory, temporary memory, fixed memory, and removable memory. Computer-readable storage devices 125, 155, and 171 can be means for performing storage functions. As a non-limiting example, processors 120, 152, and 175 can be of any type suitable for the local technical environment and can include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Processors 120, 152, and 175 can be components for performing functions such as controlling UE 110, RAN node 170, network element 190, and other functions as described herein.

[0032] Typically, various example embodiments of user equipment 110 may include, but are not limited to, cellular phones such as smartphones, tablet computers, personal digital assistants (PDAs) with wireless communication capabilities, portable computers with wireless communication capabilities, image capture devices such as digital cameras with wireless communication capabilities, gaming devices with wireless communication capabilities, music storage and playback devices with wireless communication capabilities, internet devices including internet devices that allow wireless internet access and browsing, tablet computers with wireless communication capabilities, head-mounted displays such as those implementing virtual / augmented / mixed reality, and portable units or terminals incorporating combinations of these functions. UE 110 may also be a vehicle such as an automobile, or a UE installed in a vehicle, a UAV such as a drone, or a UE installed in a UAV. User equipment 110 may be a terminal device, such as a mobile phone, mobile device, sensor device, etc., which is a device used by the user or a device not used by the user.

[0033] UE 110, RAN node 170, and / or network element 190 (and associated memory, computer program code, and modules) can be configured to (e.g., partially) implement the methods described herein. Therefore, UE 110's Figure 1 The computer program code 123, module 140-1, module 140-2, and other elements / features shown herein can implement the user equipment-related aspects of the examples described herein. Similarly, RAN node 170's... Figure 1 The computer program code 153, module 150-1, module 150-2, and other elements / features shown herein can implement the gNB / TRP-related aspects of the examples described herein. (Multiple) network elements 190 Figure 1The computer program code 173 and other elements / features shown can be configured to implement the network element-related aspects of the examples described herein.

[0034] Therefore, a suitable but non-limiting technical context for practicing the exemplary embodiments has been introduced, and the exemplary embodiments are now described in more detail.

[0035] As specified in IETF RFC 9449, Proof of Ownership (DPoP) is a technique for cryptographically binding an access token to a specific client when it is issued. It requires the application to use the token to prove ownership of the same private key used to obtain the token. The DPoP proof is a signature on some data of an HTTP request, appended with a timestamp, a unique identifier, an optional server-provided random number, and a hash of the associated access token, when the access token exists within the request. The detection mechanism proposed in this RFC is not available to the inventors' best knowledge within the 3GPP standard. The solution described in this paper extends the DPoP proposal mentioned in IETF RFC 9449 (and the concept in RFC 8705) for use indirect communication scenarios.

[0036] IETF RFC 8705 addresses the binding of OAuth 2.0 access tokens to TLS certificate issuance. For the purpose of sender-bound access tokens, the (OAuth 2.0) client identifies itself to the (OAuth 2.0) resource server via a thumbprint of its TLS EE certificate public key. During the processing of the access token request, the (OAuth 2.0) authorization server (from the TLS stack) obtains the (OAuth 2.0) client's TLS EE certificate public key and associates its thumbprint with the corresponding access token. The (OAuth 2.0) resource server obtains its TLS EE certificate public key from the TLS stack in the same manner and compares its thumbprint with the thumbprint associated with the access token.

[0037] IETF RFC 8705 addresses only direct communication (i.e., for both client authorization server and client resource server links) because it relies on mTLS and does not address all the challenges of indirect communication via generic HTTP / 2 proxies, HTTP / 2 load balancers, or L7 Web Application and API Protection (WAAP) services, or especially all the challenges of indirect communication in 3GPP 5GCSBA via SCP (i.e., models C and D).

[0038] IETF RFC 8705 assumes that the same TLS profile with the same TLS EE client certificate is used between the (OAuth 2.0) client and the (OAuth 2.0) authorization server, and between the (OAuth 2.0) client and the (OAuth 2.0) resource server. Furthermore, the CCA token is used in OAuth 2.0 with 5GC SBA, where the X.509 public key certificate associated with the CCA token signing (with JWS) can be signed by a different subCA than the one used to sign the TLS EE certificate.

[0039] Mitigation of access token theft attacks in direct and indirect communication within service-based architectures addresses the problem of binding access tokens to NFc public keys for direct communication only. However, this does not solve the problem at SCPs. The method described in this paper addresses indirect communication scenarios, i.e., when SCPs are involved.

[0040] Problem: In indirect communication, access tokens cached by the NFc after being received from the SCP may be stolen. Access tokens can also be stolen from the NFp (i.e., when it is used but is valid for more than one use at that NFp, e.g., leaked from the NFp) or from the NRF that issued the token to the SCP (e.g., by an insider).

[0041] In indirect scenarios, how can we prevent stolen / accidentally shared access tokens from being reused (illegally) by other network functions (NFc) to consume services from another NF that has obtained the access token? How can we provide proof for the NFp in this situation, i.e., that it is not due to a direct connection to the NFc without mTLS? In the current 3GPP specifications, particularly in the parsed 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. Furthermore, there is no binding between the CCA token (self-signed by NFc; used for NFc authentication) and the access token (signed by NRF). Therefore, if an NFc is granted... A Consumer Producer NF C The service access token was leaked to another network function NF with a valid certificate. B Then NF B You can consume NF C The service, even if it is not authorized to do so.

[0042] Currently, 3GPP's approach to this problem relies on good implementations that do not allow access token leakage and prevent what can be called the token reply problem. That is, 3GPP makes the assumption that the SCP is trusted and that mTLS exists between SCPs.

[0043] Therefore, the theft and misuse of access tokens are possible; that is, when the SCP shares a token with an NFc for caching, the NFc can reuse the token in further communications. If the access token is leaked to another NFc' and the NFc' reuses the token, no one has the option to verify whether the token is authorized for use by the NFc'.

[0044] In addition, there may be scenarios where the access token is leaked and used by another NF producer other than the one that originally generated the access token for it.

[0045] For several reasons (1-5), the currently specified RFC 8705 does not address the following issues in 5G SBA: 1. Indirect communication for 5GC SBA, introduced in 3GPP Release 16. Communication between NFc and NFp is accomplished via one or more SCPs (Service Communication Brokers). Therefore, TLS mutual authentication is performed between NFs and between SCPs (and between NFs and NRFs with Model C), rather than between NFs. Furthermore, NF consumers (and NF producers) can use different TLS profiles directed to NRF and SCPc (and SCPp) nodes (e.g., inter-SCP routing), where NF consumers acting as TLS clients can also support X.509 certificate rotation. 2. The 3GPP-specified CCA (Client Credential Assertion) token solution enables client authentication in indirect communication-based deployments (with Models C and D). RFC 8705 does not cover this feature. 3. 5G SBA uses HTTP / 2 and is avoided according to RFC 9113 "TLS 1.3 Post-Handshake Authentication". 4. In 3GPP 5GC SBA, the JWT access token is self-contained, and therefore the NF producer (as a "protected resource" in the RFC 8705 terminology) does not integrate with the NRF acting as an "authorization server" to determine the state of the access token, nor does it obtain any metadata about the access token (granted by the NRF) through introspection or similar means. 5. In 3GPP 5GC SBA, the NRF acting as an "authorization server" does not support / utilize the dynamic client registration protocol (defined in RFC 7591) to obtain client metadata for NF consumers, nor does it support dynamically registering OAuth 2.0 client metadata with the "authorization server".

[0046] For several reasons (1-6), the currently specified RFC 9449 does not address the issues in 5G SBA: 1. (See the reasons given for RFC 8705). 2. The OAuth 2.0 authorization framework for 3GPP 5GC SBA uses client credentials authorization in access token requests, while RFC 9449 uses authorization types (e.g., authorization codes or refresh tokens). 3. RFC 9449 defines the primary use case for DPoP according to RFC 9449 as being for public clients that do not use client authentication (e.g., single-page applications and applications on user devices). 4. The 3GPP-specified CCA (Client Credential Assertion) token solution enables client authentication in deployments based on indirect communication (with models C and D). The DPoP mechanism in RFC 9449 does not imply client authentication as described in Clause 3 of RFC 9449. 5. RFC 9449 introduces new DPoP HTTP headers (i.e., containing DPoP proof JWT type) and DPoP-Nonce HTTP headers not used in 3GPP 5GC SBA. 6. In 3GPP 5GC SBA, the NRF acting as the "Authorization Server" does not support / utilize the Dynamic Client Registration Protocol (defined in RFC 7591) to obtain or register client metadata for NF consumers (i.e., supports dynamic registration of OAuth 2.0 client metadata to the "Authorization Server").

[0047] Furthermore, 3GPP TS 33.501 and TS 29.510 define the optional use of specific JWT access tokens for accessing Nnrf services (e.g., Nnrf service API scopes with Nnrf_NFManagement and Nnrf_NFDiscovery services for NFs; including SCPs). The same solution can also be reused for Nnrf service authorization purposes; however, here (OAuth2.0) the resource server is an NRF (i.e., this can be different from the NRF that grants JWT access tokens to the target NF producer).

[0048] CCA tokens (i.e., delivered in the "3gpp-Sbi-Client-Credentials" HTTP custom header) are therefore standardized only in 3GPP 5GC SBA and used for NF consumer authentication, not for (service) authorization, and therefore cannot solve the problem of JWT access token theft.

[0049] In indirect communication, the NFc requests the service via the SCP, and optionally adds its CCA for authentication. The SCP authenticates the NFc during mTLS using the presented NFc certificate and requests an access token on behalf of the NFc.

[0050] The idea described in this article is to use the concept of proof of ownership (which may be called DPoP) through which an NRF acting as an authorization server can create a JWT access token that is guaranteed to be bound to a legitimate NFC and cannot be used by any other NFC.

[0051] The examples described in this article specifically involve the following enhancements: enhanced DPoP in CCA and its SCP for verification to prevent access token theft, and enhanced DPoP that covers all certificates / issuance keys.

[0052] The proposal suggests including one or more DPoPs in the NFc CCA (generated by NFc) and the JWT access token generated for NFc (generated by NRF). The proof of ownership (DPoP) can be accomplished via an mTLS public key or a hash of an mTLS public key or certificate.

[0053] If different TLS profiles with different TLS EE client certificates are used for NRF and SCPc, multiple DpoPs are required.

[0054] The process is as follows: NFc generates a DPoP with an NFc public key certificate and a thumbprint (i.e., including the public key). NFc uses the same public key certificate for this as the mTLS setup.

[0055] NFc adds one or more DPoPs to its self-generated CCA token. When multiple TLS EE certificates are provided for NFc, NFc can include multiple DPoPs (or a set of DPoPs).

[0056] SCP forwards NFC details (DPoP, Public Key Certificate) in the access token request.

[0057] NRF receives DPoP (Model D) from SCP.

[0058] The NRF verifies the DPoP and generates a JWT access token that includes the received DPoP, which is then provided to the SCP.

[0059] JWT access tokens are constrained by the sender by adding DPoP.

[0060] The SCP is requesting services with the received access token (including (multiple) DPoPs) at NFp (representing NFc).

[0061] NFp verifies the DPoP information in the JWT access token.

[0062] NFp provides services to NFc via SCP; if subsequent requests with the same access token are permitted, SCP also provides NFc with an access token that includes DPoP to NFc.

[0063] NFc can cache and reuse access tokens, including DPoPs, for subsequent requests (DPoPs) to NFp via SCP. SCP verifies DPoP and ensures that access tokens are not stolen.

[0064] Later, if the same access token granted to NFc (and not to NFc') is used by an unauthorized NFc', and the unauthorized NFc' transmits NFc's access token and CCA token to the SCP along with a service request, the SCP proceeds as follows (1-2): 1. The SCP verifies whether the access token truly belongs to NFc' by matching the DPoP of the CCA with the DPoP of the access token. If they match, the SCP allows the request. Otherwise, the SCP rejects the request. 2. Alternatively, the SCP notifies that the token has been discarded and requests a new token.

[0065] Another scenario is if NFc' also adds a stolen CCA token to NFc. In this case, the SCP must reject the request because the DPoP in the CCA token does not match the TLS EE client certificate of that NFc'.

[0066] The NFc TLS EE client certificate public key and any additional DPoP are bound to the JWT access token.

[0067] NFp also includes a CCA token containing DPoP information to verify the JWT access token (i.e., NFc, TLS EE client certificate public key, etc.), and only then will it provide the requested service. Both the CCA token and the access token are sender-bound.

[0068] By verifying the JWT access token, it is ensured that it has not been stolen or abused, thus confirming that it is a legitimate NF consumer for the transmission request.

[0069] The CCA token supports the following parameters, making the CCA token include (1-4): 1. The NF instance ID of the NF service consumer (principal); 2. The timestamp (iat) and expiration time (exp); 3. The NF type of the intended audience (audience), i.e., the type "NRF" and / or NF type of the NF service producer. When using model D, both the "NRF" and NF type of the target NF service producer are included in the intended audience; and 4. It can include one or more "DPoP ((multiple) proofs)" (e.g., an mTLS public key or a hash of an mTLS public key or certificate), depending on whether different TLS profiles with different TLS EE client certificates are used for NRF and SCPc.

[0070] NF service consumers digitally sign the generated CCA token based on their private key, as described in RFC 7515

[45] . The signed CCA token shall include one of the following fields (1-2): 1. X.509 URL (x5u), which refers to the resource of the X.509 public key certificate or certificate chain used to sign the client credential assertion token, or 2. X.509 certificate chain (x5c), which includes the X.509 public key certificate or certificate chain used to sign the client credential assertion token.

[0071] Figure 2 This is a diagram illustrating the signaling exchange between NFc-1 210, SCP1 220, NFp 230 and the authorization server 240 (e.g., NRF).

[0072] A (200-a). NF (Consumer and Producer) Profile Registration.

[0073] If separate TLS profiles with different TLS EE client certificates are used for both the NRF and SCPc, the NFc 210 also registers its public key (or a hash or thumbprint of the public key) or multiple public keys during profile registration (200-A) at the NRF240 (or OAM). Since profile registration should occur via mTLS (not mandatory), the NRF 240 can have one or more public keys from the corresponding TLS certificates. In cases where (multiple) AS-NRFs use different private and public key pairs to sign JWT access tokens, the JWT access token signature exists in mTLS and can also be updated at the NRF as part of the NF profile registration.

[0074] If this information is not available at NRF 240, it can use the NFc NF instance ID information to request (out-of-band) the corresponding information from OAM.

[0075] Assume that in the future all NFs (both consumers and producers) will register at NRF 240.

[0076] A1 (200-A1): Assume mutual authentication (mTLS) between all hops.

[0077] B (200-B1, 200-B2, 200-B3). Access token requests from NFc 210 and SCP 220 to NRF 240.

[0078] When the initial NNF service request is sent at 200-B1, NFc 210 also includes its CCA token and (multiple) DPoPs. In the case of both Model C and Model D, the initial NNF service request includes a CCA token (with a specific audience claim depending on whether Model C or D is applied).

[0079] Even though the CCA token is short-lived, the following process remains valid even if the CCA token is stolen: When SCP 220 receives an access token request from NFc 210 (in Model C) or receives an initial NNF service request and then generates an access token request 200-B3 accordingly (in Model D only), SCP 220 first verifies at 200-B2 whether the CCA token is indeed signed and belongs to NFc 210 of the transmission message 200-B1.

[0080] In Model C, NFc has a direct connection to NRF, so access token requests are not routed through SCP. In Model C, the initial service request includes both a CCA token and an access token. If SCPc uses Model C and NFc does not include an access token, then SCPc does not request a new access token from NRF, but instead returns an error response to NFc.

[0081] Because SCPc has direct mTLS with NFc, it can verify that the public key present in the TLS EE client certificate of the HTTPS connection is the same as the public key present in the CCA token (or, if multiple, can be found). In cases where different keys are used for TLS and CCA token signing, SCP 220 verifies that the NF instance ID and NF type information present in the TLS certificate information are the same as those present in the CCA token. Only after successful verification does SCP 220 forward the access token request to the NRF at 200-B3 (Model C), or generate an access token request (Model D) and transmit it to NRF 240, in some examples including the public key information of NFc 210 in the access token request 200-B3. Typically, all DPoP information is only included in the CCA token passed to the NRF along with the access token request.

[0082] C (200-C1, 200-C2). NRF access token generation and ownership proof verification.

[0083] When NRF 240 receives Access Token Request 200-B3 and the CCA token of NFc 210, it performs the verification described in Clause 13.3.8 of TS 33.501 and verifies that the public key present in the CCA token indeed belongs to NFc 210 whose NF instance ID exists in Access Token Request 200-B3 (using NF profile registration information). Then, at 200-C1, NRF 240 appends DPoP information, i.e., the public key present in the CCA token in the Access Token Claim. Alternatively, at 200-C1, NRF 240 may also add a signature hash of the public key or NFc certificate thumbprint or other "DPoP (proof)" information (e.g., one or more hashes of the public key or certificate thumbprint, depending on the use of a shared / private TLS profile relative to SCPc for the HTTPS connection with NRF) to the JWT Access Token.

[0084] If NFc 210 uses different certificates for the CCA token and mTLS, the CCA token may contain an additional public key / certificate for mTLS (or hash), and NRF 240 should also include the same key / certificate in AT1.

[0085] Even if the NF service consumer will not register with the NRF, the CCA token generated by the NFc including DPoP is used as proof of processing of the private key, and the corresponding public key in DPoP is added by NRF 240 (at 200-C1) in the access token.

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

[0087] D (200-D1, 200-D2, 200-D3, 200-D4). The service request is sent to NF service producer 230.

[0088] Upon receiving the request 200-D1 and the CCA token (including DPoP) from NFc 210, NF service producer 230 can verify at 200-D2 whether the public key present in the access token is the same as the public key in the CCA token. If the verification is successful, the service is provided.

[0089] Subsequently (D.3), that is, providing services at 200-D3 and transferring service responses from NFp 230 to SCP 220 at 200-D3, at 200-D4, SCP 220 provides tokens to NFc 210 for caching, so that NFc 210 can reuse cached tokens (in D.4).

[0090] E (200-E1, 200-E2, 200-E3). Once NFc 210 provides the token again in further communications (at 200-E1), SCP 220 needs to authenticate and authorize NFc 210 and verify that its access token has not been stolen (at 200-E2 and 200-E3). To do this, SCP 220 will check (i-iii): i. Does the access token contain (multiple) DPoPs? If not, the SCP will discard the access token.

[0091] ii. If the access token contains DPoP(multiple), the SCP shall verify the information in DPoP(multiple), such as whether the hash of the public key / certificate matches the hash of the public key / certificate present in the NFc certificate provided via mTLS or CCA token (at 200-E2).

[0092] iii. If they match, the SCP reuses the token provided by the NFc. If it does not match (in 200-E1), SCP 220 determines that the token was not used by the NFc but by NFc' and discards the request.

[0093] Figure 2 The call flow and signaling diagram are shown in part based on Model D, in which SCP 220 transmits an access token request 200-B3 to the authorization server 240, and the authorization server transmits an access token response 200-C2 to SCP 220. Figure 2 This also applies to Model C, where an access token request 270 with CCA 272 has DPoP 274, and an access token response 280 with AT 282 has 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 an access token (e.g., at 270) before sending an initial service request to SCP 220 at 200-B1 (such as transmitting messages 270 and 280 before message 200-B1), and such a call flow order may be a preferred embodiment.

[0094] like Figure 2As shown, 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, or have some of the same information, as determined by NFc 210, SCP 220, NFp 230, and / or Authorization Server 240.

[0095] In Model D, SCP 220 requests an access token, while in Model C, NFc 210 requests an access token directly from Authorization Server 240 instead of via SCP 220. In Model D, the access token displaying proof of ownership is an access token granted by NRF 240, which acts as the Authorization Server. The DPoP, containing a CCA token from NFc 210, is a DPoP received via SCP 220.

[0096] In Model C (using a direct mTLS connection with NFc 210), the NRF, acting as the authentication server 240, needs to verify that the DPoP (one of one) in the client credential assertion token, which includes one or more DPoPs, matches the actual TLS EE client certificate of NFc 210 before granting an access token that displays proof of ownership.

[0097] Therefore, in Model D, only the CCA token with DPoP is sent to SCPc in the initial NNF request. In Model C, NFc requests the token directly from NRF, which acts as the authorization server, and uses a different CCA token for this purpose compared to the service request via SCPc. Therefore, in Model C, where one or more TLS profiles used by NFc for NRF differ from one or more TLS profiles used by NFc for SCPc, and / or where one or more TLS EE certificates used by NFc for NRF differ from one or more TLS EE certificates used by NFc for SCPc, the set of DPoPs in the CCA token to NRF also includes the DPoP for NFc to SCPc.

[0098] In summary, the Client Credential Assertion (CCA) is a token signed by the NF service consumer 210. The CCA token enables the NF service consumer 210 to authenticate with the receiving endpoint (e.g., NRF 240 or NF service producer 230) by including the signed CCA token in the service request. The CCA token includes the NF service consumer's NF instance ID and a proof of ownership (e.g., an mTLS public key) (DPoP), which can be checked against the NF service consumer's certificate by the NF service producer 230 (in Model B) or by the SCP 220 (in Models C and D). The CCA includes one or more DPoPs ((multiple) proofs) that allow the NRF to link the 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.

[0099] The verification of the CCA will be performed by the receiving node (i.e., the NRF, SCPc, or NF service producer), such that the receiving node verifies that the NF instance ID of at least one of the NFc and DPoP in the CCA matches the NF instance ID in the public key certificate used to sign the CCA (i.e., the NF instance ID in the URI-ID). If the receiving node is an SCPc, the SCPc verifies that the NFc TLS EE client certificate information (e.g., thumbprint or public key) matches one of the DPoPs in the CCA, and that the NF instance ID of the NFc in the CCA matches the NF instance ID in the NFc TLS EE client certificate (i.e., the NF instance ID in the URI-ID).

[0100] The advantages and technical benefits of the solution described in this paper include mitigating the reuse of access tokens by unauthorized NF consumers, taking into account the threat of service producers providing services to unauthorized NFs. The solution described in this paper stipulates that access tokens are used only by legitimate NFs.

[0101] One key difference is that, using the solution described in this paper for DPoP or a set of DPoPs, the client and resource server can communicate indirectly via an "HTTPS proxy" (in this case, an SCP). This "HTTPS proxy" can also be an HTTPS LB / L7 Web Application and API Protection (WAAP) service (which is essentially impossible for an RFC8705 / RFC9449-based setup that always implements direct mTLS between the client and resource server). Furthermore, the client has the same TLS profile for both the authorization server and the resource server, meaning the same TLS EE client certificate is used for both mTLS connections.

[0102] Further implementation details: Here, "public key" can refer to a public key present in a TLS EE / X.509 certificate, or a cryptographic (SHA256) hash of a public key certificate (e.g., a digest / thumbprint / thumbprint of an X.509 certificate); for the different options covered by the examples described herein, refer to the table below (however, other options may appear later but require this protection); for example, the table below summarizes a set of different implementation alternatives for JWT access tokens and CCA tokens used to create sender constraints, where "DPoP" (proof) refers to the identity information about the sender constraint included in the CCA token (signed by the NF consumer) and / or the JWT access token (granted by the NRF and signed as an OAuth 2.0 authorization server) (and a demonstration of the associated private key held by the NF consumer).

[0103] Here, "DPoP" (proof) does not specifically refer to RFC 9449 (concept); however, some similarities may arise. It is proposed here to include "DPoP" (proof) in both the CCA token and the JWT access token within separate custom declarations. The "x5t#S256" (X.509 certificate SHA-256 thumbprint header parameter) defined in IETF RFC 7515, the "cnf" verification method declaration with the "x5t#S256" member defined in RFC 8705, or the "cnf" verification method declaration with the "jkt" JWK thumbprint verification method member defined in RFC 9449 cannot be used alone for this purpose.

[0104] Note: The “x5t” (X.509 certificate SHA-1 thumbprint header parameter) defined in IETF RFC 7515 has been deprecated due to well-known security issues with SHA-1, such as SHA-1 collisions.

[0105] Note: Self-signed CCA tokens with “x5u” / “x5c” header parameters from an NFc using an X.509 certificate signed by a (sub)CA for the CCA token signing key (JWS) may be easily used for identity theft by a (forged) victim NFc. In this case, a fraudulent / malicious NFc can replace the victim’s “x5u” / “x5c” header parameters with a forged (e.g., self-signed X.509 certificate) one and then create a new digital signature for the CCA token used, unless the NRF / NFp (or SCPc) also verifies the trust path of the requester NFc’s identity (in the subject statement) in the CCA token signing X.509 certificate.

[0106] Explanation of multipurpose certificates / single-purpose certificates: Note: Multipurpose X.509 PKI certificates can be used in NF (and in X.509 PKI certificate verification), as indicated by keyUsage and extendedKeyUsage in the X.509 PKI certificate, such as (i-iii): i) TLS EE guest Client / Server Certificates (For mTLS), which has "KU:digitalSignature" and "EKU:id-kp-client-auth" / "EKU:id-kp-server-auth" (allowed NF types in X.509 certificates: including all NFs, NRF, SEPP, SCP) and / or ii) OAuth 2.0 with JWT access token (That is, here used for JWS signing keys with AS-NRF), which have “KU: digitalSignature” (or “KU: nonrepudiation”) and (optionally) “EKU: id-kp-oauthAccessTokenSigning” (allowed NF type: NRF in X.509 certificates); and / or iii) With CCA token OAuth 2.0 (This is used here for CCA token signing keys with NF consumers), which has "KU: digitalSignature" (or "KU: nonrepudiation") and (optionally) "EKU: id-kp-jwt" (allowed NF types in X.509 certificates: all NF consumers).

[0107] A multipurpose X.509 PKI certificate is required for AS-NRF (i.e., with mTLS and JWT access tokens); however, a multipurpose X.509 PKI certificate is not required for NF producers (i.e., unless those are also NF consumers and therefore need to support CCA tokens), SCPs (with model C / D), SEPPs, or NRF nodes without an OAuth 2.0 AS role (i.e., if those are not AS-NRFs with an OAuth 2.0 authorization server role).

[0108] Single or multipurpose X.509 PKI certificates with “anyExtendedPurpose” for EKU are currently not recommended for use with JWS token signing for JWT access tokens or CCA tokens.

[0109] In cases where a single-purpose or multi-purpose X.509 PKI certificate is manually (via OAM) distributed to the NF producer, the KU+EKU verification of the JWT access token during JWS signature verification can be skipped according to local policies.

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

[0111] In the table, different scenarios are sketched as implementation details to illustrate the ideas described in this article.

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

[0113]

[0114] The method described in this paper addresses a problem in a single PLMN (i.e., an in-domain SBA and non-roaming scenario) where the public key of an NF service consumer can be obtained via a CCA token used in indirect communication.

[0115] The NRF uses the public key provided by the NF consumer (via the “x5u” or “x5c” header parameter) to verify the CCA token signature, and also verifies the presence of a “DPoP (proof)” (e.g., one or more public keys / thumb fingerprints) in the CCA token in a previously registered NF profile (see note).

[0116] In some examples, it is assumed that all NFs (i.e., both NF consumers and NF producers) within the SBA of the domain must be registered with the NRF (or any other repository). This is also one of the most important prerequisites for NF consumers (models B and C) or SCPc (model D) requesting JWT access tokens. For model D, the SCPc does not or does not need to check whether the NF consumer has already registered with the NRF.

[0117] This (public key) information is available during NF registration (current NF producer registration is only via direct communication, i.e., in principle using mutual TLS), or it can be obtained from out-of-band OAM using the NF instance ID of the NFc present in the CCA token.

[0118] Once verified, the NRF adds the NFc's TLS EE client certificate public key and / or other "DPoP (proof)" information (e.g., one or more hashes of the public key or certificate thumbprint, depending on the use of the SCPc in the shared / private TLS profile for the HTTPS connection with the NRF) to the generated JWT access token (i.e., as "DPoP (proof)" (multiple) materials) and binds the JWT access token in such a way that only an NFc that provides processing proof of the corresponding TLS EE client certificate private key can use the JWT access token.

[0119] During the processing of an NNF service request initiated by an NFc via one or more SCPs to NFp (along with a CCA token), NFp verifies details such as the JWS signature and whether the "DPoP (proof of identity)" (e.g., one or more public keys / thumbprints) present in the JWT access token matches one / one thumbprint (if multiple appended) present in the CCA token (see note below). NFp only provides NNF service to the requesting NFc if the verification is successful (i.e., verifying the public key present in the access token claim against the CCA token).

[0120] For different combinations of “DPoP (proof)” materials covered in the CCA token and the (authorized) JWT access token, please refer to the table above.

[0121] Subsequently, SCPc provides the JWT access token to NFc for caching, allowing NFc to reuse cached JWT access tokens. Once NFc provides the JWT access token again in further communications with the initial / subsequent NFc service requests, SCPc needs to authenticate and authorize NFc and verify that the (re)used access token in the authorization header has not been stolen.

[0122] To this end, the CCA token is enhanced to include the TLS EE client certificate public key from mTLS, because when the NRF is generating the access token claim, it can also add the NFc's TLS EE client certificate public key to the access token claim. Note that the NFc can use different certificates for the CCA token and mTLS (i.e., further, multiple TLS EE client and server certificates for different TLS profiles; additionally, the NFc can use TLS EE client certificate rotation, where the validity period of the shorter-lived TLS EE client certificate is shorter than that of the TLS EE server certificate).

[0123] Therefore, SCPc will For intra-domain SBA Enable the service authorization policy based on "sender-constrained" JWT access tokens, and then check the following (1-4): 1. The NNF service request is for an intra-domain SBA; if the NNF service request is for an intra-domain SBA, proceed with the following checks.

[0124] 2. The NNF service request parameters match the contents of the CCA token and JWT access token transmitted by the NF service consumer (in the authorization header).

[0125] 3. SCP checks whether the received JWT access token is sender-constrained (i.e., whether it contains a hash of (multiple) public keys). 3a) If the JWT access token is not sender-constrained, SCP will discard the JWT access token based on the enabled service authorization policy (i.e., remove the contents of the authorization header) to use only “sender-constrained” JWT access tokens. Depending on the implementation, SCP then requests a new access token in the case of model D (and later returns it to NFc in the service response), or forwards the NFc request without an authorization header in the case of model C, or may even reject the NFc request with an error status. 3b) If the JWT access token is a sender-constrained hash (i.e., containing (multiple) public keys / certificates), the SCP shall verify whether the hash of the public key / certificate matches the hash of the public key / certificate present in the NFC certificate provided via mTLS or CCA token. Then, 3b1) if they match, the SCP keeps the JWT access token unchanged in the authorization header, as provided by the NFC. 3b2) if they do not match, the SCP determines that the JWT access token has been stolen and discards the JWT access token (i.e., removes the contents of the authorization header), and requests a new token from the NRF (Model D) or forwards the NRF request without the authorization header (Model C).

[0126] 4. SCP can notify NFc to delete JWT access tokens, for example, by using a “jti” JWT ID claim (with other necessary contextual information) or by using other methods.

[0127] SCPc applies all of the above checks and mechanisms only when it determines that the Nnf service request is for an intra-PLMN (i.e., non-roaming).

[0128] Figure 3This is an example device 300, which can be implemented in hardware and configured to implement the examples described herein. Device 300 includes at least one processor 302 (e.g., an FPGA and / or a CPU), and one or more memories 304 including computer program code 305 having instructions for performing the methods described herein, wherein at least one memory 304 and computer program code 305 are configured, together with at least one processor 302, to enable device 300 to implement circuits, processes, components, modules, or functions (implemented with control module 306) to implement the examples described herein. Memory 304 may be non-transitory memory, temporary memory, volatile memory (e.g., RAM), or non-volatile memory (e.g., ROM).

[0129] DPoP signaling 330 can implement the example described herein, which involves proof of ownership of the SCP in an indirect communication scenario to allow the access token to be reused only by the legitimate owner.

[0130] Device 300 includes a display and / or I / O interface 308, which includes user interface (UI) circuitry and components that can be used to display aspects or states of the methods described herein (e.g., while performing one of the methods or at a subsequent time), or to receive input from a user, such as using a keyboard, camera, touchscreen, touch area, microphone, biometric identification, one or more sensors, etc. Device 300 includes one or more communication interfaces (I / F) 310, such as network (N / W) interfaces. The communication I / F 310 can be wired and / or wireless and communicates via the Internet / other networks via any communication technology, including via one or more links 324. Link 324 can be from... Figure 1 Links 131 and / or 176. From Figure 1 Links 131 and / or 176 can also be implemented using transceiver 316 and the corresponding wireless link 326. Communication I / F 310 may include one or more transmitters or one or more receivers.

[0131] Transceiver 316 includes one or more transmitters 318 and one or more receivers 320. Transceiver 316 and / or communication I / F 310 may include standard known components such as amplifiers, filters, frequency converters, (de)modulators, and encoder / decoder circuitry, as well as one or more antennas such as antenna 314 for communication via wireless link 326.

[0132] The control module 306 of device 300 includes one or both of portions 306-1 and / or 306-2, which can be implemented in various ways. Control module 306 can be implemented in hardware as control module 306-1, such as as part of one or more processors 302. Control module 306-1 can also be implemented as an integrated circuit or by other hardware such as a programmable gate array. In another example, control module 306 can be implemented as control module 306-2, which is implemented as computer program code (with corresponding instructions) 305 and executed by one or more processors 302. For example, one or more memories 304 store instructions that, when executed by one or more processors 302, cause device 300 to perform one or more operations as described herein. Furthermore, one or more processors 302 encoded as instructions, programs, or code, one or more memories 304, and example algorithms (e.g., as flowcharts and / or signaling diagrams) are components for causing the operations described herein to be performed.

[0133] The device 300 for implementing the function of control 306 may be or correspond to UE 110, RAN node 170 (e.g., gNB), or network element 190 (e.g., AMF 190). Therefore, processor 302 may correspond to processor 120, processor 152, and / or processor 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 310 and / or transceiver 316 may correspond to transceiver 130, antenna 128, transceiver 160, antenna 158, N / WI / F 161, and / or N / WI / F 180. Alternatively, the device 300 and its components may not correspond to any of the UE 110, RAN node 170, or network components(s) 190 and their respective components, as the device 300 may be part of a self-organizing / optimized network (SON) node or other nodes (such as nodes in the cloud).

[0134] Device 300 can also be distributed throughout the network (e.g., 100), including within and between device 300 and any network elements (such as network control element (NCE) 190 and / or RAN node 170 and / or UE 110).

[0135] Device 300 may correspond to any device described herein, including NFc 210, SCP 220, NFp 230, or Authorization Server (NRF) 240.

[0136] Interface 312 enables data communication and signaling between various items of device 300, such as Figure 3 As shown. For example, 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 optic cables, or other optical communication devices. The computer program code (e.g., instructions) 305 including control 306 may include object-oriented software configured to pass data or messages between objects within computer program code 305, or the computer program code (e.g., instructions) including control 306 may include function, script, or procedure code. Device 300 need not include every feature mentioned, or may include other features. Various components of device 300 may reside at least partially in a common housing 328, or a subset of various components of device 300 may reside at least partially in different housings, which may include housing 328.

[0137] Figure 4 A schematic diagram is shown of non-volatile memory media 400a (e.g., a computer / optical disc (CD) or digital multifunction disc (DVD)) and 400b (e.g., a Universal Serial Bus (USB) Memory Stick) and 400c (e.g., cloud storage for downloading instructions and / or parameters 402 or receiving email instructions and / or parameters 402), which, when executed by a processor, allow the processor to perform one or more steps of the methods described herein. Instructions and / or parameters 402 may represent non-transitory computer-readable media.

[0138] Figure 5This is an example method 500 based on the examples described herein. At 510, the method includes receiving a service request for a service from a network function consumer, the service request including a client credential assertion token. At 520, the method includes determining whether the client credential assertion token includes display ownership proof information. At 530, the method includes determining whether, when the client credential assertion token includes display ownership proof information, information associated with a Transport Layer Security (TLS) End Entity (TLSE) client certificate of the network function consumer matches at least a portion of the display ownership proof information of the client credential assertion token. At 540, the method includes determining to process the service request in response to a match between the information associated with the TLSSE End Entity (TLSE) client certificate and at least a portion of the display ownership proof information of the client credential assertion token. At 550, the method includes determining to discard the service request in response to a mismatch between the information associated with the TLSSE End Entity (TLSE) client certificate and at least a portion of the display ownership proof information of the client credential assertion token. Method 500 can be performed using service communication broker 220 or apparatus 300.

[0139] Figure 6 This is an example method 600 based on the examples described herein. At 610, the method includes: transmitting a service request for a service to a service communication agent, the service request including a client credential assertion token including proof of ownership information. At 620, the method includes: receiving a response to the service request for the service from the service communication agent. At 630, the method includes: receiving an access token including proof of ownership information from the service communication agent or an authorization server. Method 600 can be performed using network function consumer 210, device 300, or UE 110.

[0140] Figure 7 This is an example method 700 based on the examples described herein. At 710, the method includes: receiving an access token request from a network function consumer or service communication agent, the access token request including a client credential assertion token, the client credential assertion token including proof of ownership information. At 720, the method includes: transmitting the access token having proof of ownership information to the network function consumer or service communication agent. Method 700 can be performed using an authorization server 240 (e.g., NRF 240) or device 300.

[0141] Figure 8This is an example method 800 based on the examples described herein. At 810, the method includes: receiving a service request from a service communication broker, the service request including: a client credential assertion token displaying ownership proof information, and an access token displaying ownership proof information. At 820, the method includes: transmitting a response to the service request to the service communication broker based on the ownership proof information displayed by the client credential assertion token and the ownership proof information displayed by the access token, the response granting the network function consumer access to a service provided by the device. Method 800 can be performed by network function producer 230 or device 300.

[0142] Figure 9 Model A is shown for the authorization aspect in a direct deployment. At 902, consumer 210 and producer 230 perform authorization based on the NF service producer local authorization policy. At 904, consumer 210 transmits a service request to producer 230. At 906, the producer transmits a service response 906 to consumer 210.

[0143] Figure 10 Model B is shown for the authorization aspect in a direct deployment. At 1002, the consumer transmits a discovery to NRF 240. At 1004, NRF 240 transmits one or more NF profiles to the consumer. At 1006, consumer 210 requests a token from NRF 240. At 1008, NRF 240 authorizes an access token and grants it to the consumer. At 1010, consumer 210 transmits a service request with the access token to producer 230. At 1012, producer 230 transmits a service response to consumer 210.

[0144] Figure 11Model C for the authorization aspect in an indirect deployment is illustrated based on the example described herein. At 1102, consumer 210 transmits discovery to NRF 240. At 1104, NRF 240 transmits one or more NF profiles to consumer 210. At 1106, consumer 210 requests a token from NRF 240, including DPoP 1120 within the request. At 1108, NRF 240 authorizes and grants an access token and DPoP 1122 and transmits it to consumer 210. At 1110, consumer 210 transmits a service request (with an access token and optional CCA) to SCP 220, including DPoP 1124 within the request. At 1112, SCP 220 transmits a response with DPoP 1126 to consumer 210. At 1114, SCP 220 and NRF optionally perform discovery. At 1116, SCP 220 transmits a service request (with an access token and optional CCA) to Producer 230 using DPoP 1128. At 1118, Producer 230 transmits a response to SCP 220 with DPoP 1130. DPoP 1120, DPoP 1122, DPoP 1124, DPoP 1126, DPoP 1128, and DPoP 1130 may include the same information or at least a portion of the same information as determined by Consumer 210, NRF 240, SCP 220, and Producer 230.

[0145] Figure 12Model D for the authorization aspect in an indirect deployment is illustrated based on the example described herein. At 1202, Consumer 210 transmits a service request (including an optional CCA) to SCP 220 using DPoP 1220. At 1204, SCP 220 transmits a response to Consumer 210 using DPoP 1222. At 1206, SCP 220 transmits a discovery to NRF 240. At 1208, NRF 240 transmits one or more NF profiles to SCP 220. At 1210, SCP 220 transmits a request to NRF 240 for a token with DPoP 1224 (with an optional CCA). At 1212, NRF 240 authorizes the token request, grants an access token, and transmits it to SCP 220 with DPoP 1226. At 1214, SCP 220 transmits a service request (with an access token and optional CCA) to Producer 230 via DPoP 1228. At 1216, Producer 230 transmits a response to SCP 220 via DPoP 1230. DPoP 1220, DPoP 1222, DPoP 1224, DPoP 1226, DPoP 1228, and DPoP 1230 may include the same information or at least a portion of the same information as determined by Consumer 210, NRF 240, SCP 220, and Producer 230.

[0146] The following embodiments are provided and described herein.

[0147] Example 1. An apparatus comprising: at least one processor; and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: receive a service request for a service from a network function consumer, the service request including a client credential assertion token; determine whether the client credential assertion token includes display ownership proof information; when the client credential assertion token includes display ownership proof information, determine whether information associated with a transport layer security terminal entity client certificate of the network function consumer matches at least a portion of the display ownership proof information of the client credential assertion token; in response to the information associated with the transport layer security terminal entity client certificate matching at least a portion of the display ownership proof information of the client credential assertion token, determine to process the service request; and in response to the information associated with the transport layer security terminal entity client certificate not matching at least a portion of the display ownership proof information of the client credential assertion token, determine to discard the service request.

[0148] Example 2. The apparatus according to Example 1, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine to discard the service request in response to the client credential assertion token not including proof of ownership information.

[0149] Example 3. An apparatus according to any one of Examples 1 to 2, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether the network function instance identifier of the network function consumer in the client credential assertion token matches the network function instance identifier in the transport layer security terminal entity client certificate of the network function consumer; and in response to a mismatch between the network function instance identifier of the network function consumer in the client credential assertion token and the network function instance identifier in the transport layer security terminal entity client certificate of the network function consumer, determine to discard the service request.

[0150] Example 4. An apparatus according to any one of Examples 1 to 3, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit a response to the network function consumer for the service request for the service in response to the information associated with the Transport Layer Security Terminal Entity Client Certificate matching at least a portion of the presentation of proof information of the Client Credential Assertion Token, wherein the response includes an access token.

[0151] Example 5. The apparatus according to Example 4, wherein the response includes the access token because no access token was received from the network function consumer within the service request.

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

[0153] Example 7. The apparatus according to Example 6, wherein the response includes the access token based on the apparatus requesting the access token due to the exception.

[0154] Example 8. An apparatus according to any one of Examples 1 to 7, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether an access token is received in the service request; in response to not receiving an access token in the service request, transmit an access token request for the access token to an authorization server, the access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and receive the access token having the proof of ownership information from the authorization server.

[0155] Example 9. The apparatus according to Example 8, wherein an access token request is associated with model D, and a service request is associated with model C or model D.

[0156] Example 10. The apparatus according to any one of Examples 8 to 9, wherein the presentation ownership proof information of the access token is the same as the presentation ownership proof information of the client credential assertion token.

[0157] Example 11. The apparatus according to any one of Examples 8 to 10, wherein the presentation ownership proof information of the access token is different from and includes a portion of the presentation ownership proof information of the client credential assertion token.

[0158] Example 12. An apparatus according to any one of Examples 8 to 11, wherein the authorization server includes a network repository function (NRF).

[0159] Example 13. An apparatus according to any one of Examples 8 to 12, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit a producer service request to a network function producer, the producer service request including a client credential assertion token, the client credential assertion token including proof of ownership information, and receiving an access token having the proof of ownership information from the authorization server; and receiving a response to the producer service request from the network function producer based on a match between at least a portion of the proof of ownership information of the client credential assertion token of the producer service request and at least a portion of the proof of ownership information of the access token received from the authorization server, the response granting access to a service provided by the network function producer.

[0160] Example 14. The apparatus according to Example 13, wherein when the public key present in the access token matches the public key present in the client credential assertion token, a response to a request for a producer service is received from the network function producer, the response granting access to the service provided by the network function producer.

[0161] Example 15. The apparatus according to any one of Examples 13 to 14, wherein the client credential assertion token for the producer service request includes an indication of the intended audience, which is at least in part the type of the target network function producer.

[0162] Example 16. An apparatus according to any one of Examples 13 to 15, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit a response to the service request to the network function consumer, the response including an access token displaying ownership verification information, wherein the response indicates that the network function consumer is granted access to the service provided by the network function producer.

[0163] Example 17. The apparatus according to Example 16, wherein the access token displaying proof of ownership information in the response transmitted to the network function consumer is an access token receiving from the authorization server that displays proof of ownership information.

[0164] Example 18. An apparatus according to any one of Examples 8 to 17, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit to the authorization server a subsequent access token request for the new access token, the subsequent access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and receive from the authorization server the new access token having the proof of ownership information.

[0165] Example 19. An apparatus according to any one of Examples 8 to 18, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: receive a follow-up service request for the service from the network function consumer or another network function consumer, the follow-up service request including a client credential assertion token and an access token, the client credential assertion token including display ownership proof information; wherein the follow-up service request for the service follows the service request for the service; and determine the information associated with the transport layer security terminal entity client certificate of the network function consumer or the other network function consumer and the display ownership information of the client credential assertion token of the follow-up service request. The following steps are performed: First, determine whether at least a portion of the proof information matches. Second, in response to a mismatch between the information associated with the client certificate of the Transport Layer Security (TLS) terminal entity and the displayed proof information of the client credential assertion token of the subsequent service request, determine whether to discard the subsequent service request. Third, determine whether the displayed proof information of the client credential assertion token of the subsequent service request matches the displayed proof information of the access token received from the authorization server. Fourth, in response to a mismatch between the displayed proof information of the client credential assertion token of the subsequent service request and the displayed proof information of the access token received from the authorization server, determine whether to discard the subsequent service request.

[0166] Example 20. The apparatus according to Example 19, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine that the other network function consumer is an illegitimate network function consumer in response to determining that the subsequent service request should be discarded.

[0167] Example 21. An apparatus according to any one of Examples 8 to 20, wherein, since at least one first transport layer profile used with the network function consumer for the authorization server is different from at least one second transport layer profile used with the network function consumer for the apparatus, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request received from the network function consumer.

[0168] Example 22. An apparatus according to any one of Examples 8 to 21, wherein, since at least one first transport layer terminal entity certificate used with the network function consumer for the authorization server is different from at least one second transport layer terminal entity certificate used with the network function consumer for the apparatus, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request received from the network function consumer.

[0169] Example 23. The apparatus as described in any one of Examples 1 to 22, wherein the client credential assertion token's presentation of ownership proof information includes at least one or more of the following: one or more mutual transport layer security public keys, or one or more hashes of mutual transport layer security public keys, or one or more mutual transport layer security certificates, or one or more hashes of mutual transport layer security certificates.

[0170] Example 24. An apparatus according to any one of Examples 1 to 23, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether at least a portion of the presentation ownership proof information of the client credential assertion token matches at least a portion of the presentation ownership proof information of the access token received with the service request; determine to process the service request in response to the presentation ownership proof information of the client credential assertion token at least partially matching the presentation ownership proof information of the access token received with the service request; and determine to discard the service request in response to any one of the presentation ownership proof information of the client credential assertion token not matching any one of the presentation ownership proof information of the access token received with the service request.

[0171] Example 25. An apparatus according to any one of Examples 1 to 24, wherein the apparatus includes a service communication agent, or the service communication agent includes the apparatus.

[0172] Example 26. An apparatus comprising: at least one processor; and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: transmit a service request for a service to a service communication agent, the service request including a client credential assertion token, the client credential assertion token including proof of ownership information; receive a response to the service request for the service from the service communication agent; and receive an access token including proof of ownership information from the service communication agent or an authorization server.

[0173] Example 27. The apparatus according to Example 26, wherein the response to a service request received from the service communication agent includes an access token displaying ownership verification information.

[0174] Example 28. The apparatus according to Example 27, wherein the service request is associated with model D.

[0175] Example 29. An apparatus according to any one of Examples 26 to 28, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit to an authorization server an access token request for the access token, the access token request including the client credential assertion token, the client credential assertion token including the proof of ownership information; and receive from the authorization server the access token including the proof of ownership information.

[0176] Example 30. The apparatus according to Example 29, wherein an access token request is associated with model C.

[0177] Example 31. An apparatus according to any one of Examples 29 to 30, wherein: before the apparatus transmits the service request to the service communication proxy, an access token request for the access token is transmitted to the authorization server; and the service request includes both the client credential assertion token displaying ownership proof information and the access token displaying ownership proof information.

[0178] Example 32. An apparatus according to any one of Examples 29 to 31, wherein, since at least one first transport layer profile used with the apparatus for the authorization server is different from at least one second transport layer profile used with the apparatus for the service communication agent, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request transmitted to the service communication agent.

[0179] Example 33. An apparatus according to any one of Examples 29 to 32, wherein, since at least one first transport layer terminal entity certificate used with the apparatus for the authorization server is different from at least one second transport layer terminal entity certificate used with the apparatus for the service communication agent, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request transmitted to the service communication agent.

[0180] Example 34. An apparatus according to any one of Examples 26 to 33, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: transmit a follow-up service request for the service to the service communication proxy, the follow-up service request including: the client credential assertion token having the proof of ownership information, and the access token having the proof of ownership information; wherein the follow-up service request for the service follows the service request for the service.

[0181] Example 35. The apparatus according to Example 34, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive from a service communication agent an instruction to reuse an access token having the presented ownership proof information to access the service when the presented ownership proof information of a client credential assertion token matches the presented ownership proof information of an access token.

[0182] Example 36. The apparatus according to any one of Examples 26 to 35, wherein the presentation ownership proof information of the client credential assertion token and the presentation ownership proof information of the access token include at least one or more of the following: one or more inter-transfer layer security public keys, or one or more hashes of inter-transfer layer security public keys, or one or more inter-transfer layer security certificates, or one or more hashes of inter-transfer layer security certificates.

[0183] Example 37. An apparatus according to any one of Examples 26 to 36, wherein: the apparatus includes a network function consumer, or the network function consumer includes the apparatus, or the apparatus includes a user equipment, or the user equipment includes the apparatus.

[0184] Example 38. An apparatus comprising: at least one processor; and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: receive an access token request from a network function consumer or a service communication agent, the access token request including a client credential assertion token, the client credential assertion token including display ownership proof information; and transmit an access token having the display ownership proof information to the network function consumer or the service communication agent.

[0185] Example 39. The apparatus according to Example 38, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine, using all or part of the presentation ownership proof information in the access token, assert all or part of the presentation ownership proof information in the client credential.

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

[0187] Example 41. An apparatus according to any one of Examples 38 to 40, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether a portion of the display ownership proof information of the client credential assertion token matches information associated with the Transport Layer Security Entity Client Certificate of the Network Function Consumer; wherein, in response to determining that the portion of the display ownership proof information of the client credential assertion token matches the information associated with the Transport Layer Security Entity Client Certificate of the Network Function Consumer, the access token having the display ownership proof information is transmitted to the Network Function Consumer.

[0188] Example 42. The apparatus according to Example 41, wherein the information associated with the transport layer security terminal entity client certificate of the network function consumer includes a network function identifier.

[0189] Example 43. An apparatus according to any one of Examples 38 to 42, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether a portion of the display ownership proof information of the client credential assertion token matches a network function instance identifier in a public key certificate used to sign the client credential assertion token; wherein, in response to determining that the portion of the display ownership proof information of the client credential assertion token matches the network function instance identifier in the public key certificate used to sign the client credential assertion token, the access token having the display ownership proof information is transmitted to the network function consumer.

[0190] Example 44. An apparatus according to any one of Examples 38 to 43, wherein the presentation ownership proof information of the access token is configured to: assert, based on any client credential, match the presentation ownership proof information of the network function consumer with the presentation ownership proof information of the access token to determine whether the network function consumer is granted access to services provided by the network function producer.

[0191] Example 45. The apparatus according to any one of Examples 38 to 44, wherein the proof of ownership of the client credential assertion token and the proof of ownership of the access token include at least one or more of the following: one or more mutual transport layer security public keys, or one or more hashes of mutual transport layer security public keys, or one or more mutual transport layer security certificates, or one or more hashes of mutual transport layer security certificates.

[0192] Example 46. An apparatus according to any one of Examples 38 to 45, wherein the apparatus includes a network repository function (NRF).

[0193] Example 47. An apparatus according to any one of Examples 38 to 46, wherein the apparatus includes an authorization server, or the authorization server includes the apparatus.

[0194] Example 48. An apparatus according to any one of Examples 38 to 47, wherein, since at least one first transport layer profile used with the network function consumer in the apparatus is different from at least one second transport layer profile used with the network function consumer in the service communication agent, the presentation of the client credential assertion token displaying the access token request includes presenting at least a portion of the presentation of the service request associated with the service communication agent.

[0195] Example 49. An apparatus according to any one of Examples 38 to 48, wherein, since at least one first transport layer terminal entity certificate used with the network function consumer in the apparatus is different from at least one second transport layer terminal entity certificate used with the network function consumer in the service communication agent, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request associated with the service communication agent.

[0196] Example 50. An apparatus comprising: at least one processor; and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: receive a service request from a service communication agent, the service request including: a client credential assertion token having proof of ownership information and an access token having proof of ownership information; and, based on the proof of ownership information of the client credential assertion token and the proof of ownership information of the access token, transmit a response to the service communication agent in response to the service request, the response granting a network function consumer access to services provided by the apparatus.

[0197] Example 51. An apparatus according to Example 50, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether at least a portion of the displayed ownership proof information of the client credential assertion token of the service request matches at least a portion of the displayed ownership proof information of the access token; wherein, in response to the match between at least a portion of the displayed ownership proof information of the client credential assertion token of the service request and at least a portion of the displayed ownership proof information of the access token, the apparatus transmits the response to the service communication proxy, the response granting the network function consumer access to the service provided by the apparatus.

[0198] Example 52. An apparatus according to any one of Examples 50 to 51, wherein when the public key present in the access token matches the public key present in the client credential assertion token, the response to the service request is transmitted to the service communication agent, the response granting the network function consumer access to the service provided by the apparatus.

[0199] Example 53. The apparatus according to any one of Examples 50 to 52, wherein the presentation ownership proof information of the client credential assertion token and the presentation ownership proof information of the access token include at least one or more of the following: one or more inter-transfer layer security public keys, or one or more hashes of inter-transfer layer security public keys, or one or more inter-transfer layer security certificates, or one or more hashes of inter-transfer layer security certificates.

[0200] Example 54. An apparatus according to any one of Examples 50 to 53, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: determine whether a portion of the presentation ownership proof information of the client credential assertion token matches a network function instance identifier in a public key certificate used to sign the client credential assertion token; determine to process the service request in response to the portion of the presentation ownership proof information of the client credential assertion token matching the network function instance identifier in the public key certificate used to sign the client credential assertion token; and determine to discard the service request in response to any presentation ownership proof information in the presentation ownership proof information of the client credential assertion token not matching the network function instance identifier in the public key certificate used to sign the client credential assertion token.

[0201] Example 55. An apparatus according to any one of Examples 50 to 54, wherein the apparatus includes a network function producer, or a network function producer includes the apparatus.

[0202] Example 56. A method comprising: receiving a service request for a service from a network function consumer, the service request including a client credential assertion token; determining whether the client credential assertion token includes display ownership information; when the client credential assertion token includes display ownership information, determining whether information associated with a transport layer security endpoint entity client certificate of the network function consumer matches at least a portion of the display ownership information of the client credential assertion token; in response to the information associated with the transport layer security endpoint entity client certificate matching at least a portion of the display ownership information of the client credential assertion token, determining to process the service request; and in response to the information associated with the transport layer security endpoint entity client certificate not matching at least a portion of the display ownership information of the client credential assertion token, determining to discard the service request.

[0203] Example 57. A method comprising: transmitting a service request for a service to a service communication agent, the service request including a client credential assertion token, the client credential assertion token including proof of ownership information; receiving a response to the service request for the service from the service communication agent; and receiving an access token including proof of ownership information from the service communication agent or an authorization server.

[0204] Example 58. A method comprising: receiving an access token request from a network function consumer or a service communication agent, the access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and transmitting an access token having the proof of ownership information to the network function consumer or the service communication agent.

[0205] Example 59. A method comprising: receiving a service request from a service communication agent, the service request including: a client credential assertion token having proof of ownership information and an access token having proof of ownership information; and transmitting a response to the service communication agent based on the proof of ownership information of the client credential assertion token and the proof of ownership information of the access token, the response granting a network function consumer access to a service provided by the device.

[0206] Example 60. An apparatus comprising: components for receiving a service request for a service from a network function consumer, the service request including a client credential assertion token; components for determining whether the client credential assertion token includes display ownership proof information; components for determining, when the client credential assertion token includes display ownership proof information, whether information associated with a transport layer security terminal entity client certificate of the network function consumer matches at least a portion of the display ownership proof information of the client credential assertion token; components for determining to process the service request in response to the information associated with the transport layer security terminal entity client certificate matching at least the portion of the display ownership proof information of the client credential assertion token; and components for determining to discard the service request in response to the information associated with the transport layer security terminal entity client certificate not matching at least the portion of the display ownership proof information of the client credential assertion token.

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

[0208] Example 62. An apparatus comprising: components for receiving an access token request from a network function consumer or a service communication agent, the access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and components for transmitting the access token having the proof of ownership information to the network function consumer or the service communication agent.

[0209] Example 63. An apparatus comprising: components for receiving a service request from a service communication agent, the service request including: a client credential assertion token having ownership proof information and an access token having ownership proof information; and components for transmitting a response to the service communication agent based on the ownership proof information of the client credential assertion token and the ownership proof information of the access token, the response granting a network function consumer access to a service provided by the apparatus.

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

[0211] Example 65. A computer-readable medium comprising instructions stored thereon for at least performing: transmitting a service request for a service to a service communication agent, the service request including a client credential assertion token including proof of ownership information; receiving a response to the service request for the service from the service communication agent; and receiving an access token including proof of ownership information from the service communication agent or an authorization server.

[0212] Example 66. A computer-readable medium including instructions stored thereon for performing at least the following: receiving an access token request from a network function consumer or service communication agent, the access token request including a client credential assertion token, the client credential assertion token including display ownership proof information; and transmitting an access token having the display ownership proof information to the network function consumer or the service communication agent.

[0213] Example 67. A computer-readable medium comprising instructions stored thereon for at least performing the following: receiving a service request from a service communication agent, the service request including: a client credential assertion token having ownership proof information; and an access token having ownership proof information; and transmitting a response to the service communication agent based on the ownership proof information of the client credential assertion token and the ownership proof information of the access token, the response granting a network function consumer access to services provided using the device.

[0214] References to computers, processors, etc., should be understood to encompass not only computers with different architectures (such as single / multiprocessor architectures and sequential or parallel architectures), but also special-purpose circuits, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), signal processing devices, and other processing circuits. References to computer programs, instructions, code, etc., should be understood to encompass software or firmware used with programmable processors, such as the programmable content of hardware devices, whether instructions for processors or configuration settings for fixed-function devices, gate arrays, or programmable logic devices, etc. The memory described herein can 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, transient memory, fixed memory, and removable memory. The memory may include a database for storing data.

[0215] As used herein, the term "circuit" may refer to: (a) a hardware circuit implementation, such as an implementation in analog and / or digital circuitry; and (b) a combination of circuitry and software (and / or firmware), such as (if applicable): (i) a combination of (one or more) processors, or (ii) a portion of (one or more) processors / software, including (one or more) digital signal processors, software, and memory, which work together to enable a device to perform various functions; and (c) circuitry, such as (one or more) microprocessors or portions thereof, which require software or firmware to operate, even if the software or firmware is not physically present. As another example, as used herein, the term "circuit" will also cover implementations of processors (or processors) or portions thereof and their accompanying software and / or firmware. For example, and if applicable to a particular element, the term "circuit" will also cover baseband integrated circuits or application processor integrated circuits for mobile phones, or similar integrated circuits in servers, cellular network devices, or other network devices.

[0216] It should be understood that the foregoing description is illustrative only. Those skilled in the art can devise various alternatives and modifications. For example, the features recited in the various dependent claims and examples can be combined with each other in any suitable combination. Furthermore, features from the different example embodiments described above can be selectively combined to form new example embodiments. Therefore, this specification is intended to cover all such alternatives, modifications, and variations that fall within the scope of the appended claims.

[0217] The following acronyms and abbreviations, which can be found in the instruction manual and / or accompanying drawings, are given below (abbreviations and acronyms may be appended / combined with each other, or with other characters, such as dashes, hyphens, forward slashes, letters or numbers, and may be case-insensitive): 3GPP Third Generation Partnership Project 4G fourth generation 5G fifth generation 5GC 5G Core Network 5GS 5G System AMF access and mobility management functions API Application Programming Interface AS Authorization Server (e.g., AS-NRF) ASIC (Application-Specific Integrated Circuit) AT Access Token CA Certificate Authority CCA Client Credential Assertion CD compression / computer disk CNF confirmed CPU Central Processing Unit CU central unit or centralized unit DPoP demonstrates that it has proof. DSP Digital Signal Processor DU Distributed Unit DVD Digital Multifunction Disc EE terminal entity EKU extended key usage ( eNB evolved Node B (e.g., LTE base station) exp expired EN-DCE-UTRAN New Radio - Dual Connection The en-gNB provides the node for terminating NR user plane and control plane protocols toward the UE and acts as a secondary node in the EN-DC. E-UTRAN evolved UMTS terrestrial radio point access, i.e., LTE radio point access technology E-UTRAE-UTRAN network Interface between F1CU and DU FPGA Field Programmable Gate Array gNB is used as a base station for 5G / NR, that is, a node that provides NR user plane and control plane protocol termination to the UE, and connects to 5GC via the NG interface. Authorization server in hNRFhPLMN hPLMN belongs to the public terrestrial mobile network. HTTP Hypertext Transfer Protocol HTTPS HTTP security IAB Integration Access and Backhaul iat was released at the time. ID identifier IETF Internet Engineering Task Force I / F interface I / O Input / Output jktJSON network key SHA-256 thumbprint JOSEJSON object signing and encryption JSON JavaScript object symbols jtiJWT ID JWSJSON web signature JWTJSON web token Purpose of using the kp key KU key usage L7 floor 7 LB load balancing LMF location management function LTE Long Term Evolution (4G) MAC Media Access Control MME Mobility Management Entity MRO mobility robustness optimization mTLS mutual transport layer security N is an indication of a service-based interface (e.g., Nnrf is a service-based interface for the Network Repository Function (nrf)). NCE Network Control Components NF Network Functions NFcNF serves consumers NFpNF service producers ng or NG next generation ng-eNB next-generation eNB NG-RAN (Next Generation Radio Access Network) NNF service requests for any network function. NR New Radio NRF Network Repository Functionality NW Network N / W network OAM operation and management, or operation, management and maintenance OAuth Open Authorization opt can be used PDA Personal Digital Assistant PDCP Packet Data Convergence Protocol PHY physical layer PKI Public Key Infrastructure PLMN Public Land Mobile Network RAM (Random Access Memory) RAN Radio Access Network Rel version RFC Request for Comments RLC Radio Link Control ROM (Read-Only Memory) RRC Radio Resource Control RU radio unit Rx, RX receiver or receiver, or receiver SBA Service-Based Architecture SBI uses service-based interfaces (e.g., in "3gpp-Sbi-Client-Credentials"). SCP Service Communication Agent SCPc and NF service consumer related service communication agent SCPp and NF service producers' related service communication agents SDAP Service Data Adaptation Protocol SEPP Secure Edge Protection Agent SGW Service Gateway SHA-1 Secure Hash Algorithm 1 SHA256 Secure Hash Algorithm (256-bit) SID Research Project Description SMF Session Management Function SON self-organizing / optimizing network TLS transport layer security TRP transceiver point TS Technical Specification Tx, TX transmission or transmitter or transmission UAV (Unmanned Aerial Vehicle) UE (User Equipment) (e.g., wireless, typically mobile devices) UI User Interface UMTS (Universal Mobile Telecommunication System) UPF User Face Functions URI (Uniform Resource Identifier) URL Uniform Resource Locator USB Universal Serial Bus UTRANUMTS Terrestrial Radio Access Network WAAP web application and API protection X.509 defines the International Telecommunication Union (ITU) standard for public key certificate formats. x5cX.509 certificate chain x5uX.509 URL Network interfaces between X2RAN nodes and between the RAN and the core network (depending on the context) Network interface between XnNG-RAN nodes

Claims

1. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Receive a service request for a service from a network function consumer, the service request including a client credential assertion token; Determine whether the client credential assertion token includes information that demonstrates ownership. When the client credential assertion token includes proof of ownership information, determine whether the information associated with the transport layer security terminal entity client certificate of the network function consumer matches at least a portion of the proof of ownership information of the client credential assertion token; In response to the information associated with the client certificate of the transport layer security terminal entity matching at least a portion of the displayed proof information of the client credential assertion token, it is determined to process the service request; as well as In response to the information associated with the client certificate of the transport layer security terminal entity not matching at least a portion of the proof information displayed on the client credential assertion token, it is determined to discard the service request.

2. The apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: If the client credential assertion token does not include proof of ownership, the service request is discarded.

3. The apparatus according to any one of claims 1 to 2, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether the network function instance identifier of the network function consumer in the client credential assertion token matches the network function instance identifier in the transport layer security terminal entity client certificate of the network function consumer; and In response to the fact that the network function instance identifier of the network function consumer in the client credential assertion token does not match the network function instance identifier in the transport layer security terminal entity client certificate of the network function consumer, it is determined to discard the service request.

4. The apparatus according to any one of claims 1 to 3, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: In response to the information associated with the client certificate of the transport layer security terminal entity matching at least a portion of the displayed proof information of the client credential assertion token, a response to the service request for the service is transmitted to the network function consumer, wherein the response includes an access token.

5. The apparatus of claim 4, wherein the response includes the access token since no access token was received from the network function consumer within the service request.

6. The apparatus according to any one of claims 4 to 5, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Due to an anomaly, the access token is requested.

7. The apparatus of claim 6, wherein the response includes the access token when the apparatus requests the access token due to the anomaly.

8. The apparatus according to any one of claims 1 to 7, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether an access token was received in the service request; In response to the absence of an access token in the service request, an access token request for the access token is transmitted to the authorization server, the access token request including a client credential assertion token, the client credential assertion token including information demonstrating ownership proof; as well as Receive the access token from the authorization server, which displays proof of ownership information.

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

10. The apparatus according to any one of claims 8 to 9, wherein the presentation ownership proof information of the access token is the same as the presentation ownership proof information of the client credential assertion token.

11. The apparatus of any one of claims 8 to 10, wherein the presentation ownership proof information of the access token is different from and includes a portion of the presentation ownership proof information of the client credential assertion token.

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

13. The apparatus according to any one of claims 8 to 12, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: A producer service request is transmitted to a network function producer, the producer service request including a client credential assertion token, the client credential assertion token including proof of ownership information, and the access token having the proof of ownership information is received from the authorization server; and Based on the fact that the client credential assertion token for the producer service request displays at least a portion of the proof information and the access token received from the authorization server displays at least a portion of the proof information, a response to the producer service request is received from the network function producer, the response granting access to the service provided by the network function producer.

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

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

16. The apparatus according to any one of claims 13 to 15, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: A response to the service request is transmitted to the network function consumer, the response including an access token displaying proof of ownership, wherein the response indicates that the network function consumer is granted access to the service provided by the network function producer.

17. The apparatus of claim 16, wherein the access token displaying proof of ownership information, which is transmitted to the network function consumer, is the access token receiving the proof of ownership information from the authorization server.

18. The apparatus according to any one of claims 8 to 17, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: A subsequent access token request for the new access token is transmitted to the authorization server, the subsequent access token request including a client credential assertion token, the client credential assertion token including proof of ownership information; and Receive the new access token from the authorization server, which displays proof of ownership information.

19. The apparatus according to any one of claims 8 to 18, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: The network function consumer or another network function consumer receives a follow-up service request for the service, the follow-up service request including a client credential assertion token and an access token, the client credential assertion token including displaying ownership proof information; The subsequent service request for the service is after the service request for the service. Determine whether the information associated with the client certificate of the transport layer security terminal entity of the network function consumer or the other network function consumer matches at least a portion of the proof information displayed by the client credential assertion token of the subsequent service request; In response to the fact that the information associated with the client certificate of the transport layer security terminal entity does not match at least a portion of the proof information displayed by the client credential assertion token of the subsequent service request, it is determined to discard the subsequent service request. Determine whether the displayed ownership proof information of the client credential assertion token in the subsequent service request matches the displayed ownership proof information of the access token received from the authorization server; and If the presentation ownership proof information of the client credential assertion token in response to the subsequent service request does not match the presentation ownership proof information of the access token received from the authorization server, the subsequent service request is determined to be discarded.

20. The apparatus of claim 19, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: In response to the decision to discard the subsequent service request, it is determined that the other network function consumer is an illegitimate network function consumer.

21. The apparatus of any one of claims 8 to 20, wherein, since at least one first transport layer profile used with the network function consumer for the authorization server is different from at least one second transport layer profile used with the network function consumer for the apparatus, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request received from the network function consumer.

22. The apparatus of any one of claims 8 to 21, wherein, since at least one first transport layer terminal entity certificate used with the network function consumer for the authorization server is different from at least one second transport layer terminal entity certificate used with the network function consumer for the apparatus, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request received from the network function consumer.

23. The apparatus according to any one of claims 1 to 22, wherein the presentation of ownership proof information of the client credential assertion token includes at least one or more of the following: One or more mutually transport layer secure public keys, or One or more hashes of the mutual transport layer secure public key, or One or more mutual transport layer security certificates, or One or more hashes of mutual transport layer security certificates.

24. The apparatus according to any one of claims 1 to 23, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether at least a portion of the client credential assertion token’s presentation of proof information matches at least a portion of the access token’s presentation of proof information received with the service request; In response to the client credential assertion token's presentation possession proof information at least partially matching the access token's presentation possession proof information received with the service request, it is determined that the service request will be processed. as well as If any item in the presentation ownership proof information of the client credential assertion token does not match any item in the presentation ownership proof information of the access token received with the service request, the service request is determined to be discarded.

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

26. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: A service request for a service is transmitted to a service communication agent, the service request including a client credential assertion token, the client credential assertion token including proof of ownership information; Receive a response to a service request for the service from the service communication proxy; as well as Receive an access token from the service communication agent or authorization server, which includes information demonstrating ownership.

27. The apparatus of claim 26, wherein the response to the service request received from the service communication agent includes the access token having ownership verification information.

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

29. The apparatus according to any one of claims 26 to 28, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Transmit an access token request for the access token to the authorization server, the access token request including the client credential assertion token, the client credential assertion token including the displayed ownership proof information; and Receive the access token, which includes the information demonstrating ownership, from the authorization server.

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

31. The apparatus according to any one of claims 29 to 30, wherein: Before the device transmits the service request to the service communication proxy, the access token request for the access token is transmitted to the authorization server; as well as The service request includes both the client credential assertion token that displays proof of ownership and the access token that displays proof of ownership.

32. The apparatus of any one of claims 29 to 31, wherein since at least one first transport layer profile used with the apparatus for the authorization server is different from at least one second transport layer profile used with the apparatus for the service communication agent, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request transmitted to the service communication agent.

33. The apparatus of any one of claims 29 to 32, wherein, since at least one first transport layer terminal entity certificate used with the apparatus for the authorization server is different from at least one second transport layer terminal entity certificate used with the apparatus for the service communication agent, the presentation ownership proof information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership proof information of the service request transmitted to the service communication agent.

34. The apparatus according to any one of claims 26 to 33, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: The service communication proxy transmits a follow-up service request for the service, the follow-up service request including: The client credential assertion token that displays proof of ownership, and the access token that displays proof of ownership; The subsequent service request for the service is after 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 to at least: When the presentation ownership proof information of the client credential assertion token matches the presentation ownership proof information of the access token, an instruction is received from the service communication agent to reuse the access token with the presentation ownership proof information to access the service.

36. The apparatus according to any one of claims 26 to 35, wherein the presentation ownership proof information of the client credential assertion token and the presentation ownership proof information of the access token include at least one or more of the following: One or more mutually transport layer secure public keys, or One or more hashes of the mutual transport layer secure public key, or One or more mutual transport layer security certificates, or One or more hashes of mutual transport layer security certificates.

37. The apparatus according to any one of claims 26 to 36, wherein: The device includes a network-enabled consumer, or Network function consumers include the device, or The device includes user equipment, or User equipment includes the aforementioned device.

38. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Receive an access token request from a network function consumer or service communication agent, the access token request including a client credential assertion token, the client credential assertion token including information demonstrating ownership proof; as well as Transmit an access token displaying proof of ownership to the network function consumer or the service communication agent.

39. The apparatus of claim 38, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: The client credential asserts all or part of the presented ownership proof information in the access token to determine the presented ownership proof information.

40. The apparatus according to any one of claims 38 to 39, wherein: When the access token request is received from the network function consumer, the access token request is associated with model C; as well as When the access token request is received from the service communication agent, the access token request is associated with model D.

41. The apparatus according to any one of claims 38 to 40, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether a portion of the displayed ownership proof information of the client credential assertion token matches the information associated with the transport layer security terminal entity client certificate of the network function consumer. In response to determining that the portion of the client credential assertion token displaying proof information matches the information associated with the transport layer security terminal entity client certificate of the network function consumer, the access token displaying proof information is transmitted to the network function consumer.

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

43. The apparatus according to any one of claims 38 to 42, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether a portion of the ownership proof information displayed on the client credential assertion token matches the network function instance identifier in the public key certificate used to sign the client credential assertion token; In response to determining that the portion of the client credential assertion token that displays proof information matches the network function instance identifier in the public key certificate used to sign the client credential assertion token, the access token that displays proof information is transmitted to the network function consumer.

44. The apparatus of any one of claims 38 to 43, wherein the presentation ownership proof information of the access token is configured to: assert, based on any client credential, match the network function consumer presentation ownership proof information of the token with the presentation ownership proof information of the access token to determine whether the network function consumer is granted access to services provided by the network function producer.

45. The apparatus of any one of claims 38 to 44, wherein the presentation ownership proof information of the client credential assertion token and the presentation ownership proof information of the access token comprise at least one or more of the following: One or more mutually transport layer secure public keys, or One or more hashes of the mutual transport layer secure public key, or One or more mutual transport layer security certificates, or One or more hashes of mutual transport layer security certificates.

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

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

48. The apparatus of any one of claims 38 to 47, wherein, since at least one first transport layer profile used with the network function consumer in the apparatus is different from at least one second transport layer profile used with the network function consumer in the service communication agent, the presentation ownership information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership information of the service request associated with the service communication agent.

49. The apparatus of any one of claims 38 to 48, wherein, since at least one first transport layer terminal entity certificate used with the network function consumer in the apparatus is different from at least one second transport layer terminal entity certificate used with the network function consumer in the service communication agent, the presentation ownership information of the client credential assertion token of the access token request includes at least a portion of the presentation ownership information of the service request associated with the service communication agent.

50. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Receive a service request from the service communication agent, the service request including: a client credential assertion token displaying ownership proof information, and an access token displaying ownership proof information; as well as Based on the assertion token of the client credentials and the assertion token of the access token, a response to the service request is transmitted to the service communication agent, the response granting the network function consumer access to the services provided by the device.

51. The apparatus of claim 50, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether at least a portion of the displayed proof information of the client credential assertion token of the service request matches at least a portion of the displayed proof information of the access token; Wherein, in response to the service request, the client credential assertion token that displays proof information at least a portion thereof matches the access token that displays proof information at least a portion thereof, and the response to the service request is transmitted to the service communication agent, the response granting the network function consumer access to the service provided by the device.

52. The apparatus of any one of claims 50 to 51, wherein when the public key present in the access token matches the public key present in the client credential assertion token, the response to the service request is transmitted to the service communication agent, the response granting the network function consumer access to the service provided by the apparatus.

53. The apparatus according to any one of claims 50 to 52, wherein the presentation ownership proof information of the client credential assertion token and the presentation ownership proof information of the access token include at least one or more of the following: One or more mutually transport layer secure public keys, or One or more hashes of the mutual transport layer secure public key, or One or more mutual transport layer security certificates, or One or more hashes of mutual transport layer security certificates.

54. The apparatus according to any one of claims 50 to 53, wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: Determine whether a portion of the ownership proof information displayed on the client credential assertion token matches the network function instance identifier in the public key certificate used to sign the client credential assertion token; In response to the fact that the portion of the client credential assertion token that displays proof information matches the network function instance identifier in the public key certificate used to sign the client credential assertion token, it is determined to process the service request; as well as If any of the presented ownership proof information of the client credential assertion token does not match the network function instance identifier in the public key certificate used to sign the client credential assertion token, the service request is determined to be discarded.

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

Images