Mechanism for authenticating virtual identities via STIR and SHAKEN

Abstract

Embodiments of the present disclosure relate to mechanisms for authenticating virtual identities via STIR and SHAKEN. An apparatus includes circuitry configured to: receive, from a first user device, a session initiation protocol invitation request to a second user device, where the session initiation protocol invitation request includes information related to at least one virtual identity; sending at least one signature request to a signature server as part of a signature process, the at least one signature request comprising information related to the at least one virtual identity; receiving a response to the at least one signature request from the signature server, wherein the response to the at least one signature request comprises: a signature token or other related information associated with the at least one virtual identity created during the signature process; and forwarding the session initiation protocol invitation request with the identity header to the network entity, wherein the identity header includes the signature token or other related information created during the signature process.

Description

Technical Field

[0001] The exemplary and non-limiting exemplary embodiments relate generally to communications, and more particularly to mechanisms for authenticating virtual identities via STIR AND SHAKEN. Background Art

[0002] It is known that two communication devices participate in a call in a communication network. Summary of the invention

[0003] According to one aspect, an apparatus includes: at least one processor; and at least one memory, the at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: receive a session initiation protocol invitation request intended for a second user device from a first user device, wherein the session initiation protocol invitation request includes information related to at least one virtual identity; send at least one signing request to a signing server as part of a signing process, wherein the at least one signing request includes information related to at least one virtual identity; receive a response to the at least one signing request from the signing server, wherein the response to the at least one signing request includes: a signing token or other related information related to the at least one virtual identity created during the signing process; and forward the session initiation protocol invitation request with an identity header to a network entity, wherein the identity header includes a signing token or other related information related to the at least one virtual identity created during the signing process.

[0004] According to one aspect, a device includes: at least one processor; and at least one memory, the at least one memory storing instructions, which, when executed by the at least one processor, cause the device to at least: receive a session initiation protocol invitation request with an identity header from a network entity, wherein the identity header includes a signature token or other related information created during a signing process, wherein the session initiation protocol invitation request includes information related to at least one virtual identity and is associated with a first user device; send a verification request to a verification server to verify the information related to the at least one virtual identity, wherein the verification request includes: an identity header including the signature token or other related information created during the signing process, a session initiation protocol invitation request associated with the first user device, and information related to the at least one virtual identity; receive an indication from the verification server whether the information related to the at least one virtual identity is verified; and in response to receiving an indication from the verification server that the information related to the at least one virtual identity is verified, forward the session initiation protocol invitation request and the information related to the at least one virtual identity to a second user device.

[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 a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request includes: an identity header including a signature token or other related information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity; determine whether the information associated with at least one virtual identity is verified based on the identity header and the information associated with at least one virtual identity; and send an indication to the network entity whether the information associated with at least one virtual identity is verified.

[0006] According to one aspect, an apparatus comprises: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: send a session initiation protocol invitation request to a second user device from a first user device to a network entity, wherein the session initiation protocol invitation request includes information related to at least one virtual identity as part of a signing process, and wherein the apparatus comprises the first user device; receive an identity header related to at least one virtual identity from the network entity, the at least one virtual identity being verified; and store an identity header related to at least one verified virtual identity of at least one other session initiation protocol invitation request.

[0007] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity; and download, use, or view information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device.

[0008] According to one aspect, an apparatus includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive at least one signature request from a network entity as part of a signing process, the at least one signature request including information related to at least one virtual identity; and send a response to the at least one signature request to the network entity, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above-described aspects and other features are explained in the following description taken in conjunction with the accompanying drawings.

[0010] Figure 1 is a block diagram of one possible non-limiting system in which example embodiments may be practiced.

[0011] Figure 2 An example Ms reference point operation is shown.

[0012] Figure 3 The IMS AR communication architecture is shown.

[0013] Figure 4 is a signaling diagram based on the examples described in this article.

[0014] Figure 5 is an example apparatus configured to implement the examples described herein.

[0015] Figure 6 A representation of an example of a non-volatile storage medium for storing instructions to implement the examples described herein is shown.

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

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

[0018] Fig. 9 is an example method based on the examples described in this article.

[0019] Fig.10 is an example method based on the examples described in this article.

[0020] Fig.11 is an example method based on the examples described in this article.

[0021] Fig.12 is an example method based on the examples described in this article. DETAILED DESCRIPTION

[0022] Steering Figure 1 , which shows a block diagram of one possible non-limiting example in which the examples may be practiced. A user equipment (UE) 110, a radio access network (RAN) node 170, and (multiple) network elements 190 are shown. Figure 1In the example of FIG. 1 , a user equipment (UE) 110 wirelessly communicates with a wireless network 100. A UE is a wireless device that can access the wireless network 100. The UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected by 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, an optical fiber or other optical communication device, etc. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The UE 110 includes a module 140, which includes one or both of the parts 140-1 and / or 140-2, which can be implemented in a variety of ways. The module 140 can be implemented in hardware as the module 140-1, such as being implemented as part of the one or more processors 120. Module 140-1 may also be implemented as an integrated circuit or by other hardware such as a programmable gate array. In another example, module 140 may 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 may be configured to cause user equipment 110 to perform one or more of the operations described herein together with one or more processors 120. UE 110 communicates with RAN node 170 via wireless link 111.

[0023] In this example, the RAN node 170 is a base station that provides access to the wireless network 100 for wireless devices such as UE 110. The RAN node 170 may be, for example, a base station for 5G, also known as New Radio (NR). In 5G, the RAN node 170 may be a 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 towards the UE and is connected to a 5GC (such as, for example, (multiple) network elements 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 towards the UE and is connected to a 5GC via an NG interface (such as connection 131). The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) 196 and (multiple) distributed units (DU) (gNB-DU), of which DU 195 is shown. Note that the DU 195 may include or be coupled to and control a radio unit (RU). The gNB-CU 196 is a logical node that hosts the radio resource control (RRC), SDAP, and PDCP protocols of a gNB or the RRC and PDCP protocols of an en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU 196 terminates the F1 interface connected to the gNB-DU 195. The F1 interface is shown as reference 198, although reference 198 also shows a link between a remote element of the RAN node 170 and a centralized element of the RAN node 170, such as a link between the gNB-CU 196 and the gNB-DU 195. The 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 controlled in part by the gNB-CU 196. One gNB-CU 196 supports one or more cells. One cell can be supported by one gNB-DU 195, or one cell can be supported / shared with 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 the transceiver 160, e.g., as part of the RU, but some examples in this regard may have the transceiver 160 as part of a separate RU, e.g., under the control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolved Node B) base station for LTE (Long Term Evolution), or any other suitable base station or node.

[0024] The 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 by one or more buses 157. Each of the one or more transceivers 160 includes a receiver Rx 162 and a transmitter Tx 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include (multiple) processors 152, one or more memories 155, and a network interface 161. Note that the DU 195 may also include its own memory / memory and (multiple) processors, and / or other hardware, but these are not shown.

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

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

[0027] The one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of wires on a motherboard or integrated circuit, optical fiber or other optical communication device, wireless channel, etc. For example, the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for a gNB implementation for 5G, where other elements of the RAN node 170 may be physically located at a different location from the RRH / DU 195, and the one or more buses 157 may be implemented in part, for example, as fiber optic cables or other suitable network connections for connecting other elements of the RAN node 170 (e.g., central unit (CU), gNB-CU 196) to the RRH / DU 195. Reference 198 also indicates these suitable network link(s).

[0028] The RAN node / gNB may include one or more TRPs, to which the methods described herein may be applied. Figure 1 RAN node 170 is shown to include TRP 51 and TRP 52 in addition to the TRP represented by transceiver 160. Similar to transceiver 160, TRP 51 and TRP 52 may each include a transmitter and a receiver. RAN node 170 may host or include Figure 1 Other TRPs not shown.

