Method for securing rich call data link of third-party identity

Abstract

Example embodiments of the present disclosure provide solutions for securing rich call data (RCD) link (s) of a third-party identity. In an example method, a network device receives, from an originating IMS, an SIP invite message targeting a terminal device, wherein the SIP invite message includes a RCD URL for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information. The proposed solutions can allow IMS network function (s) and / or a terminating UE to authenticate the third party server before retrieve the RCD data from the third party server and build secured communication with the server.

Description

METHOD FOR SECURING RICH CALL DATA LINK OF THIRD-PARTY IDENTITYFIELD

[0001] Example embodiments of the present disclosure generally relate to the field of communication, and in particular, to a network device, a terminal device, a home subscriber server, methods, apparatuses, and a computer readable medium for securing rich call data (RCD) link (s) of a third-party identity.BACKGROUND

[0002] A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. Such communication networks operate in accordance with standards, such as those promulgated by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute) . Examples of such standards include the so-called 5G (5th Generation) standard or other standards promulgated by 3GPP.SUMMARY

[0003] In general, example embodiments of the present disclosure provide solutions for securing rich call data (RCD) link (s) of a third-party identity.

[0004] In a first aspect, there is provided a network device. The network device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to: receive, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0005] In a second aspect, there is provided a terminal device. The terminal device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: receive, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message  targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0006] In a third aspect, there is provided home subscriber server (HSS) . The home subscriber server comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the home subscriber server at least to: store a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0007] In a fourth aspect, there is provided a method at a network device. The method comprises: receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0008] In a fifth aspect, there is provided a method at a terminal device. The method comprises: receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0009] In a sixth aspect, there is provided a method at a home subscriber server (HSS) . The method comprises: storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0010] In a seventh aspect, there is provided an apparatus. The apparatus comprises: means for receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0011] In an eighth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol,  SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0012] In a ninth aspect, there is provided an apparatus. The apparatus comprises: means for storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0013] In a tenth aspect, there is provided a computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0014] In an eleventh aspect, there is provided a computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0015] In a twelfth aspect, there is provided a computer-readable storage medium comprising program instructions. The program instructions, when executed by an apparatus, cause the apparatus to perform at least the following: storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0016] In a thirteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0017] In a fourteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0018] In a fifteenth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to: storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0019] In a sixteenth aspect, there is provided a network device. The network device comprises: a receiving circuitry configured to receive, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0020] In a seventeen aspect, there is provided a terminal device. The terminal device comprises: a receiving circuitry configured to receive from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0021] In an eighteenth aspect, there is provided a home subscriber server (HSS) . The home subscriber server comprises: a storing circuitry configured to store a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0022] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0024] FIG. 1 illustrates an overall reference architecture in which a third-party network is connected to a serving IMS network;

[0025] FIG. 2 illustrates an example workflow of third-party identity signing and verification workflow;

[0026] FIG. 3 illustrates a block diagram of a Signature-based Handling of Asserted information using toKENs (SHAKEN) reference architecture;

[0027] FIG. 4 illustrates a block diagram of a SHAKEN certificate management architecture;

[0028] FIG. 5 illustrates an example network environment in which example embodiments of the present disclosure may be implemented;

[0029] FIGS. 6 to 9 illustrate example process flows in accordance with some example embodiments of the present disclosure;

[0030] FIG. 10 illustrates an example flowchart of a method implemented at a network device according to example embodiments of the present disclosure;

[0031] FIG. 11 illustrates an example flowchart of a method implemented at a terminal device according to example embodiments of the present disclosure;

[0032] FIG. 12 illustrates an example flowchart of a method implemented at home subscriber server according to example embodiments of the present disclosure;

[0033] FIG. 13 illustrates an example simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure; and

[0034] FIG. 14 illustrates an example block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.

[0035] Throughout the drawings, the same or similar reference numerals represent the same or similar elements.DETAILED DESCRIPTION

[0036] Principles of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for  the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0037] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0038] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0039] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0040] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0041] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0042] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and

[0043] (b) combinations of hardware circuits and software, such as (as applicable) :

[0044] (i) a combination of analog and / or digital hardware circuit (s) with software / firmware and

[0045] (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0046] (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (for example, firmware) for operation, but the software may not be present when it is not needed for operation.

[0047] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0048] As used herein, the term “network” , “communication network” or “data network” refers to a network following any suitable communication standards, such as long term evolution (LTE) , LTE-advanced (LTE-A) , wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , wireless fidelity (Wi-Fi) , narrow band Internet of things (NB-IoT) , satellite, enhanced machine-type communication (eMTC) , non-terrestrial communication, terrestrial communication, and so on. Furthermore, the communications between a terminal device and a network device / element in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) , new radio (NR) , IEEE 802.11 communication protocols, and / or any other protocols either currently known or to be  developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0049] As used herein, the term “network device” may refer to a device in a core network or a device performing a core network function. For instance, the network device may refer to a device performing network functions in a IMS network, including but not limited to, an application server (AS) , a call session control function (CSCF) such as proxy-CSCF (P-CSCF) , serving-CSCF (S-CSCF) , and interrogating-CSCF (I-CSCF) , a home subscriber server (HSS) , an IMS access gateway or transport gateway (IMS-AGW / TrGW) . In addition, the network device may refer to a device performing other network functions, such as access and mobility management function (AMF) , session management function (SMF) , and so on.