[0029] The relay nodes in NR are called integrated access and backhaul nodes. The mobile terminal part of the IAB node facilitates the backhaul (parent link) connection. In other words, the mobile terminal part includes the functionality of carrying UE functions. The distributed unit part of the IAB node facilitates the so-called access link (sub-link) connection (i.e., for access link UE, and in the case of multi-hop IAB, for the backhaul of other IAB nodes). In other words, the distributed unit part is responsible for certain base station functions. The IAB scenario can follow a so-called split architecture, where the central unit hosts the high-level protocols for the UE and terminates the control plane and user plane interfaces with the 5G core network.

[0030] Note that the description herein indicates that a "cell" performs a function, but it should be clear that the device that forms the cell can perform the function. A cell constitutes part of a base station. That is, each base station can have multiple cells. For example, a single carrier frequency and associated bandwidth can have three cells, each covering one-third of a 360-degree area, so the coverage area of ​​a single base station covers an approximate ellipse or circle. In addition, each cell can correspond to a single carrier and the base station can use multiple carriers. So if each carrier has three 120-degree cells and there are two carriers, the base station has a total of 6 cells.

[0031] The wireless network 100 may include one or more network elements 190, which may include core network functions and provide connectivity to other networks such as telephone networks and / or data communication networks (e.g., the Internet) via one or more links 181. Such core network functions for 5G may include location management functions (LMF) and / or (multiple) access and mobility management functions (AMF) and / or 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 may be supported by (multiple) network elements 190, and it is noted that both 5G and LTE functions may be supported. The RAN node 170 is coupled to the network element 190 via a 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. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N / WI / F) 180 interconnected by one or more buses 185. The one or more memories 171 include computer program code 173. The computer program code 173 may include SON and / or MRO functionality 172.

[0032] The 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, which is usually combined with resource virtualization. Network virtualization is divided into external network virtualization or internal network virtualization. External network virtualization combines many networks or network parts into virtual units, and internal network virtualization provides network-like functions for software containers on a single system. Note that the virtualized entities generated by network virtualization are still implemented using hardware such as processors 152 or 175 and memories 155 and 171 to some extent, and such virtualized entities also produce technical effects.

[0033] Computer readable memories 125, 155, and 171 may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, non-volatile memory, volatile memory, fixed memory, and removable memory. Computer readable memories 125, 155, and 171 may be components for performing storage functions. Processors 120, 152, and 175 may be of any type suitable for the local technical environment and, as non-limiting examples, may 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 may be components for performing functions such as control of UE 110, RAN node 170, (multiple) network elements 190, and other functions described herein.

[0034] In general, various example embodiments of user equipment 110 may include, but are not limited to, a cell phone with wireless communication capabilities (such as a smart phone, a tablet computer, a personal digital assistant (PDA)), a portable computer with wireless communication capabilities, an image capture device with wireless communication capabilities (such as a digital camera), a gaming device with wireless communication capabilities, a music storage and playback device with wireless communication capabilities, an Internet device (including those that allow wireless Internet access and browsing), a tablet computer with wireless communication capabilities, a head-mounted display (such as those that implement virtual / augmented / mixed reality), and a portable unit or terminal that incorporates a combination of such functions. UE 110 may also be a vehicle such as a car, or a UE installed in a vehicle, a UAV such as an unmanned aerial vehicle, or a UE installed in a UAV. User equipment 110 may be a terminal device, such as a mobile phone, a mobile device, a sensor device, etc., which is a device used by a user or not used by a user.

[0035] UE 110, RAN node 170 and / or network element(s) 190 (and associated memory, computer program code and modules) may be configured to implement (eg, in part) the methods described herein. Figure 1 The computer program code 123, module 140-1, module 140-2 and other elements / features of the UE 110 shown may implement the example user equipment related aspects described herein. Similarly, Figure 1 The computer program code 153, module 150-1, module 150-2, and other elements / features of the illustrated RAN node 170 may implement the example gNB / TRP-related aspects described herein. Figure 1The computer program code 173 and other elements / features of the illustrated network element(s) 190 may be configured to implement the example network element related aspects described herein.

[0036] Therefore, having introduced a suitable but non-limiting technical background for the practice of the example embodiments, the example embodiments are now described in more detail.

[0037] The Ms reference point described in TS24.229 (e.g., see Annex V.2) is used to request a signature for the Identity header field, or to request verification of a signed assertion in the Identity header field. This enables calling number verification using signature verification and attestation information based on the STIR / SHAKEN framework. This is particularly important for robocalls, such as flagging potential spam calls.

[0038] The existing Ms reference points and procedures described in TS 24.229 are used to sign and verify other identities than the identity in the P-Asserted-Identity header field which is primarily in the format of a SIP URI or Tel URL.

[0039] Figure 2 The use of the Ms reference point to sign and verify the identity in the SIP header field is shown, where the AS (STI-AS) is used to sign 210 on the originating side and the AS (STI-VS) 216 is used to verify on the terminating side. To verify the calling line identity, the IBCF 204 or AS 202 of the originating network issues an HTTP signing request (206, 208) to the signing AS 210, which in turn responds with a personal assertion token (PASSporT) (206, 2008). On the terminating network side, the IBCF 224 or AS 222 issues an HTTP verification request (212, 214) to the signing AS 216, which includes the PASSporT, and the signing AS 216 responds with a verification success or failure message (212, 214).

[0040] Protecting the caller's display name is not within the scope of Secure Telephone Identity Reaccess (STIR), and IETF draft-ietf-stir-passport-rcd-26 documents optional mechanisms for PASSport and related STIR processes to allow signing and verification of additional data elements, including, for example: the name of the calling person or entity; traditional caller ID and related display information that will be rendered to the called party during an alert; a hyperlink to an image (such as a logo or facial image) or similar external profile information; information related to the caller's location; information related to the organization, or category or department of organizations and institutions, with which the caller is associated; and potentially other rich call data (RCD) information elements.

[0041] Signature request / response example:

[0042] Sample request:

[0043]

[0044] Example response (successful):

[0045]

[0046]

[0047] In 3GPP Rel19 TS22.261 clause 6.39, 5G IMS multimedia telephony services are extended to new devices such as AR / VR / XR, which can bring promising improvements to IMS services. TS23.228AC.9 provides support for AR communications. Figure 3 An example IMS AR communication architecture is shown. Figure 3 A digital asset container (DAC) not shown in the figure is used to store and retrieve virtual identity models. The DAC can be inside or outside the 5GC.

[0048] In TS22.156, 3GPP SA1 has defined various requirements for virtual identity calls, including (1-7):

[0049] 1. Subject to user consent, the 5G system (including IMS) should support multimedia session communications between two or more users, including the transmission of real-time avatar media and audio media. The avatar media can be sent on both uplink and downlink. It is assumed that the data used to generate the avatar (e.g., from UE cameras, etc.) is confidential.

[0050] 2. Subject to user consent, 5G systems (including IMS) should support parties in a multimedia session to change media type between video and avatar media.

[0051] 3.5G systems (including IMS) should support transcoding between media such as text, video, and avatar media in multimedia session communications. Text, video, or other media may allow a party to control the appearance of their avatar, such as expressing behavior, movement, affect, emotion, etc. Transcoding of media enables avatar communications, such as in scenarios where UEs participating in IMS calls or other services do not support, such as FACS, encoding avatar media, generating avatar media, etc.

[0052] 4. Subject to operator policies, regulatory requirements and user consent, 5G systems (including IMS) should support the ability to render virtual identities based on physical motion information of human users (e.g., body movements or facial expressions).

[0053] 5.5G systems (including IMS) should support encoding sensor data that captures a person's facial expressions, movements, and gestures in a standard form. In multimedia session communications, the actual transmission and rendering of a person's facial expressions, movements, and gestures are subject to the person's consent.

[0054] 6. Subject to operator policies, regulatory requirements and user consent and operator policies, 5G systems should be able to authorize virtual identities for use in mobile metaverse services.

[0055] 7. Subject to regulatory requirements, user consent and operator policies, 5G systems should provide time-limited authorization for designated users to use virtual identities in mobile metaverse services.

[0056] And regarding digital assets (including virtual identities) (1-2):

[0057] 1. Subject to user consent, regulatory requirements, and operator policies, 5G systems should provide a secure way to authorize the use of digital assets associated with users (e.g., digital assets belonging to third-party customers).

[0058] 2.5G systems should provide mechanisms to prove the authenticity of digital assets associated with users.

[0059] Digital asset container management can provide solutions for securely managing representative symbols and other media. IMS virtual identity calls can also be implemented, and the examples described in this article involve virtual identity representation identification. For example, STIR and SHAKEN with rich data or third-party identities and identifications can be implemented to treat virtual identity IDs or virtual identity files as part of such information. Similarly, related behaviors based on whether virtual identity information has been verified can be defined in IMS. Therefore, the examples described in this article involve virtual identity authentication based on STIR and SHAKEN and related system aspects and solutions, as well as STIR and SHAKEN enhancements for virtual identity calls.

[0060] As defined in SA1 Metaverse TR 22.156 (see clause 7.2): Subject to operator policy, regulatory requirements and user consent and operator policy, the 5G system shall be able to authorize virtual identities for use in mobile Metaverse services, subject to regulatory requirements, user consent and operator policy, the 5G system shall provide time-limited authorization for a specified subscriber to use a virtual identity in mobile Metaverse services, subject to user consent, regulatory requirements and operator policy, the 5G system shall provide a secure way to authorize the use of digital assets associated with a user (e.g., digital assets belonging to a third-party customer), and the 5G system shall also provide mechanisms to prove the authenticity of digital assets associated with a user.

[0061] Public figures can use patented or copyrighted virtual identities to avoid any misuse of their virtual identities. However, in IMS calls, the network should ensure that users are only allowed to use their own virtual identities, and the network should not allow users to use other patented or copyrighted virtual identities.

[0062] Furthermore, care should be taken that the virtual identity representation cannot be hijacked, e.g. replaced with another content or representation if the ID is the same: its integrity must therefore be protected.

[0063] It is further anticipated that A2P calls are developed in the context of virtual identity calls, such as for customer service or potential telemarketing calls, including robot calls made with virtual identities and pre-recorded voices. Therefore, in this context, trusted identification of virtual identities is very important to avoid unnecessary virtual identity calls. The examples described herein utilize the STIR and / or SHAKEN frameworks in IMS to authenticate the use of a virtual identity used by a user in an IMS virtual identity call.

[0064] Main assumptions and definitions:

[0065] Virtual identity metadata or virtual identity representation is a 2D or 3D representation content or model of a virtual identity stored in a file that can be accessed via a URL. Virtual identity metadata or representation can correspond to a face or a full body or a part of a body. The virtual identity representation is stored in a digital asset container (DAC). The DAC can be inside the PLMN, for example as a new NF or part of a NF (e.g., HSS or UDM, IMS AS), an XR application server, or a network server within the IMS and / or 5GC, or outside the PLMN (e.g., on a network server of a cloud provider). There may be potential security issues in retrieving the virtual identity representation from an external storage device. Additional metadata may be associated with the virtual identity representation (e.g., format, resolution, access or usage rights and time, creation date, license, etc.). Candidate technologies for the virtual identity model may be, for example, glTF or VRM.

[0066] It is assumed that virtual identity representations or references to them (e.g., virtual identity IDs) are associated with each subscriber and / or each subscriber's user identity (i.e., it is assumed that each subscriber has multiple user identities, such as personal and / or professional). Additional metadata may be associated with the virtual identity ID user association (e.g., access or usage permissions and time, etc.).

[0067] Multiple virtual identity representations may be stored for each subscriber, each of which may be addressed via a virtual identity ID. The virtual identity ID may be, for example, an integer, a string, a UUID, a URI (URN or URL). When in the form of a URI, the virtual identity ID may be in the form of a dereferenceable URI, allowing easy retrieval of the relevant virtual identity representation. Other means (such as, for example, via Webfinger or Host-meta or LRDD protocols, or from a predefined server) may be used to retrieve the virtual identity representation based on the virtual identity ID.

[0068] Possibly, different alternative versions (eg, format / technology, resolution, etc.) of the avatar representation may be provided.

[0069] The main solution principles described in this article:

[0070] The initiating UE or network may retrieve the virtual identity ID, for example, via SIP or SDP signaling and add it to the IMS call. For example, the user may select a virtual identity from a web page of possible or allowed virtual identities and use the corresponding virtual identity URL as the ID. The allowed virtual identity IDs (URLs) may also be stored in the network (UDM / HSS) as part of the user subscription data.

[0071] The network checks whether the user is authorized to use the virtual identity ID provided by the initiating UE in the SIP or SDP signaling, or trusts the user (e.g., an enterprise) to allow the use of the provided virtual identity ID for the user. The IMS can check the virtual identity ID by contacting a (trusted) third party where the virtual identity is stored, and provides the user's ID (e.g., IMPU) and the selected virtual identity ID.

[0072] In addition, the calling party virtual identity must be integrity protected and therefore signed. To sign the calling party virtual identity, the IBCF or AS of the originating network issues an HTTP signature request including the virtual identity identity (e.g., virtual identity URI) and the virtual identity content to the signing AS, which in turn responds with a personal assertion token (PASSporT), which is forwarded to the terminal side in SIP signaling.

[0073] The signing request can be as follows:

[0074]

[0075] As shown in the above examples, one or more virtual identity identifiers and one or more virtual identity uniform resource identifiers are passed by reference, which is preferred (in other examples, one or more virtual identity identifiers and one or more virtual identity uniform resource identifiers can be passed by value), and the virtual identity content is passed by value (in other examples, the virtual identity content can be passed by reference).

[0076] The signed response with identity (enhanced token) will include one or more virtual identity IDs or one or more virtual identity URIs or virtual identity content. The virtual identity ID, virtual identity URI or virtual identity content can be provided in the Call-Info header.

[0077] Additionally, the call information header and calling party number may be signed separately.

[0078] On the terminal network side, the IBCF or AS sends an HTTP authentication request to the authentication AS, which includes the received PASSPORT, and the authentication AS in turn responds with an authentication success or failure message. If the authentication of the enhanced token is successful, the included one or more virtual identity IDs or one or more virtual identity URIs or virtual identity content matches the virtual identity selected by Party A (where Party A is the party that initiated the invitation request). Based on the provided virtual identity ID, Party B (where Party B is the recipient of the invitation) can download the virtual identity for use in the IMS virtual identity call.

[0079] The originating network can issue a signature token or passport to the UE so that the UE can cache the signature token together with the virtual identity Id and use it for further communications. This avoids issuing an additional signature request to the signature server.

[0080] Figure 4 is a signaling diagram illustrating various aspects of the methods described herein. Specifically, Figure 4 Signaling exchanges between UE-A 110-A, original IMS 420, signature server 210, terminal IMS 430, verification server 216, and UE-B 110-B are shown.

[0081] Step 1 (401): UE-A sends an INVITE request to the originating IMS network, the INVITE request includes a virtual identity ID or a virtual identity URI or virtual identity content, for example, as an RCD in a call information header. Alternatively, the IMS AS may add a virtual identity ID available or stored in the network.

[0082] Step 2 (402): If the passport or token and the virtual identity ID (previously cached in UE 110-A) are not available, the IMS network 420 issues a signing request including the virtual identity ID or virtual identity URI or virtual identity content to the signing server 210. It complies with STIR and SHAKEN standards and RFC.

[0083] If multiple virtual identities are provided in the INVITE request, the IMS network sends multiple requests, each of which carries a single virtual identity related information item.

[0084] An example request could be:

[0085]

[0086]

[0087] As shown in the above examples, one or more virtual identity identifiers and one or more virtual identity uniform resource identifiers are passed by reference, which is preferred (in other examples, one or more virtual identity identifiers and one or more virtual identity uniform resource identifiers can be passed by value), and the virtual identity content is passed by value (in other examples, the virtual identity content can be passed by reference).

[0088] The signature request may be specific to the virtual identity information and different, such as from a caller ID signature request.

[0089] Step 3 (403): The signing server 210 verifies the request and issues a response to the originating IMS network 420. The response includes a token or passport to be used in the identity header. This header also has the virtual identity details. A sample response may look like:

[0090]

[0091] 0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6IjEyM2U0NTY3LW