[0050] The term “network device” may refer also to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) or a transmission and reception point (TRP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a remote radio unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a WiFi (Wireless Fidelity) device, a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology. In the following description, the terms “network device” , “AP device” , “AP” and “access point” may be used interchangeably.

[0051] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a subscriber station (SS) , a portable subscriber station, a mobile station (MS) , a station (STA) or station device, or an access terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment  (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (for example, remote surgery) , an industrial device and applications (for example, a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. In the following description, the terms “station” , “station device” , “STA” , “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

[0052] The term “transceiver” may refer to any device that may be coupled to one or more antennas or antenna ports to wirelessly transmit and / or receive communication signals. The antennas or antenna ports may be the same or different types. The antennas or antenna ports may be located in different positions of an apparatus. One or more transceivers allow the apparatus to communicate with other devices that may be wired and / or wireless. The one or more transceivers may include processors, controllers, radios, sockets, plugs, buffers, or the like circuits to form one or more communication channels to one or more radio frequency units. The one or more transceivers may be integrated in an apparatus or a system, for example a cellular communication apparatus or system, a satellite communication apparatus or system, a WLAN system, or a short ranging system for example, Bluetooth system.

[0053] For illustrative purposes, principles and example embodiments of the present disclosure will be described below with reference to FIGS. 1 to FIG. 14. However, it is to be noted that these embodiments are given to enable the skilled in the art to understand inventive concepts of the present disclosure and implement the solution as proposed herein, and not intended to limit scope of the present application in any way.

[0054] The IP Multimedia Subsystem (IMS) is an architectural framework for delivering IP-based multimedia services. It integrates voice, video, data, and messaging services into an IP network, providing a standardized way for telecommunications operators to offer services across different networks and devices. The IMS enables the convergence of fixed and mobile networks, facilitating seamless communication experiences for users regardless of their location or device. Key components of IMS include session control, multimedia session handling, and service control functions, all of which work together to enable rich multimedia communications over IP networks.

[0055] Rich Call Data (RCD) refers to the additional information associated with voice calls, video calls, and multimedia sessions facilitated by IMS. The IMS enables the transmission and management of this rich call data, enhancing communication experiences beyond traditional voice calls.

[0056] According to 3GPP SA2 (Service and System aspects) working group 2 Technical Report TR 23.700-77, there are scenarios that the third-party subscribers use third-party identities (IDs) , e.g., enterprise employee ID. The IMS network can present the third-party ID to the callee during subsequent calling process. The third-party subscriber can access the IMS network directly or via a SIP trunk as well. From the security point of view, the enhanced IMS network shall be able to support the identity verification and authorization of third-party user during an IMS call.

[0057] However, there could be some security issues. For example, a malicious UE can use third-party IDs belonging to others or forged third-party IDs to initiate IMS calls in the IMS network. Also, the malicious UE can use a third-party ID that no longer belongs to it to initiate IMS calls in the IMS network (e.g., the user uses the third-party ID allocated by a particular company even after leaving it) . As a further example, the third-party ID’s transfer between IMS networks may be manipulated by intermediary network entities. Consequently, the callee may receive a wrong third-party ID.

[0058] To handle those issues, the IMS system shall be able to coordinate with the third-party to verify and authorize the third-party specific user identities, and shall be able to support the integrity protection of the third-party specific user identities on the originating side and terminating side.

[0059] It was suggested to use Ms reference point as described in Technical Specification TS 24.229, Annex V. 2, to request signing of an Identity header field or request verification of a signed assertion in an Identity header field. This enables calling number verification using signature verification and attestation information based on the Secure Telephone Identity Revisited (STIR) or Signature-based Handling of Asserted information using toKENs (SHAKEN) framework. It was suggested to use the existing Ms reference point and procedures for signing and verifying other identities than for example the ones in the P-Asserted-Identity header field which are mainly in the format of a Session Initialization protocol (SIP) URI or Tel URL. For verification of the calling line identity the Interconnection Border Control Function (IBCF) or an IMS application server (IMS-AS) of  the originating network sends a HTTP (HyperText Transfer Protocol) signing request to the signing AS which in turn replies with a Personal Assertion Token (PASSporT) . At the terminating network side, the IBCF or an IMS AS sends a HTTP verification request to the signing AS including the PASSporT which in turn replies with a verification success or failure message. The Ms reference point involves an AS for signing of the Identity at the originating side and another AS for verification of the signed token at the terminating side. It can be extended to enable signing and verification of different kind of identities.

[0060] A mechanism for PASSporT and the associated STIR procedures allows to sign and verify additional data elements including for example: name of the calling person or of an entity, caller ID along with related display information that would be rendered to the called party during alerting, hyperlinks to images, logos, pictures of faces, Avatar representations, or to similar external profile information, information related to the official address of the caller, information related to an organization, or categories / departments of organizations and institutions, possibly other Rich Call Data (RCD) information elements and so on.

[0061] This solution assumes that the types of third-party specific user identities used in IMS are aligned with the existing definitions. Other possible user identity information, e.g., avatar ID can also be added and used for signing and verification. The concrete list of third-party specific user identities is determined during normative phase in alignment with stage 3 and Internet Engineering Task Force (IETF) .

[0062] Example of a Call-Info header field is shown below:

[0063] Call-Info: <https:  / / example. com / qbranch. json>; purpose=jcard.

[0064] Example contents of a URL linked jCard JSON file is:

[0065] Example "rcd" PASSporTs with URL linked jCard JSON file is:

[0066] FIG. 1 illustrates an overall reference architecture in which a third-party network is connected to a serving IMS network. A third-party network 110 comprising an SIP user agent (UA) 112 and IP private branch exchange (PBX) 114 is connected to a serving IMS network 120 via user-network interface (UNI) or network-to-network interface (NNI) interfaces. The server IMS network 120 is connected to a terminating network 130 (e.g., a terminating IMS network) . The serving IMS network 120 may handle outbound SIP calls from the third-party network 110. As shown, the serving IMS network 120 includes a home subscriber server (HSS) 121, a serving / interrogating call session control function (S / I-CSCF) 122, a proxy-CSCF (P-CSCF)  / interconnection border control function (IBCF) 123, one or more application servers (AS) 124, an IMS-access / transit gateway (IMS-AGW / TrGW) 125, and other components.

[0067] There are several options how and where third-party specific user identities are signed and verified, which allow for different deployment scenarios, e.g. using UNI or NNI interface between the third party and the IMS network 120, with different levels of impact to the third-party network 110 and the IMS network 120 and with different levels of trust relationship between both.

[0068] Generally, the HSS 121 stores one or several URL (s) (noted as RCD URL (s) ) pointing to resources on the third-party servers where third party specific user identities and  data are stored. This includes URL (s) pointing to Rich Call Data (RCD URL) as described above or pointing to any other user or Third party specific data (noted as RCD info) , Storing just RCD URL (s) in the HSS 121 avoids potential misusing a third party specific user identity that no longer belongs to a UE to initiate IMS calls (e.g., the user uses the identities allocated by a particular company even after leaving it) , and possibly frequent updates to the data based on request from the third party network 110 and avoids defining third party specific data formats in HSS 121. Nevertheless, the HSS 121 may also store additional data in the subscription of a third-party subscriber like caller name, organization information, job title, and location information. The URL (s) and possibly other data are fetched from the HSS 121 by the IMS AS 124. Optionally, the IMS AS 124 may use the RCD URL received from the HSS 121 to fetch RCD information from a third-party server that can be in the operator domain or external in the third-party network and provide these RCD information or the RCD URL in SIP signaling (SIP INVITE) towards the terminating party. The fetched Rich Call Data information (RCD information or RCD URL) is used by the AS for Signing the RCD PASSporT and by the AS for Verification to verify the signed RCD PASSporT. The SIP header extensions (e.g. Call-Info header) required to transfer third party specific user identity information may be defined by stage 3.

[0069] FIG. 2 illustrates an example workflow of third-party identity signing and verification workflow. In the workflow a UE-A (i.e., the caller) 101 in an originating IMS network uses a third-party server 102 to call a UE-B (i.e., the callee) 109 in a terminating IMS network, where the third party 102 provides rich data for the call, such as multimedia data including text, images, videos and so on. The originating IMS network may at least include a CSCF 103, an IMS AS 104, a HSS 105, and a AS for signing 106. The terminating IMS 107 may at least include a (I- / S-) CSCF and an IMS AS (not shown in FIG. 2) . The workflow further involves an AS for verification 108 which could be included in or external to the terminating IMS 107.

[0070] At step 1, the UE-A 101 in the originating IMS sends a SIP INVITE that contains an IMS Public Identity (IMPU) and / or IMS Private Identity (IMPI) of the calling UE and optional third-party specific user identity (or third-party identity) to the CSCF 103.

[0071] At step 2, the CSCF 103 forwards the SIP INVITE request to the IMS AS 104.

[0072] At step 3, the IMS AS 104 checks with HSS 105 if the calling user (IMPI or IMPU based) is authorized to use the third-party identity based on subscription. The association  between IMPU / IMPI and third-party ID / RCD URL is pre-configured in HSS 105 as subscription data.

[0073] At step 4a, optionally, the IMS AS 104 may retrieve Rich Call Data (RCD) of the third-party identity from HSS 105 together with the IMPU / IMPI. The HSS 105 may return RCD URL pointing to the RCD on a third-party server 102 or the concrete RCD info, e.g., caller name, job title, organization, and location information, etc., based on deployment option.

[0074] At step 4b, if the IMS AS 104 receives RCD URL from step 4a, the IMS AS 104 may retrieve the RCD information from third party server 102 based on the received RCD URL.

[0075] At step 5, the IMS AS 104 calls the AS for Signing 106 (also being called Secure Telephone Identity Authentication Service, STI-AS) to sign the SIP header, e.g. call-info, which including RCD URL or RCD information of the third-party identity.

[0076] At step 6, the AS for Signing 106 returns the signed SIP header (PASSPort  / Token) back to the IMS AS 104.

[0077] At step 7, the IMS-AS 104 and the CSCF 103 forward the SIP INVITE to the terminating IMS subsystem 107, which including signed RCD URL or RCD information of the third-party identity.

[0078] At step 8, the terminating IMS 107 (including an IMS AS and a CSCF which are not shown for brevity) invokes the AS for verification 108 (also being called Secure Telephone Identity Verification Service, STI-VS) to verify the signed RCD URL or RCD information.

[0079] At step 9, if verification is successful, optionally the terminating IMS AS 107 may retrieve RCD information of the third-party identity from the third party server 102 if RCD URL pointing to the RCD information is received.

[0080] At step 10, the terminating IMS 107 sends SIP INVITE to terminating UE-B 109 in the terminating IMS which including the RCD information if verification is successful in step 8.Otherwise, the terminating IMS 107 may send SIP INVITE to the UE-B 109 without including RCD.

[0081] At step 10a, if the RCD information of the third-party identity is not retrieved by the terminating IMS AS 107 in step 9, the UE-B 109 may retrieve the RCD information from the third party server 102.

[0082] At step 11, the terminating UE-B sends 18X / 200 to the terminating IMS subsystem, the originating IMS subsystem and to the UE-A 101.

[0083] FIG. 3 illustrates a block diagram of a Signature-based Handling of Asserted information using toKENs (SHAKEN) reference architecture. In FIG. 3, the STI-AS in source IMS gets private key from Secure Key Store (SKS) and use the private key to sign calling information. On terminate IMS side, the STI-VS retrieves public key corresponding to the signing private key from STI certificate repository (STI-CR) , and verifies the signature sent from the source IMS.

[0084] FIG. 4 illustrates a block diagram of a SHAKEN certificate management architecture. In FIG. 4, both SKS / STI-AS in source IMS side and STI-CR in terminate IMS side connect to Service Provider Key Management Server (SP-KMS) , then the STI-CR is able to retrieve public key of the same certificate for the private key used by STI-AS. Then STI-VS in terminate IMS can get certificate from STI-CR via https, and use the certificate to verify signature signed by STI-AS. In this SHAKEN framework, STI-VS in terminate IMS is the server which is preconfigured with address / URL of STI-CR and root certificate to verify https of the STI-CR URL.

[0085] FIG. 5 illustrates an example network environment in which example embodiments of the present disclosure may be implemented. In the present disclosure, as the line 150 shown in FIG. 5, to access RCD provided by the third-party server based on secured RCD URL, the UE-B needs root certificate for the third-party server to verify the https of RCD URL. To reuse SHAKEN Certificate Management Architecture to provision certificate of third-party server to the terminate UE-B, it is implied that all third-party server needs to support SHAKEN Certificate Management Architecture for the certificate used to sign https of RCD URL and the UE-B needs to be provisioned with root certificate of STI-CRs corresponding to each third-party server. It is further implied that, afterwards, the UE-B needs to retrieve certificates to sign RCD URLs from the STI-CRs. Instead of the RCD content being sent to the terminate IMS and UE-B, the RCD address (or URL of RCD) may be sent to terminate IMS and / or UE-B, and the terminate IMS and / or UE-B need to retrieve RCD content from its provider, i.e., the third-party data store.

[0086] One problem is how to validate certificate of https-based RCD URL at the UE-B / Term IMS. An example of https-based RCD URL is below.

[0087] Call-Info: <https:  / / example. com / qbranch. json>; purpose=jcard.

[0088] Example contents of a URL linked jCard JSON file:

[0089] Https is always enabled to protect the RCD information transmitted via internet, also allow the RCD consumer to authenticate the producer. However, how to get the root certificate or fingerprint of the certificate to validate the https link of RCD provided by the third-party application server, has not been studied yet. Especially it could be challenging for UE-B to get this information. Therefore, a solution is required to validate and access the secured link.

[0090] Referring back to FIG. 2, the terminate IMS should verify the signature generated in step 5 and 6 to make sure the authenticity of the third-party specific user identity and corresponding RCD information included in the SIP invitation message received in step 7. In that case, the certificate used to sign the third-party specific user identity is issued to the STI AS by a well-known Certificate Authority (CA) , then the STI VS could verify the signature with the preconfigured CA certificate. If the verification is successful, the STI VS can confirm with the terminate IMS network function (e.g., IMS AS) that the third-party specific user identity and corresponding RCD information is trusted. After that, the terminate IMS NF could retrieve the RCD content from the third-party server based on secured RCD URL, or forward RCD URL or RCD content to the terminating UE. Then the terminating UE may retrieve the RCD content based on the secured RCD URLs. In this case, the terminating IMS NF and / or UE need the way to get the root certificate of a CA who issued the certificate to protect https of RCD to the third-party server, then authenticate the third-party server (i.e., the RCD information provider) with the root certificate when access the secured RCD URL.

[0091] FIG. 6 illustrates an example process flow in accordance with some example embodiments of the present disclosure. In FIG. 6, the https of the RCD URL or the provider  of the RCD URL or RCD information is verified by the terminating IMS NF (e.g., IMS AS) 207.

[0092] At step 0, the HSS 205 may store the URL of the RCD and also stores trust information, e.g., a root certificate, used to sign the certificate (s) of https of the RCD URL / URIs.

[0093] At step 1, the UE-A 201 in the originating IMS sends a SIP INVITE that contains the IMPU of the calling UE and optional third-party specific user identity (or third-party identity) .

[0094] At step 2, the CSCF 203 forwards the SIP request to the IMS AS 204.

[0095] At step 3, the IMS AS 204 checks with HSS 205 if the calling user (e.g., using IMPI or IMPU) is authorized to use the third-party identity based on subscription. The association between IMPU / IMPI and third-party ID / RCD URL is pre-configured in HSS 205 as subscription data.

[0096] At step 4a, the IMS AS 204 may optionally retrieve Rich Call Data (RCD) information of the third-party identity received from HSS 205 together with the IMPU / IMPI. The HSS 205 may return RCD URL pointing to the RCD on a third-party server 202 or the concrete RCD information, like caller name, job title, organization, and location information, etc., and also includes the CA root certificate used to sign the certificate (s) of https of the RCD URL / URIs, based on deployment option. In some embodiments, the RCD information may include additional RCD URL (s) .

[0097] Alternatively, the IMS AS 204 may retrieve the RCD data from the third-party server 202, then the third-party server 202 may provide RCD data and the root certificate associated with third-party server 202.

[0098] At step 4b, if the IMS AS 204 receives RCD URL from step 4a, the IMS AS 204 may retrieve the RCD information from third party server 202 based on the received RCD URL along with the root certificate to validate the RCD URL.

[0099] At step 5, the IMS AS 204 may call the AS for signing 206 to sign the SIP header, e.g., call-info, which including RCD URL or RCD information of the third-party identity.

[0100] At step 6, the AS for signing 206 returns the signed SIP header back to the IMS AS 204.

[0101] At step 7, the IMS-AS 204 and the CSCF 203 may forward the SIP INVITE to the terminating IMS 207 which including signed RCD URL or RCD information of the third-party identity along with the certificate for verification purposes.

[0102] At step 8a, the terminating IMS 207 (e.g., a terminating IMS AS or a CSCF) invokes the AS for verification 208 to verify the signed RCD URL or RCD information. In some embodiments, at step 8b, the terminating IMS 207 may configure the root certificate as trust anchor for that UE and for that particular RCD URL. For example, the terminating IMS 207 may store the root certificate in a local cache of the terminating IMS AS.

[0103] At step 9, if the verification is successful, optionally the terminating IMS AS may retrieve RCD information of the third-party identity from third party server 202 if RCD URL pointing to the RCD information is received and after the validation of the certificate of the https of the third-party server 202. In some embodiments, the terminating IMS 207 may create a transport layer security (TLS) tunnel with the third-party server 202 based on the RCD URL. The third-party server 202 may provide server certificate to terminating IMS 207. The terminating IMS 207 can validate the server certificate based on the root certificate received in previous steps.

[0104] At step 10, the terminating IMS 207 may send the SIP INVITE to the terminating UE-B 209 which including the RCD information if verification is successful in step 8. Otherwise, the terminating IMS 207 may send the SIP INVITE message to the terminating UE-B 209 without including RCD.

[0105] At step 11, the terminating UE-B 209 sends a response to the SIP INVITE to originating IMS subsystem and to the originating UE-A 201. In some embodiments, the response may include an information element to indicate that the root certificate with an expiration time has been cached. Based on this information, the IMS AS 204 may set a flag to indicate whether the root certificate at the terminating IMS 207 has expired. Before the expiry of the root certificate, the terminating IMS AS 207 does not need to obtain new trust information from the HSS 205 and send it to the IMS AS 207. The flag may also be set at the terminating IMS.

[0106] FIG. 7 illustrates an example process flow in accordance with some example embodiments of the present disclosure. In FIG. 7, the https of the RCD URL or the provider of the RCD URL or RCD information is verified by the terminating UE-B 209.

[0107] At step 0, the HSS 205 stores the URL of the RCD and also stores trust information, e.g., the root certificate, used to sign the certificate (s) of https of the RCD URL / URIs.

[0108] At step 1, the UE-A 201 in the originating IMS sends a SIP INVITE that contains the IMPU of the calling UE and optional third-party specific user identity (or third-party identity) to the CSCF 203.

[0109] At step 2, the CSCF 203 forwards the SIP INVITE to the IMS AS 204.

[0110] At step 3, the IMS AS 204 checks with the HSS 205 if the calling user (IMPI or IMPU based) is authorized to use the third-party identity based on subscription. The association between IMPU / IMPI and third-party ID / RCD URL is pre-configured in HSS 205 as subscription data.

[0111] At step 4a, the IMS AS may optionally retrieve Rich Call Data (RCD) of the third-party identity from the HSS 205 together with the IMPU / IMPI. The HSS 205 may return the RCD URL pointing to the RCD on a third-party server 202 or the concrete RCD information, such as caller name, job title, organization, and location information, etc., and also includes the CA root certificate used to sign the certificate (s) of https of the RCD URL / URIs, based on deployment option.

[0112] Alternatively, the IMS-AS 204 may retrieve the RCD data from third party server 202, then the third-party server 202 may provide the RCD data and root certificate associated with third party server 202.

[0113] At step 4b, if the IMS AS 204 receives RCD URL (s) from step 4a, the IMS AS 204 may retrieve the RCD information from the third-party server 202 based on the received RCD URL(s) along with the root certificate to validate the RCD URL.

[0114] At step5, the IMS AS 204 calls the AS for signing 206 to sign the SIP header, e.g., call-info, which including RCD URL or RCD information of the third-party identity.

[0115] At step 6, the AS for signing 206 returns the signed SIP header back to the IMS AS 204.

[0116] At step 7, the IMS-AS 204 and the CSCF 203 may forward the SIP INVITE message to the terminating IMS 207 which including signed RCD URL or RCD information of the third-party identity along with the certificate for verification purposes.

[0117] At step 8, the terminating IMS subsystem 207 (e.g., terminating IMS AS, CSCF) invokes the AS for verification 208 to verify the signed RCD URL or RCD information.

[0118] At step 9a, the terminating IMS 207 sends SIP INVITE message to the terminating UE-B 209 without including RCD information, and the root certificate is shared with the UE-B 209. At step 9b, the UE-B 209 may configure the root certificate as trust anchor, for example, stores it in the local cache. Later, at step 9c, the full RCD information may be fetched from the third-party server 202, after the validation of the certificate of the https of the third-party server 202. In some embodiments, the terminating UE-B 209 may create a TLS tunnel with the third-party server 202 based on the RCD URL. The third-party server 202 may provide the server certificate to the terminating UE-B 209. The terminating UE-B 209 may validate the server certificate based on the root certificate received in previous steps.

[0119] At step 10, the terminating UE-B 209 sends a response to the SIP INVITE to originating IMS subsystem and to the originating UE. In some embodiments, the response may include an information element to indicate that the root certificate with an expiration time has been cached. Based on this information, the IMS AS 204 may set a flag to indicate whether the root certificate at the terminating IMS AS 207 has expired. Before the expiry of the root certificate, the terminating IMS AS 207 does not need to obtain new trust information from the HSS 205 and send it to the IMS AS 207 and further to the UE-B 209. The flag may also be set at the terminating IMS.

[0120] FIG. 8 illustrates an example process flow in accordance with some example embodiments of the present disclosure. In FIG. 8, the https of the RCD URL or the provider of the RCD URL or RCD information is verified by both of the terminating IMS AS 207 and the terminating UE-B 209.

[0121] At step 0, the HSS 205 stores the URL of the RCD and also stores the trust information, e.g., the root certificate, used to sign the certificate (s) of https of the RCD URL / URIs.

[0122] At step 1, the UE-A 201 in the originating IMS sends a SIP INVITE that contains the IMPU of the calling UE and optional third-party specific user identity (or third-party identity) to the CSCF 203.

[0123] At step 2, the CSCF 203 forwards the SIP INVITE to the IMS AS 204.

[0124] At step 3, the IMS AS 204 checks with the HSS 205 if the calling user (IMPI or IMPU based) is authorized to use the third-party identity based on subscription. The association between IMPU / IMPI and third-party ID / RCD URL is pre-configured in the HSS 205 as subscription data.

[0125] At step 4a, the IMS AS 204 may optionally retrieve Rich Call Data (RCD) information of the third-party identity received from the HSS 205 together with the IMPU / IMPI. The HSS 205 may return RCD URL (s) pointing to the RCD on a third-party server 202 or the concrete RCD info, like caller name, job title, organization, and location information, etc., and also includes the root certificate used to sign the certificate (s) of https of the RCD URL / URIs, based on deployment option.

[0126] At step 4b, if the IMS AS 204 receives the RCD URL (s) from step 4a, the IMS AS 204 may retrieve the RCD information from the third-party server 202 based on the received the RCD URL (s) along with the root certificate to validate the RCD URL (s) .

[0127] At step 5, the IMS AS 204 may call the AS for signing 206 to sign the SIP header, e.g., call-info, which including RCD URL or RCD information of the third-party identity.

[0128] At step 6, the AS for signing 206 returns the signed SIP header back to the IMS AS 204.

[0129] At step 7, the IMS-AS 204 and the CSCF 203 may forward the SIP INVITE to the terminating IMS 207 which including signed RCD URL (s) or RCD information of the third-party identity along with the certificate for verification purposes.

[0130] At step 8, the terminating IMS 207 (e.g., the terminating IMS AS, CSCF) invokes the AS for verification 208 to verify the signed RCD URL or RCD information. At step 8b, the terminating IMS 207 may configure the root certificate as trust anchor, for example, by storing the root certificate in its local cache.

[0131] At step 9a, if verification of signature is successful, the terminating IMS AS may optionally retrieve partial RCD information of the third-party identity from third party server 202 if the RCD URL pointing to the RCD information is received after validating the https of the RCD URL with the root certificate. At step 9b, the terminating IMS AS sends SIP INVITE to the terminating UE-B 209 with the partial RCD included, and the root certificate may be shared with the terminating UE-B 209. At step 9c, the UE-B 209 may store the root certificate in the local cache and configure it as the trust anchor. Later, at step 9d, the remaining partial RCD information may be fetched from the third-party server 202 by UE-B 209, only after the validation of the certificate of the https of the third-party server.

[0132] In some embodiments, the terminating IMS 207 and the UE-B 209 may create the TLS tunnels with the third-party server 202 based on the RCD URL (s) . The third-party server 202 may provide server certificate to terminating IMS 207 and the UE-B 209. The  terminating IMS 207 and the UE-B 209 can validate the server certificate based on the root certificate received in previous steps.

[0133] At step 10, the terminating UE-B sends a response to the SIP INVITE to originating IMS subsystem and to the originating UE. In some embodiments, the response may include an information element to indicate that the root certificate with an expiration time has been cached. Based on this information, the IMS AS 204 may set a flag to indicate whether the root certificate at the terminating IMS 207 has expired. Before the expiry of the root certificate, the terminating IMS AS 207 does not need to obtain new trust information from the HSS 205 and send it to IMS AS 207 and further to the UE-B 209. The flag may also be set at the terminating IMS.

[0134] FIG. 9 illustrates example process flows in accordance with some example embodiments of the present disclosure. In FIG. 9, a fingerprint is used as trust information instead of or in addition to the root certificate. The fingerprint may be generated based on a certificate of the provider of the RCD URL or RCD information.

[0135] At step 1, the UE-A 201 in the originating IMS sends a SIP INVITE that contains the IMPU of the calling UE and optional third-Party specific user identity (or third-party identity) to the CSCF 203.

[0136] At step 2, the CSCF 203 forwards the SIP INVITE to the IMS AS 204.

[0137] At step 3, the IMS AS 204 checks with the HSS 205 if the calling user (IMPI or IMPU based) is authorized to use the third-party identity based on subscription. The association between IMPU / IMPI and third-party ID / RCD URL is pre-configured in the HSS 205 as subscription data.

[0138] At step 4a, the IMS AS 204 may optionally retrieve Rich Call Data (RCD) information of the third-party identity received from the HSS 205 together with the IMPU / IMPI. The HSS 205 may return RCD URL (s) pointing to the RCD on the third-party server 202 or the concrete RCD information, like caller name, job title, organization, and location information, etc., based on deployment option.

[0139] At step 4b, if the IMS AS 204 receives the RCD URL (s) from step 4a, the IMS AS 204 may retrieve the RCD information from the third-party server 202 based on the received RCD URL and also the fingerprint is fetched from third-party server 202.

[0140] At step 5, the IMS AS 204 calls the AS for signing 206 to sign the SIP header, e.g., call-info, which including RCD URL or RCD information of the third-party identity.

[0141] At step 6, the AS for signing 206 returns the signed SIP header back to the IMS AS 204.

[0142] At step 7, the IMS-AS 204 and the CSCF 203 may forward the SIP INVITE to the terminating IMS 207 which including signed RCD URL (s) or the RCD information of the third-party identity along with the fingerprint for verification purposes.

[0143] At step 8, the terminating IMS 207 (e.g., the terminating IMS AS, CSCF) invokes the AS for verification 208 to verify the signed RCD URL or RCD information.

[0144] At step 9a, the terminating IMS 207 may send the SIP INVITE to terminating UE 209 by including the RCD URL (s) and the fingerprint. At step 9b, the terminating UE-B 209 may store and configure the fingerprint as trust information. Later, at step 9c, after the validation with the fingerprint is performed for the https of the third-party server, the full RCD may be fetched from third party server 202. In some embodiments, the terminating UE-B 209 may create the TLS tunnel with third party server 202 based on the RCD URL (s) . The third-party server 202 may provide its server certificate to the terminating UE-B 209. The terminating UE-B 209 can validate the server certificate based on fingerprint received in previous steps.

[0145] At step 10, the terminating UE-B sends a response to the SIP INVITE to originating IMS subsystem and to the originating UE. In some embodiments, the response may include an information element to indicate that the fingerprint with an expiration time has been cached. The originating IMS 203 and the terminating IMS 207 may set a flag based on this information element.

[0146] For the workflow described with reference to FIGS. 6 to 9, the terminating IMS and UE-B may save or cache received trust information (root certification or fingerprint) of RCD URL (s) and send indication in the SIP response, the indication may include the expiration time of the trust information cached in the terminating IMS and UE. The originating and terminating IMS may set flag on corresponding RCD URL (s) with related expiration time based on the indication in the response.

[0147] The originating and terminating IMS may check the flag before send SIP INVITE with RCD URL (s) to the terminating IMS / UE-B, if the flag indicates the root certificate of the URL is cached in the terminating IMS / UE-B without expiration, the originating and / or  terminating IMS may not include root certificate in the SIP message to the terminating IMS / UE-B. If the terminating IMS and / or the UE-B received RCD URL (s) without corresponding root certificate in SIP message, it will retrieve the root certificate from local cache based in information such as public land mobile network (PLMN) ID in IMPU or fully qualified domain name (FQDN) in the RCD URL (s) .

[0148] In some embodiments, the terminating IMS may relay received the RCD information, the root certificate / fingerprint in a diverted call. For example, UE-Acalls UE B, and UE-B forwards the call to UE-C. Then UE-B’s network may relay this info to UE-CS’s network.

[0149] In view of above, embodiments of the disclosure provide solutions to provision trust information, such as root certificate (s) and fingerprint, used to access secured RCD link (s) to the IMS network function (s) and  / or terminating UE, and allow the IMS network function (s) and  / or terminating UE to authenticate the third party server (a.k.a RCD provider) before retrieve the RCD data from the third party server and build secured communication with the server.

[0150] FIG. 10 illustrates a flowchart of an example method 300 implemented at a network device in accordance with some other embodiments of the present disclosure. The method 1000 may be performed by a network function in the terminating IMS 207 described in FIGS. 6 to 9.

[0151] At block 1010, the network device receives, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0152] In some embodiments, the RCD URL may comprise a signed RCD URL or a URL included in signed RCD information.

[0153] In some embodiments, the network device may apply the trust information after the signed RCD URL or the signed RCD information has been verified.

[0154] In some embodiments, the trust information includes at least a root certificate of a Certificate Authority which issues a certificate of the provider.

[0155] In some embodiments, the network device may store, at the network device, the root  certificate as a trust anchor.

[0156] In some embodiments, the network device may verify the certificate of the provider based on the root certificate; receive, after the certificate of the provider is successfully verified, RCD information from the provider based on the RCD URL; and forward the SIP invite message with the received RCD information to the terminal device.

[0157] In some embodiments, the RCD information is a part of RCD contents corresponding to the RCD URL, and the network device may transmit the root certificate and the part of the RCD contents to the terminal device.

[0158] In some embodiments, the network device may forward the SIP invite message including the RCD URL and the trust information to the terminal device.

[0159] In some embodiments, the trust information includes a fingerprint of a certificate of the provider of the RCD URL or the RCD information.

[0160] In some embodiments, the network device may further verify a certificate of the provider based on the fingerprint; and receive, after the certificate of the third-party server is successfully verified, RCD information based on the RCD URL.

[0161] In some embodiments, the network device may further receive, from the originating IMS, a second SIP invite message including at least one RCD URL for the third-party identity; and based on a determination that the second SIP invite message is received without the trust information, retrieve the trust information from a local cache.

[0162] In some embodiments, the network device may further transmit a response to the SIP invite message, the response including an indication to indicate that the trust information is cached with an expiration time.

[0163] In some embodiments, the network device may further relay the RCD URL and the trust information to a terminating IMS in a diverted call.

[0164] In some embodiments, the network device comprises an IMS application server, IMS AS.

[0165] FIG. 11 illustrates another flowchart of an example method implemented at a terminal device in accordance with some embodiments of the present disclosure. The method 1100 may be performed by the terminating UE-B 209 described with reference to FIGS. 6 to 9.

[0166] At block 1110, the terminal device receives, from a terminating IP multimedia  subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0167] In some embodiments, the RCD URL comprises a signed RCD URL or a URL included in signed RCD information.

[0168] In some embodiments, the trust information includes at least a root certificate used to of a Certificate Authority which issues a certificate of the provider.

[0169] In some embodiments, the terminal device may further store, at the terminal device, the root certificate as a trust anchor.

[0170] In some embodiments, the terminal device may further verify the certificate of the provider based on the root certificate; and receive, after the certificate of the provider is successfully verified, RCD information from the provider based on the RCD URL.

[0171] In some embodiments, the root certificate is received together with a part of RCD contents corresponding to the RCD URL, and the RCD information received from the third party is the remaining of the RCD contents.

[0172] In some embodiments, the trust information includes a fingerprint of a certificate of the provider of the RCD URL or the RCD information.

[0173] In some embodiments, the terminal device may further verify a certificate of the third-party server based on the fingerprint; and receive, after the certificate of the third-party server is successfully verified, RCD information based on the RCD URL.

[0174] In some embodiments, the terminal device may further transmit a response to the SIP invite message, the response including an indication to indicate that the trust information is cached with an expiration time.

[0175] In some embodiments, the terminal device may further receive, from the terminating IMS, a second SIP invite message including at least one RCD URL for the third-party identity; and based on a determination that the second SIP invite message is received without the trust information, retrieve the trust information from a local cache.

[0176] FIG. 12 illustrates another flowchart of an example method implemented at a home subscriber server (HSS) in accordance with some embodiments of the present disclosure. The method 1200 may be performed by the HSS 205 described with reference to FIGS. 6 to 9.

[0177] At block 1210, the HSS stores a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0178] In some embodiments, the HSS may receive, from an IMS AS, a request to validate a third-party identity; and transmit, after the third-party identity is successfully validated, the RCD URL for the third-party identity and trust information to the IMS AS.