[0092] U4OWItMTJkMy1hNDU2

[0093] LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6nY4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4

[0094] WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA;info=;alg=ES256",

[0095] ppt="rcd"

[0096] }}

[0097] Before signing the original IMS 420, it must be ensured that UE 110-A is allowed to provide the virtual identity. The virtual identity itself is trusted, or the virtual identity is retrieved from a trusted external entity, or is stored inside the network itself (in the HSS) and retrieved from there. The signing server 210 generates a token based on the certificate and header content. The IMS network (420,

[0098] 430) This content must be trusted. It is the same as the phone number provided by UE 110A, which is credible (or asserted) because it is stored in the HSS.

[0099] Step 4 (404), 5 (405): The initiating network 420 forwards the INVITE request to the terminating network 430, with the enhanced token in the identity header. If multiple virtual identities are provided in the INVITE request, there are multiple identity headers, each header carrying a single virtual identity related information item.

[0100] Now, the terminal network 430 sends a request to the verification server 216 to verify the identity header.

[0101] Steps 6 (406), 7 (407): Verify that the server 216 complies with STIR and SHAKEN

[0102] RFC, and verify the content of one or more identity headers. In addition, if the virtual identity ID or virtual identity URI or virtual identity content available in the identity header matches the virtual identity ID or virtual identity URI or virtual identity content available in the request, the identity header and / or virtual identity related information is considered valid, and the verification server issues a response. Otherwise, the verification server issues an error.

[0103] Alternatively, if only the virtual identity (identity header dedicated to the virtual identity, e.g. using parameter ppt="rcd") verification fails, but e.g. the originator identity (From) is valid, the terminating network 430 may allow the call to proceed without the virtual identity.

[0104] Steps 8 (408), 9 (409): The terminating IMS network 430 forwards the INVITE to UE-B 110-B, and after receiving a response from UE-B, it (terminating IMS network 4.3) forwards the response to UE-A 110-A, which is via the originating IMS network 420. If the virtual identity cannot be verified, the IMS network 430 may have different behaviors based on the configuration (1-3):

[0105] 1. Reject the call without notifying UE-B 110-B;

[0106] 2. Remove the virtual identity media (e.g., only allow audio calls), but still forward the call to UE-B (e.g., if UE-A identity is positively verified via a separate token associated with the originator ID);

[0107] 3. Forward the call to UE-B with an indication that the virtual identity cannot be verified (or does not indicate that it is verified). In this case, UE-B informs the B-user that this may be a spam or spoofed virtual identity, and UE-B may not attempt to download or display the virtual identity during the incoming call ringing or setup.

[0108] Only when the virtual identity URI is verified, the terminal network 430 and / or UE-B 110 -B can download the verified virtual identity from the URL and present the virtual identity to the terminal party B.

[0109] Steps 10 (410), 11 (411): The originating network 420 may add a SIP identity header associated with the verified virtual identity to UE-A 110-A, so that UE-A may cache the SIP identity header associated with the verified virtual identity and further use the SIP identity header associated with the verified avatar for subsequent calls. Note that other SIP identity headers associated with, for example, the verified calling party identity may also be added to UE-A.

[0110] The examples described herein may be part of a 3GPP standard such as the 3GPP Rel-19 standard.

[0111] Figure 5 500 (which may be implemented in hardware) is configured to implement the examples described herein. The apparatus 500 includes at least one processor 502 (e.g., an FPGA and / or a CPU), one or more memories 504 including computer program code 505, the computer program code 505 having instructions for performing the methods described herein, wherein the at least one memory 504 and the computer program code 505 are configured to cause the apparatus 500 to implement a circuit system, process, component, module, or function (implemented with a control module 506) with the at least one processor 502 to implement the examples described herein. The memory 504 may be a non-transitory memory, a transient memory, a volatile memory (e.g., a RAM), or a non-volatile memory (e.g., a ROM). Optionally, the authentication 530 of the control module implements aspects described herein related to authenticating a virtual identity via STIR and SHAKEN.

[0112] The device 500 includes a display and / or I / O interface 508, which includes user interface (UI) circuit systems and elements, which can be used to display aspects or states of the methods described herein (for example, while one of the methods is being performed or at a subsequent time), or to receive input from a user, such as using a keypad, camera, touch screen, touch area, microphone, biometrics, one or more sensors, etc. The device 500 includes one or more communications, such as (multiple) network (N / W) interface (I / F) 510. The (multiple) communication I / F 510 can be wired and / or wireless, and communicate over (multiple) Internet / other networks via any communication technology (including via one or more links 524). The (multiple) link 524 can be from Figure 1 Link(s) 131 and / or 176. Figure 1 The link(s) 131 and / or 176 may also be implemented using transceiver(s) 516 and corresponding wireless link(s) 526. The communication I / F(s) 510 may include one or more transmitters or one or more receivers.

[0113] The transceiver 516 includes one or more transmitters 518 and one or more receivers 520. The transceiver 516 and / or the communication I / F(s) 510 may include standard well-known components such as amplifiers, filters, frequency converters, (de)modulators and encoder / decoder circuitry, and one or more antennas, such as antenna 514 for communicating over a wireless link 526.

[0114] The control module 506 of the device 500 includes one or both of the components 506-1 and / or 506-2, which can be implemented in a variety of ways. The control module 506 can be implemented in hardware as the control module 506-1, such as being implemented as a part of one or more processors 502. The control module 506-1 can also be implemented as an integrated circuit or implemented by other hardware such as a programmable gate array. In another example, the control module 506 can be implemented as a control module 506-2, which is implemented as a computer program code (with corresponding instructions) 505 and is executed by one or more processors 502. For example, one or more memories 504 store instructions that, when executed by one or more processors 502, cause the device 500 to perform one or more of the operations described herein. In addition, one or more processors 502, one or more memories 504, and example algorithms (e.g., as flow charts and / or signaling diagrams) (encoded as instructions, programs, or codes) are components for performing the operations described herein.

[0115] The apparatus 500 for implementing the functionality of the control 506 may be a UE 110, a RAN node 170 (e.g., a gNB), or (multiple) network elements 190 (e.g., a LMF 190). Thus, processor 502 may correspond to processor(s) 120, processor(s) 152, and / or processor(s) 175, memory 504 may correspond to memory(s) 125, memory(s) 155, and / or memory(s) 171, computer program code 505 may correspond to computer program code 123, computer program code 153, and / or computer program code 173, control module 506 may correspond to module 140-1, module 140-2, module 150-1, and / or module 150-2, and communication I / F(s) 510 and / or transceiver 516 may correspond to transceiver 130, antenna(s) 128, transceiver 160, antenna(s) 158, N / WI / F(s) 161, and / or N / WI / F(s) 180. Alternatively, apparatus 500 and its elements may not correspond to any of UE 110, RAN node 170, or network element(s) 190 and their respective elements, as apparatus 500 may be part of a Self-Organizing / Optimizing Network (SON) node or other node, such as a node in a cloud.

[0116] Apparatus 500 may also correspond to UE-A 110-A (UE-A 110-A may be configured similarly to UE 110), original IMS 420, signature server 210, terminal IMS 430, verification server 216, or UE-B 110-B (UE-B 110-B may be configured similarly to UE 110).

[0117] The apparatus 500 may also be distributed throughout the network (eg, 100 ), including within and between the apparatus 500 and any network elements, such as a network control element (NCE) 190 and / or a RAN node 170 and / or a UE 110 .

[0118] Interface 512 enables data communication and signaling between various items of apparatus 500, such as Figure 5As shown. For example, interface 512 can be one or more buses, such as an address, data, or control bus, and can include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, an optical fiber or other optical communication device, etc. The computer program code (e.g., instructions) 505 including control module 506 can include object-oriented software configured to pass data or messages between objects within computer program code 505. Device 500 need not include each of the features mentioned, or may also include other features. The various components of device 500 can be at least partially located in a common housing 528, or a subset of the various components of device 500 can be at least partially located in different housings, which can include housing 528.

[0119] Figure 6 Schematic diagrams of non-volatile memory media 600a (e.g., computer / compact disk (CD) or digital versatile disk (DVD)) and 600b (e.g., universal serial bus (USB) memory stick) and 600c (e.g., cloud storage for downloading instructions and / or parameters 602 or receiving email instructions and / or parameters 602) storing instructions and / or parameters 602 that, when executed by a processor, allow the processor to perform one or more of the steps of the methods described herein. The instructions and / or parameters 602 may represent non-transitory computer-readable media.

[0120] Figure 7 An example method 700 based on example embodiments described herein. At 710, the method includes receiving a session initiation protocol invite request from a first user device to a second user device, wherein the session initiation protocol invite request includes information related to at least one virtual identity. At 720, the method includes sending at least one signing request to a signing server as part of a signing process, the at least one signing request including information related to at least one virtual identity. At 730, the method includes receiving a response to the at least one signing request from the signing server, wherein the response to the at least one signing request includes: a signing token or other related information related to the at least one virtual identity created during the signing process. At 740, the method includes forwarding the session initiation protocol invite request with an identity header to a network entity, wherein the identity header includes a signing token or other related information related to the at least one virtual identity created during the signing process. The method 700 may be performed with an initiating IMS 420, a RAN node 170, one or more network elements 190, or an apparatus 500.

[0121] Figure 8The example method 800 is based on the example embodiments described herein. At 810, the method includes receiving a session initiation protocol invite request with an identity header from a network entity, wherein the identity header includes a signature token or other relevant information created during a signing process, wherein the session initiation protocol invite request includes information related to at least one virtual identity and is associated with a first user device. At 820, the method includes sending a verification request to a verification server to verify the information related to at least one virtual identity, wherein the verification request includes: an identity header including a signature token or other relevant information created during the signing process, a session initiation protocol invite request associated with the first user device, and information related to at least one virtual identity. At 830, the method includes receiving an indication from the verification server whether the information related to at least one virtual identity is verified. At 840, the method includes forwarding the session initiation protocol invite request and the information related to at least one virtual identity to a second user device in response to receiving an indication from the verification server that the information related to at least one virtual identity is verified. The method 800 may be performed by a terminal IMS 430, a RAN node 170, one or more network elements 190, or an apparatus 500.

[0122] Fig. 9 An example method 900 based on example embodiments described herein is provided. At 910, the method includes receiving a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request includes: an identity header including a signature token or other related information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity. At 920, the method includes determining whether the information associated with at least one virtual identity is verified based on the identity header and the information associated with at least one virtual identity. At 930, the method includes sending an indication to the network entity whether the information associated with at least one virtual identity is verified. The method 900 may be performed with a verification server 216, a RAN node 170, one or more network elements 190, or an apparatus 500.

[0123] Fig.10An example method 1000 based on example embodiments described herein. At 1010, the method includes sending a session initiation protocol invite request to a second user device from a first user device to a network entity, wherein the session initiation protocol invite request includes information related to at least one virtual identity as part of a signing process. At 1020, the method includes receiving an identity header related to at least one virtual identity from the network entity, the at least one virtual identity being verified. At 1030, the method includes storing an identity header related to at least one other session initiation protocol invite request that is verified to the at least one virtual identity. The method 1000 may be performed by the UE-A 110-A, the UE 110, or the apparatus 500.

[0124] Fig.11 An example method 1100 based on example embodiments described herein. At 1110, the method includes receiving a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity. At 1120, the method includes downloading, using, or viewing information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device. The method 1100 may be performed by UE-B 110-B, UE 110, or apparatus 500.

[0125] Fig.12 An example method 1200 based on example embodiments described herein is provided. At 1210, the method includes receiving at least one signing request from a network entity as part of a signing process, the at least one signing request including information related to at least one virtual identity. At 1220, the method includes sending a response to the at least one signing request to the network entity, wherein the response to the at least one signing request includes: a signing token or other related information related to the at least one virtual identity created during the signing process. The method 1200 may be performed by the signing server 210, the RAN node 170, one or more network elements 190, or the device 500.

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

[0127] Example 1. An apparatus comprising: 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 session initiation protocol invitation request from a first user device intended for a second user device, wherein the session initiation protocol invitation request includes information related to at least one virtual identity; send at least one signature request to a signature server as part of a signature process, wherein the at least one signature request includes information related to at least one virtual identity; receive a response to the at least one signature request from the signature server, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signature process; and forward the session initiation protocol invitation request with an identity header to a network entity, wherein the identity header includes a signature token or other related information related to the at least one virtual identity created during the signature process.

[0128] Example 2. The apparatus of example 1, wherein at least one of the signature requests is based on at least one or more of: a secure phone identity re-access standard, or a signature-based processing of asserted information using a token standard.

[0129] Example 3. An apparatus according to any one of Examples 1 to 2, wherein the information related to at least one virtual identity within at least one signature request includes at least one or more of the following: a virtual identity identifier, or a virtual identity uniform resource identifier, or virtual identity content.

[0130] Example 4. The apparatus of any one of Examples 1 to 3, wherein the information related to the at least one virtual identity within the session initiation protocol invite request is sent in a call information header.

[0131] Example 5. An apparatus according to any one of Examples 1 to 4, wherein the information related to the at least one virtual identity within the session initiation protocol invite request is trusted or retrieved from a trusted entity, or stored and retrieved from a trusted network function.

[0132] Example 6. The apparatus of example 5, wherein the information related to the at least one virtual identity within the session initiation protocol invite request is stored in a home subscriber server.

[0133] Example 7. An apparatus according to any one of Examples 3 to 6, wherein the instructions, when executed by at least one processor, cause the apparatus to perform at least one or more of the following: passing the virtual identity identifier to the signing server by reference within at least one signing request, or passing the virtual identity uniform resource identifier to the signing server by reference within at least one signing request, or passing the virtual identity content to the signing server by value within at least one signing request.

[0134] Example 8. An apparatus according to any one of Examples 1 to 7, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: in response to the presence of multiple virtual identities in a session initiation protocol invitation request, send one or more signature requests to a signature server, wherein a signature request in the multiple signature requests includes information related to the virtual identities; and in response to the presence of multiple virtual identities in the session initiation protocol invitation request, forward a session initiation protocol invitation request having one or more identity headers to a network entity, wherein an identity header in the multiple identity headers includes a signature token and information related to the virtual identities.

[0135] Example 9. The apparatus of any of Examples 1 to 8, wherein at least one signature request is specific to information related to at least one virtual identity and is distinct from a calling party identifier signature request.

[0136] Example 10. The apparatus of any one of Examples 1 to 9, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: send an identity header related to the verified virtual identity associated with the session initiation protocol invite request to the second user equipment.

[0137] Example 11. An apparatus according to any one of Examples 1 to 10, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: send a signature token or other relevant information created during the signing process to a second user device.

[0138] Example 12. An apparatus according to any one of Examples 1 to 11, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive an indication from a second user device or terminal network that the second user device or terminal network is capable of verifying at least one virtual identity.

[0139] Example 13. A device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive a session initiation protocol invitation request having an identity header from a network entity, wherein the identity header includes a signature token or other related information created during a signing process, wherein the session initiation protocol invitation request includes information related to at least one virtual identity and is associated with a first user device; send a verification request to a verification server to verify the information related to the at least one virtual identity, wherein the verification request includes: an identity header including the signature token or other related information created during the signing process, a session initiation protocol invitation request associated with the first user device, and information related to the at least one virtual identity; receive an indication from the verification server whether the information related to the at least one virtual identity is verified; and in response to receiving an indication from the verification server that the information related to the at least one virtual identity is verified, forward the session initiation protocol invitation request and the information related to the at least one virtual identity to a second user device.

[0140] Example 14. The apparatus of Example 13, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive an indication from a verification server that information associated with at least one virtual identity is not verified.

[0141] Example 15. An apparatus according to Example 14, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: in response to receiving an indication from a verification server that information associated with at least one virtual identity is not verified, decide not to forward the session initiation protocol invitation request to the second user device.