[0179] In some embodiments, the trust information comprises at least a root certificate of a Certificate Authority which issues a certificate of the provider.

[0180] In some embodiments, an apparatus capable of performing the method 1000 (for example, a network function in a terminating IMS) may comprise means for performing the respective steps of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0181] In some example embodiments, the apparatus comprises: means for receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0182] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 1000. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0183] In some embodiments, an apparatus capable of performing the method 1100 (for example, the UE 209) may comprise means for performing the respective steps of the method 1100. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0184] In some example embodiments, the apparatus comprises: means for receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0185] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 1100. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0186] In some embodiments, an apparatus capable of performing the method 1200 (for example, the HSS 205) may comprise means for performing the respective steps of the method 1200. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0187] In some example embodiments, the apparatus comprises: means for storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.

[0188] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 1200. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0189] FIG. 13 illustrates a simplified block diagram of a device 1300 that is suitable for implementing some example embodiments of the present disclosure. The device 1300 may be provided to implement a communication device, for example, the network device or the terminal device as described above. As shown, the device 1300 includes one or more processors 1310, one or more memories 1320 coupled to the processor 1310, and one or more communication modules 1340 coupled to the processor 1310.

[0190] The communication module 1340 is for bidirectional communications. The communication module 1340 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

[0191] The processor 1310 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1300 may have multiple processors, such as an application specific integrated circuit chip that is slaved in  time to a clock which synchronizes the main processor.