[0142] Example 16. An apparatus according to any one of Examples 14 to 15, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: determine whether the identity of an initiator associated with a first user device is verified; in response to receiving an indication from a verification server that information related to at least one virtual identity is not verified, and in response to determining that the identity of the initiator associated with the first user device is verified, decide to forward a session initiation protocol invitation request to a second user device.

[0143] Example 17. An apparatus according to any one of Examples 14 to 16, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: decide to forward a session initiation protocol invitation request to a second user device having an unverified virtual identity in response to receiving an indication from a verification server that information related to at least one virtual identity has not been verified; and send an indication to the second user device that the sent virtual identity has not been verified.

[0144] Example 18. An apparatus according to any one of Examples 13 to 17, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: download a verified virtual identity from a uniform resource locator in response to receiving an indication from a verification server that information associated with at least one virtual identity is verified.

[0145] Example 19. An apparatus according to any one of Examples 13 to 18, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive an indication from a second user device or terminal network that the second user device or terminal network is capable of verifying at least one virtual identity.

[0146] Example 20. A device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request comprises: an identity header containing a signature token or other relevant information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity; determine whether the information associated with the at least one virtual identity is verified based on the identity header and the information associated with the at least one virtual identity; and send an indication to the network entity whether the information associated with the at least one virtual identity is verified.

[0147] Example 21. An apparatus according to Example 20, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: compare the virtual identity information within the identity header with the virtual identity information within the session initiation protocol invitation request; and in response to the virtual identity information within the identity header matching the virtual identity information within the session initiation protocol invitation request, determine that information associated with at least one virtual identity is verified.

[0148] Example 22. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: send a session initiation protocol invitation request to a second user device from a first user device to a network entity, wherein the session initiation protocol invitation request includes information related to at least one virtual identity as part of a signing process, and wherein the apparatus includes the first user device; receive an identity header related to at least one virtual identity from the network entity, the at least one virtual identity being verified; and store an identity header related to at least one verified virtual identity of at least one other session initiation protocol invitation request.

[0149] Example 23. The apparatus of Example 22, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: send at least one other session initiation protocol invite request having an identity header to a network entity.

[0150] Example 24. An apparatus according to any one of Examples 22 to 23, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive a signature token or other related information associated with at least one virtual identity created during a signing process; and store a signature token or other related information associated with at least one virtual identity created during the signing process; and send at least one other session initiation protocol invitation request with the signature token and other related information created during the signing process to a network entity.

[0151] Example 25. A device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity; and download, use, or view information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device.

[0152] Example 26. An apparatus according to Example 25, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive a session initiation protocol invitation request associated with another user device from a terminal network entity in response to a valid identity of an initiator associated with another user device that does not have a verified virtual identity.

[0153] Example 27. An apparatus according to any one of Examples 25 to 26, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive a session initiation protocol invitation request associated with another user device having an unverified virtual identity from a terminal network entity; and receive an indication from the terminal network entity that the received virtual identity is not verified.

[0154] Example 28. A device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: receive at least one signature request from a network entity as part of a signing process, the at least one signature request including information related to at least one virtual identity; and send a response to the at least one signature request to the network entity, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signing process.

[0155] Example 29. The apparatus of Example 28, wherein at least one signature request is based on at least one or more of: a secure phone identity re-access standard, or a signature-based processing of asserted information using a token standard.

[0156] Example 30. An apparatus according to any one of Examples 28 to 29, wherein the information related to at least one virtual identity within at least one signature request includes at least one or more of the following: a virtual identity identifier, or a virtual identity uniform resource identifier, or virtual identity content.

[0157] Example 31. An apparatus according to Example 30, wherein the instructions, when executed by at least one processor, cause the apparatus to perform at least one or more of the following: receiving a virtual identity identifier by reference within at least one signature request, or receiving a virtual identity uniform resource identifier by reference within at least one signature request, or receiving virtual identity content by value within at least one signature request.

[0158] Example 32. The apparatus of Example 31, wherein the instructions, when executed by at least one processor, cause the apparatus to at least perform: in response to receiving the virtual identity identifier by reference within at least one signed request, downloading or retrieving virtual identity content.

[0159] Example 33. An apparatus according to any one of Examples 28 to 32, wherein the instructions, when executed by at least one processor, cause the apparatus to at least: receive one or more signature requests associated with multiple corresponding virtual identities from a network entity, wherein a signature request in the multiple signature requests includes the corresponding virtual identities; and send one or more corresponding responses to the multiple corresponding signature requests to the network entity, wherein the corresponding responses to the corresponding signature requests include corresponding signature tokens or corresponding other relevant information created during the signing process.

[0160] Example 34. The apparatus of any of Examples 28 to 33, wherein at least one signature request is specific to information related to at least one virtual identity and is distinct from a calling party identifier signature request.

[0161] Example 35. A method, comprising: receiving a session initiation protocol invitation request intended for a second user device from a first user device, wherein the session initiation protocol invitation request includes information related to at least one virtual identity; sending at least one signing request to a signing server as part of a signing process, the at least one signing request including information related to at least one virtual identity; receiving a response to the at least one signing request from the signing server, wherein the response to the at least one signing request includes: a signature token or other related information related to the at least one virtual identity created during the signing process; and forwarding the session initiation protocol invitation request with an identity header to a network entity, wherein the identity header includes the signature token or other related information related to the at least one virtual identity created during the signing process.

[0162] Example 36. A method, comprising: receiving a session initiation protocol invitation request having an identity header from a network entity, wherein the identity header includes a signature token or other related information created during a signing process, wherein the session initiation protocol invitation request includes information related to at least one virtual identity and is associated with a first user device; sending a verification request to a verification server to verify the information related to the at least one virtual identity, wherein the verification request includes: an identity header including the signature token or other related information created during the signing process, the session initiation protocol invitation request associated with the first user device, and the information related to the at least one virtual identity; receiving an indication from the verification server whether the information related to the at least one virtual identity is verified; and in response to receiving an indication from the verification server that the information related to the at least one virtual identity is verified, forwarding the session initiation protocol invitation request and the information related to the at least one virtual identity to a second user device.

[0163] Example 37. A method, comprising: receiving a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request includes: an identity header including a signature token or other related information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity; determining whether the information associated with the at least one virtual identity is verified based on the identity header and the information associated with the at least one virtual identity; and sending an indication to the network entity whether the information associated with the at least one virtual identity is verified.

[0164] Example 38. A method comprising: sending a session initiation protocol invitation request to a second user device from a first user device to a network entity, wherein as part of a signing process, the session initiation protocol invitation request includes information related to at least one virtual identity; receiving an identity header related to the at least one virtual identity from the network entity, the at least one virtual identity being verified; and storing an identity header related to the verified at least one virtual identity of at least one other session initiation protocol invitation request.

[0165] Example 39. A method comprising: receiving a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity; and downloading, using, or viewing information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device.

[0166] Example 40. A method comprising: receiving at least one signature request from a network entity as part of a signing process, the at least one signature request including information related to at least one virtual identity; and sending a response to the at least one signature request to the network entity, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signing process.

[0167] Example 41. An apparatus comprising: a component for receiving a session initiation protocol invitation request intended for a second user device from a first user device, wherein the session initiation protocol invitation request includes information related to at least one virtual identity; a component for sending at least one signature request to a signing server as part of a signing process, the at least one signature request including information related to at least one virtual identity; a component for receiving a response to the at least one signature request from the signing server, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signing process; and a component for forwarding the session initiation protocol invitation request with an identity header to a network entity, wherein the identity header includes a signature token or other related information related to the at least one virtual identity created during the signing process.

[0168] Example 42. An apparatus comprising: a component for receiving a session initiation protocol invitation request having an identity header from a network entity, wherein the identity header includes a signature token or other related information created during a signing process, wherein the session initiation protocol invitation request includes information related to at least one virtual identity and is associated with a first user device; a component for sending a verification request to a verification server to verify the information related to at least one virtual identity, wherein the verification request includes: an identity header including the signature token or other related information created during the signing process, a session initiation protocol invitation request associated with the first user device, and information related to at least one virtual identity; a component for receiving an indication from the verification server whether the information related to at least one virtual identity is verified; and a component for forwarding the session initiation protocol invitation request and the information related to at least one virtual identity to a second user device in response to receiving an indication from the verification server that the information related to at least one virtual identity is verified.

[0169] Example 43. An apparatus comprising: a component for receiving a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request comprises: an identity header including a signature token or other relevant information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity; a component for determining whether the information associated with at least one virtual identity is verified based on the identity header and the information associated with at least one virtual identity; and a component for sending an indication to the network entity whether the information associated with at least one virtual identity is verified.

[0170] Example 44. An apparatus comprising: a component for sending a session initiation protocol invitation request to a second user device from a first user device to a network entity, wherein as part of a signing process, the session initiation protocol invitation request includes information related to at least one virtual identity, and wherein the apparatus includes the first user device; a component for receiving an identity header related to at least one virtual identity from the network entity, the at least one virtual identity being verified; and a component for storing identity headers related to at least one verified virtual identity of at least one other session initiation protocol invitation request.

[0171] Example 45. An apparatus comprising: a component for receiving a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity; and a component for downloading, using or viewing information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device.

[0172] Example 46. An apparatus comprising: a component for receiving at least one signature request from a network entity as part of a signing process, the at least one signature request including information related to at least one virtual identity; and a component for sending a response to the at least one signature request to the network entity, wherein the response to the at least one signature request includes: a signature token or other related information related to the at least one virtual identity created during the signing process.

[0173] Example 47. A non-transitory computer-readable medium, comprising program instructions stored thereon, the program instructions being used to perform at least one of the following: receiving a session initiation protocol invitation request intended for a second user device from a first user device, wherein the session initiation protocol invitation request includes information related to at least one virtual identity; sending at least one signing request to a signing server as part of a signing process, the at least one signing request including information related to at least one virtual identity; receiving a response to the at least one signing request from the signing server, wherein the response to the at least one signing request includes: a signature token or other related information related to the at least one virtual identity created during the signing process; and forwarding the session initiation protocol invitation request with an identity header to a network entity, wherein the identity header includes a signature token or other related information related to the at least one virtual identity created during the signing process.

[0174] Example 48. A non-transitory computer-readable medium, comprising program instructions stored thereon, the program instructions being used to perform at least: receiving a session initiation protocol invitation request having an identity header from a network entity, wherein the identity header includes a signature token or other related information created during a signing process, wherein the session initiation protocol invitation request includes information related to at least one virtual identity and is associated with a first user device; sending a verification request to a verification server to verify the information related to the at least one virtual identity, wherein the verification request includes: an identity header including the signature token or other related information created during the signing process, a session initiation protocol invitation request associated with the first user device, and information related to the at least one virtual identity; receiving an indication from the verification server whether the information related to the at least one virtual identity is verified; and in response to receiving an indication from the verification server that the information related to the at least one virtual identity is verified, forwarding the session initiation protocol invitation request and the information related to the at least one virtual identity to a second user device.

[0175] Example 49. A non-transitory computer-readable medium, comprising program instructions stored thereon, the program instructions being used to perform at least: receiving a verification request from a network entity to verify information associated with at least one virtual identity, wherein the verification request comprises: an identity header including a signature token or other relevant information created during a signing process, a session initiation protocol invitation request associated with a first user device, and information associated with at least one virtual identity; determining whether the information associated with the at least one virtual identity is verified based on the identity header and the information associated with the at least one virtual identity; and sending an indication to the network entity whether the information associated with the at least one virtual identity is verified.

[0176] Example 50. A non-transitory computer-readable medium comprising program instructions stored thereon, the program instructions being used to perform at least: sending a session initiation protocol invitation request to a second user device from a first user device to a network entity, wherein as part of a signing process, the session initiation protocol invitation request includes information associated with at least one virtual identity; receiving an identity header associated with at least one virtual identity from the network entity, the at least one virtual identity being verified; and storing an identity header associated with at least one verified virtual identity of at least one other session initiation protocol invitation request.

[0177] Example 51. A non-transitory computer-readable medium comprising program instructions stored thereon, the program instructions being used to perform at least: receiving a session initiation protocol invitation request associated with a user device and a verified virtual identity from a terminal network entity; and downloading, using, or viewing information related to the verified virtual identity using the session initiation protocol invitation request associated with the user device.

[0178] Example 52. A non-transitory computer-readable medium comprising program instructions stored thereon, the program instructions being used to perform at least: receiving at least one signature request from a network entity as part of a signing process, the at least one signature request comprising information associated with at least one virtual identity; and sending a response to the at least one signature request to the network entity, wherein the response to the at least one signature request comprises: a signature token or other related information associated with the at least one virtual identity created during the signing process.

[0179] References to "computers," "processors," and the like should be understood to cover not only computers having different architectures (such as single / multi-processor architectures and sequential or parallel architectures), but also special purpose circuits such as field programmable gate arrays (FPGAs), application specific circuits (ASICs), signal processing devices, and other processing circuit systems. References to computer programs, instructions, code, and the like should be understood to cover software or firmware for programmable processors, such as, for example, the programmable content of hardware devices, whether instructions for a processor, or configuration settings for a fixed function device, gate array, or programmable logic device, and the like.

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

[0181] As used herein, the term "circuitry" may refer to the following: (a) hardware circuit implementations, such as implementations in analog and / or digital circuitry, and (b) combinations of circuitry and software (and / or firmware), such as (as applicable): (i) a combination of (multiple) processors, or (ii) portions of (multiple) processors / software, including (multiple) digital signal processors, software, and memory, which work together to cause the device to perform various functions, and (c) circuits that require software or firmware to operate (even if the software or firmware is not physically present), such as (multiple) microprocessors or portions of (multiple) microprocessors. As another example, as used herein, the term "circuitry" would also cover implementations of only a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. For example, if applicable to the particular element, the term "circuitry" would also cover a baseband integrated circuit or application processor integrated circuit for a mobile phone, or a similar integrated circuit in a server, cell network device, or another network device.

[0182] It should be understood that the above description is illustrative only. Those skilled in the art may design various alternatives and modifications. For example, the features described in the various dependent claims may be combined with each other in any suitable (multiple) combination. In addition, the features from the above-mentioned different example embodiments may be selectively combined into 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.

[0183] The following abbreviations and abbreviations that may appear in the specification and / or drawings are as follows (abbreviations and abbreviations may be appended to each other or other characters using, for example, dashes, hyphens, slashes or numbers, and may not be case sensitive):

[0184] 2D: Two-dimensional

[0185] 3D: Three Dimensions

[0186] 3GPP: Third Generation Partnership Project

[0187] 4G: Fourth Generation

[0188] 5G: Fifth Generation

[0189] 5GC: 5G core network

[0190] A2P: Application to Individual

[0191] AGW: Access Gateway

[0192] AR: Augmented Reality

[0193] AMF: Access and Mobility Management Function

[0194] AS: Application Server

[0195] ASIC: Application-Specific Integrated Circuit

[0196] CD: Compact disc / Computer disc

[0197] CPU: Central Processing Unit

[0198] CSCF: Call Session Control Function

[0199] CU: Central Unit or Centralized Unit

[0200] DAC: Digital Asset Container

[0201] DC: Data Channel

[0202] DCAR: DC Application Repository

[0203] DCSF: DC Signaling Function

[0204] DSP: Digital Signal Processor

[0205] DU: Distributed Unit

[0206] DVD: Digital Versatile Disc

[0207] eNB: Evolved Node B (e.g., LTE base station)

[0208] EN-DC: E-UTRAN New Radio - Dual Connectivity

[0209] en-gNB: A node that provides NR user plane and control plane protocol termination towards the UE and acts as a secondary node in EN-DC

[0210] E-UTRA: Evolved UMTS Terrestrial Radio Access, i.e. LTE radio access technology

[0211] E-UTRAN: E-UTRA Network

[0212] F1: Interface between CU and DU

[0213] FACS: Facial Action Coding System

[0214] FPGA: Field Programmable Gate Array

[0215] glTF: Graphics Library Transmission Format