[0192] The memory 1320 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1324, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 1322 and other volatile memories that will not last in the power-down duration.

[0193] A computer program 1330 includes computer executable instructions that are executed by the associated processor 1310. The program 1330 may be stored in the ROM 1324. The processor 1310 may perform any suitable actions and processing by loading the program 1330 into the RAM 1322.

[0194] The embodiments of the present disclosure may be implemented by means of the program 1330 so that the device 1300 may perform any process of the disclosure as discussed with reference to FIGS. 10 to 12. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0195] In some example embodiments, the program 1330 may be tangibly contained in a computer-readable medium which may be included in the device 1300 (such as in the memory 1320) or other storage devices that are accessible by the device 1300. The device 1300 may load the program 1330 from the computer-readable medium to the RAM 1322 for execution. The computer-readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.

[0196] FIG. 14 illustrates a block diagram of an example of a computer-readable medium 1400 in accordance with some example embodiments of the present disclosure. The computer-readable medium 1400 has the program 1330 stored thereon. It is noted that although the computer-readable medium 1400 is depicted in form of CD or DVD in FIG. 14, the computer-readable medium 1400 may be in any other form suitable for carry or hold the program 1330.

[0197] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other  computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0198] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or methods 1000, 1100, or 1200 as described above with reference to FIGS. 10 to 12. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0199] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0200] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer-readable medium, and the like.