[0216] gNB: A base station for 5G / NR, i.e., a node that provides NR user plane and control plane protocol termination towards the UE and is connected to the 5GC via the NG interface

[0217] HSS: Home Subscriber Server

[0218] HTTP: Hypertext Transfer Protocol

[0219] IAB: Integrated Access and Backhaul

[0220] IBCF: Interconnect Boundary Control Function

[0221] ID: Identifier

[0222] IETF: Internet Engineering Task Force

[0223] I / F: Interface

[0224] IMPU: IMS Public User Identity

[0225] IMS: IP Multimedia Subsystem

[0226] I / O: Input / Output

[0227] IP: Internet Protocol

[0228] I / S: Inquiry / Service

[0229] ISC: IP Multimedia Subsystem Service Control Interface

[0230] json: JavaScript Object Notation

[0231] LMF: Location Management Function

[0232] LRDD: Link-based Resource Descriptor Discovery

[0233] LTE: Long Term Evolution (4G)

[0234] MAC: Media Access Control

[0235] MDC: Media Data Channel

[0236] MF: Media Function

[0237] MME: Mobility Management Entity

[0238] Mr' / Cr: SIP-based reference point between IMS AS and MRF

[0239] MRF: Media Resource Function

[0240] MRO: Mobility Robustness Optimization

[0241] Ms: Reference point between IBCF and AS for identity proof, identity signature, and signature verification

[0242] NCE: Network Control Element

[0243] NEF: Network Exposure Function

[0244] NF: Network Function

[0245] ng or NG: New Generation

[0246] ng-eNB: Next-generation eNB NG-RAN: Next-generation radio access network

[0247] NR: New Radio

[0248] N / W: Network

[0249] P-Asserted-Identity: Header field containing the URI and optional display name PASSPORT: Personal Assertion Token

[0250] P-CSCF: Proxy Call Session Control Function

[0251] PDA: Personal Digital Assistant

[0252] PDCP: Packet Data Convergence Protocol

[0253] PHY: Physical layer

[0254] PLMN: Public Land Mobile Network

[0255] ppt: PASSporT extension

[0256] RAM: Random Access Memory

[0257] RAN: Radio Access Network

[0258] RAT: Radio Access Technology

[0259] RCD: Enriching Call Data

[0260] Rel: version

[0261] RFC: Request for Comments

[0262] RLC: Radio Link Control

[0263] ROM: Read Only Memory

[0264] RRC: Radio Resource Control

[0265] RU: Radio Unit

[0266] Rx: Receiver or Receive

[0267] SA: System Aspects

[0268] SDAP: Service Data Adaptation Protocol

[0269] SDP: Session Description Protocol

[0270] SGW: Serving Gateway

[0271] SHAKEN: Signature-based processing of assertion information using toKEN

[0272] SIP: Session Initiation Protocol

[0273] SMF: Session Management Function

[0274] SON: Self-Organizing / Optimizing Network

[0275] STI-AS: Secure Telephone Identity Authentication Service

[0276] STIR: Secure Telephone Identity Revisited

[0277] STI-VS: Secure Phone Authentication Service

[0278] Tel: Phone

[0279] TR: Technical Report

[0280] TrGW: Transformation Gateway

[0281] TRP: Transmission Reception Point

[0282] TS: Technical Specification

[0283] Tx, TX: Transmitter or Transmission

[0284] UAV: Unmanned Aerial Vehicle

[0285] UDM: Unified Data Management

[0286] UE: User Equipment (e.g., wireless device, typically a mobile device)

[0287] UI: User Interface

[0288] UMTS: Universal Mobile Telecommunications System

[0289] UPF: User Plane Function

[0290] URI: Uniform Resource Identifier

[0291] URL: Uniform Resource Locator

[0292] URN: Uniform Resource Name

[0293] USB: Universal Serial Bus

[0294] UUID: Universally Unique Identifier

[0295] VR: Virtual Reality

[0296] VRM: Virtual Reality Model

[0297] X2: Network interface between RAN nodes and between RAN and core network

[0298] XML: Extensible Markup Language

[0299] Xn: Network interface between NG-RAN nodes

[0300] XR: Extended Reality

Claims

1. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving a session initiation protocol invite request from a first user device to a second user device, wherein the session initiation protocol invite request includes information related to at least one virtual identity; sending at least one signing request to a signing server as part of a signing process, the at least one signing request including the information related to the at least one virtual identity; receiving a response to the at least one signing request from the signing server, wherein the response to the at least one signing request includes: a signing token or other relevant information associated with the at least one virtual identity created during the signing process; and The session initiation protocol invite request with an identity header is forwarded to a network entity, wherein the identity header includes the signing token or the other relevant information associated with the at least one virtual identity created during the signing process.

2. The apparatus of claim 1 , wherein the at least one signature request is based on at least one or more of the following: Secure Telephone Identity Reaccess Standard, or Signature-based processing of asserted information using token standards.

3. The apparatus according to any one of claims 1 to 2, wherein the information related to the at least one virtual identity in the at least one signing request comprises at least one or more of the following: a virtual identifier, or Virtual Identity Uniform Resource Identifier, or Virtual identity content.

4. The apparatus of claim 1 , wherein the instructions, when executed by the at least one processor, cause the apparatus to at least: In response to the presence of multiple virtual identities in the session initiation protocol invitation request, sending one or more signature requests to the signature server, wherein a signature request in the multiple signature requests includes information related to the virtual identities; and In response to the presence of multiple virtual identities in the session initiation protocol invite request, forwarding the session initiation protocol invite request having one or more identity headers to the network entity, wherein an identity header in the multiple identity headers includes: The signature token, and information related to the virtual identity.

5. The apparatus of claim 1 , wherein the instructions, when executed by the at least one processor, cause the apparatus to perform at least one of the following: sending the identity header associated with the verified virtual identity associated with the session initiation protocol invite request to the second user equipment; sending the signature token or the other relevant information created during the signing process to the second user equipment; or An indication is received from the second user equipment or terminal network that the second user equipment or terminal network is capable of verifying at least one virtual identity.

6. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving, from a network entity, a session initiation protocol invite request having an identity header, wherein the identity header includes a signature token or other relevant information created during a signing process, wherein the session initiation protocol invite request includes information related to at least one virtual identity and is associated with a first user device; sending a verification request to a verification server to verify the information related to the at least one virtual identity, wherein the verification request includes: the identity header including the signing token or other related information created during the signing process, the session initiation protocol invitation request associated with the first user device, and the information related to the at least one virtual identity; receiving an indication from the verification server whether the information associated with the at least one virtual identity is verified; and In response to receiving an indication from the verification server that the information associated with the at least one virtual identity is verified, forwarding the session initiation protocol invitation request and the information associated with the at least one virtual identity to a second user equipment.

7. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving, from a network entity, a verification request for verifying information associated with at least one virtual identity, wherein the verification request comprises: an identity header including a signing token or other relevant information created during a signing process, a session initiation protocol invite request associated with a first user device, and the information associated with the at least one virtual identity; determining, based on the identity header and the information associated with the at least one virtual identity, whether the information associated with the at least one virtual identity is verified; and An indication is sent to the network entity as to whether the information associated with the at least one virtual identity is verified.

8. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: sending, from a first user equipment to a network entity, a session initiation protocol invite request to a second user equipment, wherein the session initiation protocol invite request includes information related to at least one virtual identity as part of a signing process, and wherein the apparatus includes the first user equipment; receiving, from the network entity, an identity header associated with the at least one virtual identity, the at least one virtual identity being verified; as well as The identity header is stored in association with at least one verified virtual identity of at least one other session initiation protocol invite request.

9. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving, from a terminal network entity, a session initiation protocol invite request associated with the user equipment and the verified virtual identity; and The session initiation protocol invitation associated with the user device is used to request downloading, use, or viewing of information related to the verified virtual identity.

10. A device for communication, the device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving at least one signature request from a network entity as part of a signing process, the at least one signature request including information related to at least one virtual identity; as well as A response to the at least one signing request is sent to the network entity, wherein the response to the at least one signing request includes a signing token or other relevant information associated with the at least one virtual identity created during the signing process.

Images