[0201] The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor  system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0202] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0203] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A network device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to:receive, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.2.The network device of claim 1, wherein the RCD URL comprises a signed RCD URL or a URL included in signed RCD information.3.The network device of claim 2, wherein the network device is further caused to:apply the trust information after the signed RCD URL or the signed RCD information has been verified.4.The network device of any of claims 1 to 3, wherein the trust information includes at least a root certificate of a Certificate Authority which issues a certificate of the provider.5.The network device of claim 4, wherein the network device is further caused to:store, at the network device, the root certificate as a trust anchor.6.The network device of claim 5, wherein the network device is further caused to:verify the certificate of the provider based on the root certificate;receive, after the certificate of the provider is successfully verified, RCD information from the provider based on the RCD URL; andforward the SIP invite message with the received RCD information to the terminal device.7.The network device of claim 6, wherein the RCD information is a part of RCD contents corresponding to the RCD URL, and the network device is further caused to:transmit the root certificate and the part of the RCD contents to the terminal device.8.The network device of claim 1, wherein the network device is caused to:forward the SIP invite message including the RCD URL and the trust information to the terminal device.9.The network device of any of claims 1 to 3, wherein the trust information includes a fingerprint of a certificate of the provider of the RCD URL or the RCD information.10.The network device of claim 9, wherein the network device is further caused to:verify a certificate of the provider based on the fingerprint; andreceive, after the certificate of the third party server is successfully verified, RCD information based on the RCD URL.11.The network device of any of claims 1 to 10, wherein the network device is further caused to:receive, from the originating IMS, a second SIP invite message including at least one RCD URL for the third-party identity; andbased on a determination that the second SIP invite message is received without the trust information, retrieve the trust information from a local cache.12.The network device of any of claims 1 to 11, wherein the network device is further caused to:transmit a response to the SIP invite message, the response including an indication to indicate that the trust information is cached with an expiration time.13.The network device of any of claims 1 to 12, wherein the network device is further caused to:relay the RCD URL and the trust information to a terminating IMS in a diverted call.14.The network device of any of claims 1 to 13, wherein the network device comprises an IMS application server, IMS AS.15.A terminal device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to:receive, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.16.The terminal device of claim 15, wherein the RCD URL comprises a signed RCD URL or a URL included in signed RCD information.17.The terminal device of claim 15 or 16, wherein the trust information includes at least a root certificate used to of a Certificate Authority which issues a certificate of the provider.18.The terminal device of claim 17, wherein the terminal device is further caused to:store, at the terminal device, the root certificate as a trust anchor.19.The terminal device of claim 18, wherein the terminal device is further caused to:verify the certificate of the provider based on the root certificate; andreceive, after the certificate of the provider is successfully verified, RCD information from the provider based on the RCD URL.20.The terminal device of claim 19, wherein the root certificate is received together with a part of RCD contents corresponding to the RCD URL, and the RCD information received from the third party is the remaining of the RCD contents.21.The terminal device of any of claims 15 or 16, wherein the trust information includes a fingerprint of a certificate of the provider of the RCD URL or the RCD information.22.The terminal device of claim 21, wherein the terminal device is further caused to:verify a certificate of the third party server based on the fingerprint; andreceive, after the certificate of the third party server is successfully verified, RCD information based on the RCD URL.23.The terminal device of any of claims 15 to 22, wherein the terminal device is further caused to:transmit a response to the SIP invite message, the response including an indication to indicate that the trust information is cached with an expiration time.24.The terminal device of any of claims 15 to 23, wherein the terminal device is further caused to:receive, from the terminating IMS, a second SIP invite message including at least one RCD URL for the third-party identity; andbased on a determination that the second SIP invite message is received without the trust information, retrieve the trust information from a local cache.25.A home subscriber server comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the home subscriber server at least to:store a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.26.The home subscriber server of claim 25, wherein the home subscriber server is further caused to:receive, from an IMS AS, a request to validate a third-party identity; andtransmit, after the third party identity is successfully validated, the RCD URL for the third-party identity and trust information to the IMS AS.27.The home third party server of claim 26, wherein the trust information comprise at least a root certificate of a Certificate Authority which issues a certificate of the provider.28.A method comprising:receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.29.A method comprising:receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.30.A method comprising:storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.31.An apparatus, the apparatus comprising:means for receiving, from an originating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting a terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.32.An apparatus, the apparatus comprising:means for receiving, from a terminating IP multimedia subsystem, IMS, a session initiation protocol, SIP, invite message targeting the terminal device, wherein the SIP invite message includes a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.33.An apparatus comprising:means for storing a rich call data, RCD, universal resource locator, URL, for a third-party identity and trust information used to verify a provider of the RCD URL or corresponding RCD information.34.A computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform the method of any of claims 28-30.35.A computer program product comprising instructions that, when executed by an apparatus, cause the apparatus to perform the method of any of claims 28-20.

Images