System and method for multiple user authentication and identification in cross-domain communications

Abstract

A method and system for cross-domain authentication of a device of a first domain and one or more users of a second domain are provided. An identity manager of the first domain generates identification information based on temporary IDs of the device and the user IDs of one or more users. The identity information along with credentials or certificates is used for authentication of a user of one or more users and the device via a first authenticator of the first domain and a second authenticator of the second domain, while the real ID of the device is secured with the identity manager.

Description

SYSTEM AND METHOD FOR MULTIPLE USER AUTHENTICATION AND IDENTIFICATION IN CROSS-DOMAIN COMMUNICATIONS

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to United States Provisional Patent Application No. 63 / 668, 006, filed July 5, 2024, the contents of which are incorporated herein by reference.TECHNICAL FIELD

[0003] The present disclosure pertains to the field of communication networks, and in particular to systems and methods for cross-domain authentication in communication networks.BACKGROUND

[0004] Authentication of users and devices across different domains of a network may pose security risks as sensitive identifying information is shared between domains. Existing authentication methods of a device and a digital user across different domains in the network, such as those detailed in the Third Generation Partnership Project (3GPPTM) Technical Specifications, assume that each domain knows the unique ID (SUPI) of the device, and therefore, the device ID is shared across domains when the device requests a service provided by a different domain. The existing authentication techniques (e.g., 5th Generation Authentication and Key management) further require a share key between the device and the domain it is associated with before implementing authentication during, for example, a roaming scenario.

[0005] Therefore, there is a need for systems, apparatus, and methods for authenticating users and devices across different domains that obviate or mitigate one or more limitations of the prior art.

[0006] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.SUMMARY

[0007] A first aspect of the present disclosure provides a method for cross-domain authentication. The method comprises generating, by an identity manager configured to manage identifiers (IDs) at a first domain in a network, a first validation information. The first validation information includes an identification information generated based on all temporary IDs of a device associated with the first domain in the network and user IDs of one or more users associated with a second domain in the network. The identification information is for authentication between the device and the one or more users. The method also comprises ending, by the identify manager, the first validation information towards a user of the one or more users.

[0008] In some embodiments of the first aspect, all the temporary IDs of the device may be generated by the identity manager and mapped to a real ID of the device. Each user of the one or more users may be a physical user or a virtual representation of the physical user. The first validation information may further include a credential generated based on the identification information. The first validation information may further include a respective one or more certificates for the one or more users. The method may further comprise binding, by the identity manager, the device with the one or more users. The method may further comprise receiving, by the identity manager, the user IDs of the one or more users.

[0009] In a second aspect, the present disclosure provides a method for cross-domain authentication. The method comprises, by a first authenticator associated with a first domain of a network: obtaining a first validation information that includes an identification information. The identification is generated based on user identifiers (IDs) for one or more users associated with the first domain; and all temporary IDs for a device associated with the second domain. The method also comprises, subsequent the validating of the first validation information, generating a second validation information that includes the identification information; and providing the second validation information towards a user of the one or more users for a second validation.

[0010] In a third aspect, the present disclosure provides a method for cross-domain authentication. The method comprises generating, by an identity manager configured to manage identifiers (IDs) at a first domain in a network, a first validation information. The first validation information includes an identification information generated by the identity manager based on user IDs of one or more users associated with a second domain in the network; and all temporary IDs of a device associated with the first domain in the network. The method also comprises providing the first validation information to a first authenticator associated with the first domain for a first validation; and generating, at the first authenticator, when the first validation is successful, a second validation information comprising the identification information. The method further comprises providing the second validation information to a second authenticator associated with the second domain for a second validation; generating, at the second authenticator, when the second validation is successful, a third validation information comprising the identification information; and providing, the third validation information to a user of the one or more users for a third validation.

[0011] In some embodiments of the third aspect, the method may further comprise generating, at the user, when the third validation is successful, parameters for provisioning a first key for secure communication between the user and the first domain, and a second key for secure communication between the user and the second domain. The method may further comprise providing, to the device, for a fourth validation, the identification information; a user ID of the user; and the parameters or the first key.

[0012] In some embodiments of the third aspect, all the temporary IDs of the device may be mapped to a real device ID of the device, the real ID of the device being secured with the identity manager.

[0013] In some embodiments of the third aspect, the user may be physical user or a virtual representation of the physical user.

[0014] In some embodiments of the third aspect, the first validation information may further include a credential for the identification information generated based on the identification information, and the first validation may comprises validating the credential for the identification information.

[0015] In some embodiments of the third aspect, the second validation information may further include a first authenticator credential for the first authenticator, the first authenticator credential being generated in response to the successful validation of the credential for the identification information; and the second validation may comprise validating the first authenticator credential.

[0016] In some embodiments of the third aspect, the first authenticator credential may be generated according to one or more of: the credential for the identification information; the identification information; and first authenticator information.

[0017] In some embodiments of the third aspect, the third validation information may further include a second authenticator credential for the second authenticator, the second authenticator credential being generated based on the first authenticator credential in response to the successful validation of the first authenticator credential; and the third validation may comprise validating the second authenticator credential.

[0018] In some embodiments of the third aspect, the second authenticator credential may be generated according to one or more of: the first authenticator credential; the identification information; and second authenticator information.

[0019] In some embodiments of the third aspect, the first validation information may further include a user certificate for the user and the first validation may comprise validating the user certificate.

[0020] In some embodiments of the third aspect, the second validation information may further include one or more of: the user certificate; a first authenticator certificate for the first authenticator; and a device certificate for the device.

[0021] In some embodiments of the third aspect, the second validation may comprise, respectively, validating, the one or more of: the user certificate; the first authenticator certificate; and the device certificate.

[0022] In some embodiments of the third aspect, the third validation information may further include a second authenticator certificate for the second authenticator; and the third validation may comprise validating the second authenticator certificate.

[0023] In some embodiments of the third aspect, the method may further comprise binding, at the identity manager, the device with the one or more users.

[0024] In some embodiments of the third aspect, the method may further comprise, by the second authenticator, receiving, from the user, an authentication request comprising the user ID; generating a second authenticator certificate for the second authenticator; providing, by the second authenticator to the first authenticator, the user ID and the second authenticator certificate; and by the first authenticator: validating the second authenticator certificate; and providing to the identity manager, when validating the second authenticator certificate is successful, the user ID.

[0025] In a fourth aspect, the present disclosure provides an apparatus configured to perform the method of any one of the first aspect, the second aspect, and the third aspect.

[0026] In some embodiments of the fourth aspect, the apparatus may be configured to manage identifiers (IDs) at the first domain in the network and the apparatus may comprise a processing unit configured to generate a first validation information, the first validation information including an identification information generated based on all temporary IDs of a device associated with the first domain in the network and user IDs of one or more users associated with a second domain in the network, the identification information being for authentication between the device and the one or more users. The apparatus may further comprise a transmitting unit configured to send the first validation information towards a user of the one or more users.

[0027] In some embodiments of the fourth aspect, all the temporary IDs of the device may be mapped to a real ID of the device.

[0028] In some embodiments of the fourth aspect, each user of the one or more users may be a physical user or a virtual representation of the physical user.

[0029] In some embodiments of the fourth aspect, the first validation information may further include a credential generated based on the identification information.

[0030] In some embodiments of the fourth aspect, the first validation information may further include a respective one or more user certificates for the one or more users.

[0031] In some embodiments of the fourth aspect, the processing unit may be further configured to bind the device with the one or more users.

[0032] In some embodiments of the fourth aspect, the apparatus may further comprise a receiving unit configured to receive the user IDs of the one or more users.

[0033] In a fifth aspect, the present disclosure provides an apparatus that comprises one or more processors configure to execute instructions stored in one or more memory to implement the method of any one the first aspect, the second aspect and the third aspect.

[0034] In a sixth aspect, the present disclosure provides a computer-readable storage medium having instructions stored thereon which, when executed by a one or more processors cause the one or more processors to perform the method of any one of the first aspect, the second aspect and the third aspect.

[0035] In a seventh aspect, the present disclosure provides a system for cross-domain authentication. The system comprises: an identity manager associated with a first domain in a network. The identity manager is configured to: manage identifiers (IDs) at a first domain in a network; and generate a first validation information including an identification information generated based on: user IDs of one or more users associated with a second domain in the network; and all temporary IDs of a device associated with the first domain in the network. The system further comprises a first authenticator associated with the first domain of the network. The first authenticator is configured to: obtain the first validation information for a first validation; generate, when the first validation is successful, a second validation information comprising the identification information; and provide the second validation information to a second authenticator associated with the second domain for a second validation.

[0036] In some embodiments of the seventh aspect, the second authenticator may be configured to: generate, when the second validation is successful, a third validation information comprising the identification information; and provide the third validation information to a user of the one or more users for a third validation.

[0037] In some embodiments of the seventh aspect, the first validation information may further include a credential for the identification information generated based on the identification information. The first validation may comprise validating the credential for the identification information.

[0038] In some embodiments of the seventh aspect, the second validation information may further include a first authenticator credential for the first authenticator. The first authenticator credential being generated in response to the successful validation of the credential for the identification information. The second validation may comprise validating the first authenticator credential.

[0039] In some embodiments of the seventh aspect, the first authenticator credential may be generated according to one or more of:the credential for the identification information; the identification information; and first authenticator information.

[0040] In some embodiments of the seventh aspect, the first validation information may further include a user certificate for the user; and the first validation may comprise validating the user certificate.

[0041] In some embodiments of the seventh aspect, the second validation information may further include one or more of: the user certificate; a first authenticator certificate for the first authenticator; and a device certificate for the device.

[0042] In some embodiments of the seventh aspect, the second validation may comprise, respectively, validating, the one or more of: the user certificate; the first authenticator certificate; and the device certificate.

[0043] In some embodiments of the seventh aspect, the identity manager may be further configured to bind the device with the one or more users.

[0044] Other aspects of the disclosure provide for apparatus, and systems configured to implement the methods according to the first aspect disclosed herein. For example, …can be configured with machine readable memory containing instructions, which when executed by the processors of these devices, configures the device to perform one or more of the methods and systems described herein.

[0045] Embodiments have been described above in conjunction with aspects of the present disclosure upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0047] FIG. 1 is a schematic illustration of an example communication network, according to embodiments of the present disclosure.

[0048] FIG. 2 is a schematic illustration of another example communication network, according to embodiments of the present disclosure.

[0049] FIG. 3 is a schematic illustration of an example apparatus for performing some or all of the methods and / or implementations of the present disclosure.

[0050] FIG. 4 is a schematic illustration of another example apparatus for performing some or all of the methods and / or implementations of the present disclosure.

[0051] FIG. 5 is a schematic illustration of components of a 6th Generation (6G) System Conceptual Structure, according to embodiments of the present disclosure.

[0052] FIG. 6 is a schematic illustration of a deployment architecture of a 6G System, according to embodiments of the present disclosure.

[0053] FIG. 7 is a schematic illustration of an example apparatus of a 6G system, according to an embodiment of the present disclosure.

[0054] FIG. 8 is a schematic illustration of a cross-domain scenario, according to embodiments of the present disclosure.

[0055] FIG. 9A is a schematic illustration of an identification information, according to embodiments of the present disclosure.

[0056] FIG. 9B is a schematic illustration of a flowchart of steps of cross-domain authentication, according to an embodiment of the present disclosure.

[0057] FIG. 10A is a schematic illustration of steps of user authentication in a first use case, according to an embodiment of the present disclosure.

[0058] FIG. 10B is a table detailing example messages exchanged between entities of FIG. 10A, according to an embodiment of the present disclosure.

[0059] FIG. 11A is a schematic illustration of steps of user authentication in a second use case, according to an embodiment of the present disclosure.

[0060] FIG. 11B is a table detailing example messages exchanged between entities of FIG. 11A, according to an embodiment of the present disclosure.

[0061] FIG. 12A is a schematic illustration of steps of user authentication in a third use case, according to an embodiment of the present disclosure.

[0062] FIG. 12B is a table detailing example messages exchanged between entities of FIG. 12A, according to an embodiment of the present disclosure.

[0063] FIG. 13A is a schematic illustration of steps of user authentication in a fourth use case, according to an embodiment of the present disclosure.

[0064] FIG. 13B is a table detailing example messages exchanged between entities of FIG. 13A, according to an embodiment of the present disclosure.

[0065] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.DETAILED DESCRIPTION

[0066] The present disclosure provides a method and system for cross-domain authentication of a device associated with a first domain of a network and a user associated with a second domain of the network. An identity manager of the first domain can generate an identification information based on the user IDs of one or more users and all temporary IDs for the device. The identity information is used for validation across the domains and by other entities of a same domain, such as by a first authenticator of the first domain, a second authenticator of the second domain, the user, and the device, while the information indicative of the real ID of the device is known only to the identity manager of the first domain and therefore, is not shared with any entity outside the identity manager of the first domain, advantageously providing improved privacy protection of the real ID of the device.

[0067] The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, and examples. Insofar as such block diagrams, flowcharts, and examples contain one or more functions and / or operations, it will be understood by a person skilled in the art that each function and / or operation within such block diagrams, flowcharts, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a + / -10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to. The phrase “in embodiments” can be interpreted to mean “in one or more, but not necessarily all embodiments” .

[0068] FIG. 1 schematically illustrates a network 100, according to embodiments. The network 100 may be or may include a knowledge sharing network, for example a network configured for sharing information usable at least in part for Artificial Intelligence (AI) tasks, inference training, etc. The network 100 may be or may include the 6G system architecture described elsewhere herein, for example with reference to FIGs. 5 and 6. The network 100 may include an underlay network 170, such as a transport network. The network may include an overlay network 180, such as a mobile network. The network may include an application-driven network 190. The network may include a radio access network (RAN) 120. The RAN 20 may be a next generation (e.g., 6th generation (6G) or later) radio access network, or a legacy (e.g., 5th generation (5G) or 4th generation (4G) ) radio access network. In some implementations, the 6G radio access refers to a next generation air interface of standards which may comprise both terrestrial networks (TNs) and non-terrestrial networks (NTNs) . The network 100 may include a core network (CN) 130 that may be dependent or independent of the radio access technology used in the network. The network 100 may include a public switched telephone network (PSTN) 140, the internet 150, and other networks 160. In general, the network enables communication of multiple wireless or wired devices thereof, such as nodes, network elements, servers, databases, switches, routers, orchestrator, etc. The network 100 may include various domains. Each domain may be associated with one or more of the aforementioned networks of the network 100. Each domain may include respective one or more network function, respective one or more service or both, to be provided to a device 110 (also referred to herein as a user equipment (UE) , electronic device (ED) ) , a user (also referred to herein as a D-user) associated with a domain, or both.

[0069] The network 100 may provide content, such as voice, data, video, text, or a combination thereof, via broadcast, multicast, groupcast, unicast, etc. The network may operate by sharing resources, such as carrier spectrum bandwidth, among its constituent elements. The network may provide a wide range of communication services and applications to network users including enhanced Mobile Broadband (eMBB) services, ultra-reliable low-latency communication (URLLC) services, massive machine type communication (mMTC) services, integrated sensing and communication (ISAC) , immersive communication,  massive communication, Hyper reliable and low-latency communication, ubiquitous connectivity, integrated AI and communication, and other services that can be provided by a future generation network. The network may provide other services and applications such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0070] The network may include a terrestrial network, a non-terrestrial network, or a combination thereof. The network may provide a high degree of availability and robustness through a joint operation of a terrestrial network and a non-terrestrial network. For example, integrating a non-terrestrial network (or components thereof) into a terrestrial network can result in a heterogeneous network comprising multiple layers. The heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks. The terrestrial network and the non-terrestrial network could be considered sub-systems of the network.

[0071] The network may be compliant with one or more regional, national, international, or a combination thereof, standards, such as the Internet Engineering Task Force (IETF) , the European Telecommunications Standards Institute (ETSITM) , and the Third Generation Partnership Project (3GPPTM) .

[0072] FIG. 2 illustrates another example network 100 according to an implementation of the present disclosure, there is shown the network 200 includes EDs 110a, 110b, 110c, 110d (collectively referred to as ED 110) , RANs 120a, 120b, one or more CNs 130, a PSTN 140, the Internet 150, and other networks 160. The network 100 may be or may include the 6G system architecture described elsewhere herein, for example with reference to FIGs. 5 and 6. Additionally, the network 200 may also include a non-terrestrial network (NTN) 120c. The RANs 120a and120b may include network nodes 170a and 170b respectively. Examples of network nodes 107a, 107b include base stations, which can be generally referred to as terrestrial network (TN) devices or terrestrial transmit and receive points (T-TRPs) 170a and 170b (collectively referred to as 170) . In this context, the terms "TRP" and "base station" are used interchangeably unless otherwise specified. For simplicity, this disclosure primarily refers to network nodes as base stations; however, unless explicitly stated otherwise, references to TRP are considered non-limiting and interchangeable. The T-TRPs 170a, 170b may be base stations mounted on a building or tower. In one implementation, the NTN 120c includes a RAN node such as a base station 172, which may be generally referred to as an NTN device, a non-terrestrial node, a non-terrestrial network device, a non-terrestrial base station, or a non-terrestrial transmit and receive point (NT-TRP) 172.

[0073] In some implementations, the NT-TRP 172 is not attached to the ground, for example, as in the case of an airborne base station. An airborne base station may be implemented using communication equipment supported or carried by a flying device. For example, a flying device may include, but is not limited to, an airborne platform (such as a blimp or an airship) , balloon, drone (such as quadcopter) , and other types of aerial vehicles. In some implementations, an airborne base station may be supported or carried by an unmanned aerial system (UAS) or an unmanned aerial vehicle (UAV) , such as a drone. An airborne base station may be a moveable or mobile base station that can be flexibly deployed in different locations to meet network demand. A satellite base station is another example of a non-terrestrial base station. A satellite base station may be implemented using communication equipment supported or carried by a satellite. A satellite base station may also be referred to as an orbiting base station. High altitude platforms are yet another example of non-terrestrial base stations, including international mobile telecommunication base stations.

[0074] As referred to herein, and unless specified otherwise, a “TRP” may also refer to a T-TRP or an NT-TRP, a “T-TRP” may also refer to a “TN TRP” , and an “NT-TRP” may also refer to an “NTN TRP” . The NTN 120c may be considered a RAN, sharing operational aspects with RANs 120a, 120b. The NTN 120c may include at least one NTN device and at least one corresponding terrestrial network device. The at least one NTN device may function as a transport layer device and the at least one corresponding terrestrial network device may function as a RAN node, communicating with the ED 110 via the NTN device. Additionally, there may be an NTN gateway on the ground (referred to as a terrestrial network device) that also functions as a transport layer device facilitating communication with both the NTN device and the RAN node. The RAN node may communicate with the ED 110 via the NTN device and the NTN gateway. In some implementations, the NTN gateway and the RAN node may be located within the same device.

[0075] A base station 170 (also referred to as a TRP as stated above) is a network element within a radio access network responsible for radio transmission and reception in one or more cells to or from the ED (such as a user equipment) . In different implementations, the base station 170 may also be known as a base transceiver station (BTS) , a radio base station, a network node, a network device, a device on the network side, a transmit / receive node, a Node B, an evolved NodeB (eNodeB or eNB) , a Home eNodeB, a next Generation NodeB (gNB) , a transmission point (TP) , a site controller, an access point (AP) , a wireless router, a relay station, a terrestrial node, a terrestrial network device, a terrestrial base station, a non-terrestrial node, a non-terrestrial network device, a non-terrestrial base station, and a positioning node, among other possibilities. The base station 170 may be a macro base station (BS) , a pico BS, a relay node, a donor node, or combinations thereof. When the base station 170 performs (or is configured to perform) a method described herein, it may be interpreted as the base station itself, one or more modules (or units) in the base station, a circuit or chip, or a combination thereof, performing the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, system in package (SIP) ) , and the like, and may be responsible for one or more communication functions within the base station.

[0076] The EDs 110a-110d and TRPs 170a-170b, 172 are examples of communication equipment configured to implement some or all of the operations and / or implementations described herein. The T-TRP 170a forms part of the RAN 120a, which may include other TRPs, and / or other devices. Also, the TRP 170b forms part of the RAN 120b, which may include other TRPs, and / or devices. Each TRP 170a, 170b may transmit and / or receive wireless signals within a particular geographic region or area, sometimes referred to as a “cell” or a “coverage area” . The TRPs 170a-170b may be responsible for allocating and / or configuring resources and transmission and / or reception in a set of cell (s) . A cell is a radio network object that can be uniquely identified by a cell identification that is broadcasted over a geographical region or area from base stations associated with the cell. A cell can work in either FDD or TDD mode. A cell may be further divided into cell sectors, and a base station 170a-170b may, for example, employ one or more transceivers to provide services to one or more sectors. Some implementations may include pico or femto cells if supported by the radio access technology. In some implementations, one or more transceivers could be used for each cell, such as with Multiple-Input Multiple-Output (MIMO) technology. The number of RANs 120a-120b shown is merely an example. Any number of RANs may be contemplated when designing the network 200.

[0077] A base station may be a single element, as shown in the figures, or multiple elements distributed throughout the corresponding RAN, or otherwise configured. In some implementations, a plurality of RAN nodes coordinate to assist the ED 110 in implementing radio access, and different RAN nodes separately implement and handle different functions of the base station. For example, the RAN node may be a central unit (CU) , a distributed unit (DU) , a CU-control plane (CP) , a CU-user plane (UP) , or a radio unit (RU) etc. The CU and the DU may be separately deployed, or included within the same element (i.e., a baseband unit (BBU) ) . The RU may be included in a radio frequency device or a radio frequency unit (i.e., a remote radio unit (RRU) , an active antenna unit (AAU) , or a remote radio head (RRH) ) . In different systems, the CU (or the CU-CP and the CU-UP) , the DU, or the RU may be known by different names, but their functions are understood by person skilled in the art. For example, in an open radio access network (ORAN) system, a CU may be referred to as an open CU (O-CU) , a DU may be referred to as an open DU (O-DU) , and a CU-CP may be referred to as an open CU-CP (O-CU-CP) . The CU-UP may also be referred to as an open CU-UP (O-CU-UP) , and the RU may also be referred to as an open RU (O-RU) . Any one of the CU (or the CU-CP, the CU-UP) , the DU, and the RU may be implemented using a software module, a hardware module, or a combination of a software module and a hardware module.

[0078] Furthermore, communication between different devices / apparatuses in various implementations of this disclosure may refer to direct communication (that is, without the need of forwarding by another device / apparatus) , or may refer to communication (s) between different devices / apparatuses via another device / apparatus (that is, requiring forwarding by another device / apparatus) . Alternatively, such communication (s) may involve one functional unit inside a device / apparatus using another functional unit within the device / apparatus to communicate with another device / apparatus. In other words, phrases such as "sending (or transmitting) information to... (an ED or a base station) " in this disclosure may be understood as a destination endpoint of the information being an ED or a base station, including, sending / transmitting information directly or indirectly to an ED or a base station. Similarly, phrases like "receiving information from... (an ED or a base station) " may be understood as a source endpoint of the information being an ED or a base station, including directly or indirectly receiving information from an ED or a base station.  Between the source endpoint that sends the information and the destination endpoint, necessary processing such as, but not limited to, format conversion, digital-to-analog conversion, amplification, and filtering may be performed on the information. However, the destination endpoint may understand valid information from the source endpoint. A similar understanding applies to other descriptions in this disclosure without reiterating details already described. In the present disclosure, the terms "send" and "transmit" may be used interchangeably in different implementations of this disclosure.

[0079] The ED 110 is used to connect people, objects, machines, and other entities. The ED 110 may be widely used in various scenarios including, but not limited to, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , MTC, internet of things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, and autonomous delivery and mobility.

[0080] Each ED 110 represents any suitable end user device for wireless operation and may include such devices (or may be referred to as, but not limited to) a user equipment (UE) or a user device or a terminal device, a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , an MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus (such as a module, modem, or chip) in the forgoing devices, among other possibilities. Future generation EDs 110 may be referred to by other terms. When an ED 110 performs (or is configured to perform) a method described herein, it may be interpreted as the ED itself, one or more modules (or units) in the ED, a circuit or chip, or a combination thereof, performing the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in package (SIP) ) , and the like, and may be responsible for one or more communication functions in the ED.

[0081] Each ED 110 connected to TRPs 170a-170b, and / or TRPs 172 can be dynamically or semi-statically turned-on (i.e., established, activated, or enabled) , turned-off (i.e., released, deactivated, or disabled) and / or configured in response to one of more of: connection availability and connection necessity.

[0082] Any ED 110 may be alternatively or additionally configured to interface, access, or communicate with any of the TRPs 170a, 170b and 172, the Internet 150, the CN 130, the PSTN 140, the other networks 160, or any combination thereof. In some examples, the ED 110a may communicate an uplink (UL) and / or downlink (DL) transmission over a terrestrial air interface 190a with station-TRP 170a. In some examples, the EDs 110a, 110b, 110c, and 110d may also communicate directly with one another via one or more sidelink (SL) air interfaces 190b. In some examples, the EDs 110a, 110d may communicate using an UL and / or DL transmission over a non-terrestrial air interface 190c with NT-TRP 172.

[0083] An air interface (such as, for example, 190a, 190b, 190c) generally includes a number of components and associated parameters that collectively specify how a transmission is to be sent and / or received over a wireless communications link between two or more communicating devices such as EDs and base station (s) . For example, an air interface may include one or more components defining the waveform (s) , frame structure (s) , multiple access scheme (s) , protocol (s) , coding scheme (s) and / or modulation scheme (s) for conveying information (such as, data) over a wireless communications link. The air interfaces 190a and 190b may use similar communication technology, that may include any suitable radio access technology.

[0084] The non-terrestrial air interface 190c can enable communication between the EDs 110a, 110d and one or more NT-TRPs 172 via a wireless link or simply a link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of EDs 110 and one or more NT-TRPs 172 for multicast transmission.

[0085] The TRPs 170a-170b, 172 may communicate with one another over one or more air interfaces 190e, 190f using wireless communication links (such as radio frequency (RF) , microwave, infrared (IR) , etc. ) or wired communication links. The air interfaces 190e, 190f may utilize any suitable radio access technology, and may be substantially similar to the air interfaces 190a, 190c over which the EDs 110a-110d communicate with one or more of the TRP 170a-170b, 172 or they may be substantially different. For example, the network 200 may implement one or more channel access methods, such as Time Division Multiple  Access (TDMA) , Frequency Division Multiple Access (FDMA) , Code Division Multiple Access (CDMA) , Single Carrier Frequency Division Multiple Access (SC-FDMA) , Low Density Signature Multicarrier Code Division Multiple Access (LDS-MC-CDMA) , Non-Orthogonal Multiple Access (NOMA) , Pattern Division Multiple Access (PDMA) , Lattice Partition Multiple Access (LPMA) , Resource Spread Multiple Access (RSMA) , and Sparse Code Multiple Access (SCMA) .

[0086] The RANs 120a and 120b are in communication with the CN 130 to provide the EDs 110a 110b, and 110c with various services such as voice, data, multimedia, and other services. The RANs 120a and 120b and / or the CN 130 may be in direct or indirect communication with one or more other RANs (not shown) , which may or may not be directly served by the CN 130, and may employ different radio access technologies from RAN 120a and / or RAN 120b. The CN 130 may also serve as a gateway access between (i) the RANs 120a and 120b and / or the EDs 110a 110b, and 110c, and (ii) other networks (such as the PSTN 140, the Internet 150, and the other networks 160) . In addition, some or all of the EDs 110a 110b, and 110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and / or protocols. For example, the EDs 110a 110b, and 110c communicate using different cellular communications protocols, such as, but not limited to, a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like. Instead of wireless communication (or in addition thereto) , the EDs 110a 110b, and 110c may communicate using wired communication channels to a service provider or switch (not shown) , and / or to the Internet 150. The PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS) . The Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as internet protocol (IP) , transmission control protocol (TCP) , user datagram protocol (UDP) . EDs 110a 110b, and 110c may be multimode devices capable of operation according to multiple radio access technologies, and may incorporate one or multiple transceivers necessary to support such.

[0087] In addition, the network 200 may comprise a sensing agent (not shown) to manage the sensed data from ED 110 and / or any one of TRPs 170a, 170b, 172. In one implementation, the sensing agent may be part of any one of TRPs 170a, 170b, 172. In another implementation, the sensing agent is a separate node that can communicate with the CN 130 and / or the RAN 120 (such as any one of TRPs 170a, 170b, 172) .

[0088] FIG. 3 illustrates an example apparatus 310 according to an implementation of the present disclosure. The apparatus 310 may be a communication device or an apparatus implemented in a communication device such as the ED 110 or the TRPs 170a, 170b, 172, or in a one or more network function of the network configured to implement cross-dimension authentication procedures disclosed herein. For example, the apparatus 310 implemented in an ED may be an integrated circuit, which in some instances may be referred to as a chip, a modem, a modem chip, a baseband chip, or a baseband processor. In some implementations, one or more integrated circuits can be packaged into a system-on-chip, a system-in-package, or a multi-chip module. The apparatus 310 can include one or more integrated circuits and other discrete components. In some implementations, the apparatus 310 may be a module within the ED 110. In some implementations, the apparatus 310 may be a module within one of the TRPs 170a, 170b, 172, the apparatus 410 of FIG. 4 described elsewhere herein, or the apparatus 720 of FIG. 7 described elsewhere herein.

[0089] In an example, the apparatus 310 may include one or more processors 311, and an interface circuit 312. The apparatus 310 may further include a memory 313. The one or more processors 311 are configured to process signals and execute one or more communication protocols. The memory 313 is configured to store at least a part of corresponding computer program instructions and / or data. In an example, the one or more processors 311 execute the computer program instructions stored in the memory 313 to implement related operations (for example, inputting, outputting, receiving, and transmitting) in the method embodiments disclosed herein. In some implementations, the memory 313 being configured to store the corresponding computer program instructions and / or data may mean that the memory 313 is configured to store all of the corresponding computer program instructions and / or data for execution by the one or more processors 311. In some implementations, the memory 313 being configured to store the corresponding computer program instructions and / or data may mean that the memory 313 is configured to store a part of the corresponding computer program instructions and / or data. For example, the part of the corresponding computer program instructions and / or data may include computer program instructions and / or data that need to be currently executed by the one or more processors 311. Thus, the memory 313 may store different parts of computer program instructions and / or data for a  plurality of times for the one or more processors 311 to perform related operations in the method embodiments disclosed herein. As a communication interface, the interface circuit 312 is configured to implement communication with another component. For example, the interface circuit 312 may communicate a signal with other apparatus / system such as a radio frequency processing apparatus, or processor system. The communication includes transmitting signal (or data, information) to another component or device, or receives signal from another component or device. “transmitting” includes outputting the signal to a component or device that is directly or indirectly coupled to the interface circuit (transmitting unit) . “receiving” includes inputting or obtaining a signal from a component or device that is directly or indirectly couped to the interface circuit (receiving unit) . Optionally, to reduce a load of the one or more processors, a baseband signal processing circuit 314 may be also disposed to implement processing of at least a part of baseband signals, including signal demodulation, modulation, encoding, decoding, or the like.

[0090] The apparatus 310 may be, with reference to FIG. 7, the processor 760 within the apparatus 720, in some scenarios, or may be included within the processor 760 within the apparatus 720 in some scenarios. The apparatus 310 may be a baseband chip or may include a baseband chip. In some implementations, the apparatus 310 may be independently packaged into a chip. In some implementations, the apparatus 310includes different types of chips. The apparatus 310 may be packaged into a processor chip (for example, an SoC chip or an SIP chip) with the different types of chips. In some implementations, the apparatus 310 may be packaged into a chip with some or all of circuits of a radio frequency processing system that may further be included in the apparatus 720 of FIG. 7, for example.

[0091] FIG. 4 illustrates example apparatus 410 according to an implementation of the present disclosure. The apparatus 410 may include corresponding modules or units configured to implement methods and / or implementations described herein. In some implementations, the apparatus 410 includes a processing unit 412 and a communication unit 413. Optionally, the apparatus 410 may further include a storage unit 411 configured to store apparatus program code (or instructions) and / or data.

[0092] The apparatus 410 may be an ED side apparatus, for example, an ED or a module in an ED, or a circuit or a chip responsible for a communication function in an ED.

[0093] The apparatus 410 may be a base station side apparatus, for example, a base station or a module in a base station, or a circuit or a chip responsible for a communication function in a base station. In some implementations, apparatus 410 may be apparatus 720 of FIG. 7. The processing unit 412 may be the processor 760. The communication unit 413 may comprise a receiving unit and / or a transmitting unit. The receiving unit and / or the transmitting unit may be the transmitter 752 and / or the receiver 754, respectively. The storage unit 411 may be the memory 758.

[0094] In some implementations, when the apparatus 410 is an ED 110 or a module in an ED 110, a function of the apparatus 410 may be implemented by one or more processors. Specifically, the processor may include a modem chip, or a system on chip (SoC) chip or an SIP chip that includes a modem core. A function of the communication unit 413 may be implemented by a transceiver circuit.

[0095] In some implementations, when the apparatus 410 is a circuit or a chip that is responsible for a communication function in an ED 110, such as a modem chip, a system on chip (SoC) chip or an SIP chip that includes a modem core -a function of the processing unit 412 may be implemented by a circuit system within the chip which includes one or more processors. A function of the communication unit 413 may be implemented by an interface circuit or a data transceiver circuit on the chip.

[0096] It may be understood that the units in the apparatus 410 may be logical or functional. Each function may correspond to one functional unit, or two or more functions may be integrated into a single functional unit. In actual implementation, all or some of the units may be integrated into a single physical entity, or may be distributed across different physical entities. In addition, the functional units may be implemented in the form of hardware, software, or a combination of hardware and software. Whether a function is implemented in the form of hardware or software depends on particular applications and design constraint conditions of the technical solutions. A person skilled in the art may use different methods to implement the described functions for specific applications, but it should not be considered that the implementation goes beyond the scope of this disclosure.

[0097] In an example, a functional unit in any one of the apparatuses may be configured as one or more integrated circuits for implementing the methods disclosed herein, for example, as one or more application-specific integrated circuits (application-specific integrated circuits, ASICs) , one or more central processing units (CPUs) , one or more microprocessors or microprocessor  units (MPUs) , one or more microcontrollers or microcontroller units (MCUs) , one or more digital signal processors (DSPs) , one or more field programmable gate arrays (FPGAs) , or a combination of these.

[0098] In an example, the storage unit 411 may include a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, and / or a register.

[0099] A processor may be referred to as a processor system, an application processor, a baseband processor, a processor circuit, or a processor core. The processor may include one or a combination of one or more central processing units (CPUs) , one or more digital signal processors (DSPs) , one or more microprocessors (microprocessor units, MPUs) , one or more microcontrollers (microcontroller units, MCUs) , one or more graphics processing units (GPUs) , one or more field programmable gate arrays (FPGAs) , one or more artificial intelligence processors (AI processors) , or one or more neural network processing units (NPUs) .

[0100] Memory or a storage unit may include one or more of the following storage media: a random access memory (RAM) , a static random access memory (static RAM, SRAM) , a dynamic random access memory (dynamic RAM, DRAM) , a phase-change memory (PCM) , a resistive random access memory (resistive RAM, ReRAM) , a magnetoresistive random access memory (magnetoresistive RAM, MRAM) , a ferroelectric random access memory (ferroelectric RAM, FRAM) , a cache, a register, a read-only memory (ROM) , a flash memory (flash memory) , an erasable programmable read-only memory (erasable programmable ROM, EPROM) , a hard disk, and the like. In an example, computer program instructions used to execute embodiments may be stored in a non-volatile memory, for example, at least a part of a memory or storage unit (for example, one or more of a ROM, a flash memory, an EPROM, or a hard disk) . When a terminal runs, a part or all of corresponding computer program instructions may be loaded to a memory that has a higher transmission speed with the processor, for example, at least a part of a memory or a storage unit (for example, one or more of a RAM, an SRAM, a DRAM, a PCM, a RERAM, an MRAM, a FRAM, a cache, or a register) , so that the processor executes the computer program instructions to perform the steps in the method embodiments disclosed herein.

[0101] An evolutionary solution of a 6G system architecture design and procedure design are described in the present disclosure using example embodiments. The evolutionary solution is designed by enhancement of a 5G system.

[0102] In embodiments, the proposed 6G network architecture (i.e., the evolutionary solution) has been designed with a few important principles and requirements: openness, trustworthiness, simplicity in standardization, scalability, rapid deployment of 6G networks and future-proofing. The proposed 6G network architecture applies modularization strategy, utilizes service-based (XaaS) concepts and network virtualization techniques.

[0103] In embodiments, modularization of procedures is tried for all of the procedure designs (or steps of methods) . A procedure of the 6G System (i.e., proposed 6G network architecture, the evolutionary solution) may include some procedures (or steps) that can be reused by other procedures (or steps, methods) . Such a reusable procedure is defined herein as a basic procedure (e.g., connection setup procedure, session establishment procedure) . A complex procedure (or method, step) can, thus, include multiple sequential or parallel basic procedures (or steps) . It is expected that such methodology can simplify designs of procedures (or methods, steps of methods) .

[0104] In embodiments, the 6G System of the present disclosure leverages service-based architecture and the Everything as a Service (XaaS) concept. XaaS services in the 6G System are categorized into three layers. The 6G System conceptual structure is shown in FIG. 5.

[0105] In embodiments, with reference to FIG. 5, an Infrastructure Layer 530 includes infrastructures supporting 6G services, such as wireless networks (Radio Access Network (RAN) 531, Core Network (CN) ) infrastructures 532, Cloud / data center infrastructures (not shown) , satellite networks 533, storage / database infrastructures 535, sensing networks 534, etc., or a combination thereof. These infrastructures can be provided by a single provider or by multiple providers.

[0106] In FIG. 5, each XaaS service is provided by identified 6G logical functions. In the evolutionary solution, a XaaS service can be provided with 5G enhancement by more than one approach. Notably, FIG. 5 is a non-limiting example.

[0107] With reference to FIG. 5, the 6G System conceptual structure 500 has a Service layer 510 that includes a Network for Artificial Intelligence (NET4AI) 511 that is a new type of service in 6G CN / RAN which enables network with the capability to conduct / execute artificial intelligence (AI) training / inferencing task (s) , i.e. AI task (s) , by network-based computing and  communication resources. Herein, the evolutionary solution to support NET4AI service 511 by enhancing the network data analytics function (NWDAF) in 5G system are described.

[0108] At a Service layer 510, the 6G System conceptual structure 500 includes a Network for Data (NET4Data) service 512 that provides a decentralized architecture for data stakeholders to collaboratively manage data lifecycle events. These data lifecycle events include data storage and data sharing. The data could be public, private, sensitive, confidential, or a combination thereof. Herein, the NET4Data service 512 could be integrated into the 5GS, or could be an enhancement of the 5GS.

[0109] At a Service layer 510, the 6G System conceptual structure 500 includes a Data analysis and management (DAM) service 513 that focuses on different types of data: network data (e.g., data collected from network functions, XaaS service) , Integrated Sensing and Communications (ISAC) data (3GPPTM-based sensing data (e.g., from UE and RAN) , Non-3GPPTM-based sensing data (e.g., from Radar, LiDAR, WiFiTM Sensing) ) , sensor data (e.g., data from camera sensor, video sensor) , and other data (e.g., Digital user data, 3rd party data, synthetization data, and AI data) . DAM provides services for a variety of data consumers, e.g., XaaS service, 3rd party, Network Function (NF) , UE, etc. 5G system logical functions for example: NWDAF, Data Collection Coordination Function (DCCF) , and Messaging Framework Adaptor Function (MFAF) of control plane, can be enhanced to support the DAM service in the evolutionary solution.

[0110] At a Service layer 510, the 6G System conceptual structure 500 includes a Network for Digital World (NET4DW) 515 as a service that provides the capability of intelligent integration / synthesis of information from the physical world and digital world (DW) . Customers of NET4DW can be individuals, industries, governments. The customers can have the capability of creation, control, and management of a variety of applications running in the DW such as virtual reality applications. DW services can be supported by enhancing 5G functions and adding new functions (e.g., an evolutionary solution) where necessary.

[0111] The 6G System conceptual structure 500 includes a Network for connectivity (NET4CON) 1016 as a service that provides a capability to support exchange of messages and data among new 6G services. The basic capabilities of NET4CON 516 include to manage logical topology among XaaS services and between 6G XaaS services and all types of 6G system customers, to introduce intelligent GWs for controlling dynamic forwarding based on configured procedure principle and to support anonymous interactions among these XaaS services and customers by the introduced intelligent GWs. The NET4CON service 1016 is provided by enhancement of the 5G system.

[0112] At a C / M layer 520, the 6G System conceptual structure 500 includes a Mission Management (MM) 522 as a service that provides a capability to program provisioning of XaaS services at Service Layer to provide mission services. A mission is to achieve a designated goal, known as mission goal, which includes providing PDU connectivity and optionally providing data processing. The MM services 522 include the following: mission information management service, mission session management service, mission execution and access management service.

[0113] At a C / M layer 520, the 6G System conceptual structure 500 includes a Resource Management (RM) 521 as a service that provides a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices.

[0114] At a C / M layer 520, the 6G System conceptual structure 500 includes a Service Provisioning Management (SPM) 523 as a service that provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability is provided by ID management, unified authentication, anonymous service authorization and key management.

[0115] At a C / M layer 520, the 6G System conceptual structure 500 includes a Connectivity Management (CM) 524 as a service that provides a capability of reachability management of 6G wireless devices and D-users in NET4DW in order to support connectivity establishment between wireless devices / D-Users and XaaS services of 6G System. Note that physical locations of D-Users can be changed. A CM service can be deployed across multiple Basic Architecture Structure (BAS) domains.

[0116] At a C / M layer 520, the 6G System conceptual structure 500 includes a Consortium of the Network (CONET) 525 as a Service.

[0117] At a C / M layer 520, the 6G System conceptual structure 500 includes a Protocol 526 as a Service provides a capability to design service customized protocol stacks for identified interfaces.

[0118] FIG. 6 schematically illustrates one example embodiment of deployment of the 6G system according to the evolutionary solution, such as the 6G system 500 described herein with reference to FIG. 5.

[0119] In FIG. 6, “+” sign is used to represent “enhanced” , for example, the 5G AMF-Mobility function is enhanced, and correspondingly denoted in FIG. 6 as AMF-Mobility+ (622) . Similarly, the 5G Radio Resource Control (RRC) function is enhanced, and correspondingly denoted in FIG. 6 as RRC+ (623) ; the 5G Network Repository Function (NRF) is enhanced, and correspondingly denoted as NRF+ (625) ; the 5G Session Management Function (SMF) is enhanced, and correspondingly denoted as SMF+ (627) ; the 5G Network Exposure Function (NEF) is enhanced, and correspondingly denoted as NEF+ (628) ; and the 5G Authentication Server Function (AUSF) is enhanced, and correspondingly denoted as AUSF+ (630) . Other enhanced functions are similarly illustrated in FIG. 6 and are not described in detail herein.

[0120] As further shown in FIG. 6, a C / M Radio Bearer (C / M RB) of a device (652) represents over-the-air connection for carrying control signaling for over-the-air interface management and C / M plane messages. A device can have multiple C / M RBs 652. A Data Radio Bearer (Data RB) of a device (654) represents over-the-air connection for carrying Data plane traffic. A device can have multiple Data RBs 654. A Radio Bearer (RB) endpoint (655) represents an endpoint of an RB at network side. An endpoint of an RB protocol stack (e.g., Packet Data Convergence Protocol (PDCP) ) can be in, e.g., a RAN BAS domain, but not limited to. In other words, an RB endpoint can be flexibly (or suitably) deployed / selected for a device. As further shown in FIG. 6, an RB handler (656) represents an over-the-air interface protocol stack handler. An RB handler 656 is defined as a logical function which can perform RB protocol stack operations after getting (e.g., receiving, obtaining) suitable configurations. A protocol handler is (or may be) a PDCP-only handler or whole protocol stack handler. The RB handler 656 accepts RB configuration from a Connectivity Management (CM) service. The RB handler 656 also accepts (or may accept) security configuration, e.g., keying material, from a Service Provisioning Management (SPM) service.

[0121] As further shown in FIG. 6, the NET4CON service 660, which is a main service impacting on the 6G system architecture, is implemented by an enhanced 5G Service Communication Proxy (SCP+ 663) as C / M plane GW and by an enhanced 5G User Plane Function (UPF+ 664) as data plane GW. Proposed per device / D-User C / M session 661 and data session 662 are defined as logical connections between a device / D-User 604 and its serving SCP+ 663 (C / M-TW-GW) and serving UPF+ 664 (Data-TW-GW) . All XaaS services are (or may be) deployed across multiple BAS / clouds, such as BAS domain 1 611, BAS domain 2 612, BAS domain 3 613.

[0122] The 6G customer 604 can be of a variety of types, including a device (e.g., electronic device ED, terminal device) , UE, an apparatus (e.g., apparatus 720 with reference to FIG. 7) , a chip, an equipment (e.g., user equipment) , etc. For example, the customer may be an individual customer, a business customer, etc. The 6G customer may be used to connect persons, objects, machines, etc. The 6G customer may be widely used in various scenarios including, for example, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , Machine Type Communication (MTC) , internet of things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0123] Each 6G customer represents any suitable end user device for wireless operation and may include such devices (or may be referred to but not limited to) as a user equipment (UE) or a user device or a terminal device, a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. module, modem, or chip) or comprising the forgoing devices, among other possibilities. When a 6G customer performs (or is configured to perform) a method or methods described herein, it may be interpreted as the ED, one or more module (or units) in the ED, a circuit or chip, or a combination thereof, that may perform (or may be configured to perform) the method or methods. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in package (SIP) ) , and the like, and may be responsible for one or more communication functions in the ED / UE.

[0124] FIG. 7 illustrates an example of an apparatus 720 in a communication system (e.g., the 6G system 500 in FIG. 5) . The apparatus 720 may be an electronic device (e.g. ED or other 6G customer) , a network node such as RAN, any components in RAN, CN or any Network Function of CN. As shown in FIG. 7, apparatus 720 may include at least one processor 760. Only one processor 760 is illustrated to avoid congestion in the drawing. The processor 760 may perform (or control the apparatus 720 to perform) operations (or methods) described herein as being performed by the apparatus 720.

[0125] When the apparatus is a RAN, components of the RAN or the apparatus is the UE, the apparatus 720 may further include a transmitter 752 and a receiver 754 coupled to one or more antennas. One, some, or all of the antennas may alternatively be panel antennas. The transmitter 752 and the receiver 754 may be integrated, e.g. as a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or processing signals received wirelessly or by wire. Each antenna includes any suitable structure for transmitting and / or receiving wireless or wired signals. In present disclosure, the transceiver (or transmitter 752 and / or receiver 754) may be viewed as an interface circuit.

[0126] The apparatus 720 may include at least one memory 758. The memory 758 stores instructions used to perform operations described herein. The memory 758 may also store data used, generated, and / or collected by the apparatus 720. For example, the memory 758 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by the one or more processor 760.

[0127] A person skilled in the art should understand that embodiments of the present disclosure may be provided as a method, an apparatus (or a system) , a computer-readable storage medium, or a computer program product. Therefore, embodiments of the present disclosure may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, embodiments of the present disclosure may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include a computer-usable program code.

[0128] In the NET4DW service, a D-user (also referred to herein as a user) is a virtual representation of a physical user. In a physical world, a physical user has an identity assigned thereto such as an identity card, a roll number, etc. Sometimes, authentication mechanisms are used for identifying the physical user in a network. For example, in the 3GPPTM Technical Specification (TS) 33.501 version 18.5.0 titled “Security architecture and procedures for 5G System” and dated March 28, 2024, a primary authentication and key agreement procedure is to enable mutual authentication between the physical user (i.e., the device) and the network, and to provide key materials that can be used for indirect derivation keys for security protection on communications between the physical user and the network. When it comes to representing the physical user in the virtual world in the Metaverse Environment, the physical user’s information (e.g., name, features, gestures) can be used to uniquely identify them in the virtual world. As the metaverse can typically have a lot of data and people or users / D-users, it is crucial to ensure that a valid (e.g., authenticated) user accesses (or can access) a piece of particular information, and hence authentication comes into the picture. Thus, approaches to secure the identification and authentication process for D-users with the objective of enhancing user experience and security are needed.

[0129] Embodiments of the present disclosure focus on multiple (i.e., one or more) user authentication / identification when one or more users request for a service in cross-domain communications. In embodiments, an underlying assumption includes a user already being authenticated by a domain, the user is associated with and having a secure communication channel between the user and this domain. There is another device associated with another domain. The service is binding the user and the device (if they are not already bound) in these two different domains. The method includes firstly, before implementing the service, the user and the device should be authenticated by these two domains. Secondly, to protect the device’s ID privacy, the device’s real ID should not be disclosed to another domain (i.e., the domain the user is associated with, but the device is not) . Thus, identification information associated with the user and the device is replacing the device’s real ID. A corresponding credential for the identification information is used for validation of the device and the user by different domains to which are not initially associated with (i.e., cross-domains) . Thirdly, since the device has temporary IDs, these temporary IDs should be identified by different domains (i.e., the domain the device is associated with and the domain the user is associated with) . Thus, identification information  should be identified, verified, validated by the user and the device during the cross-domain authentication procedure. The aforementioned steps could advantageously protect device’s ID privacy.

[0130] In an authentication scenario to which various embodiments disclosed herein pertain, a device may have a real ID, such as an auth-ID which is used for authentication of the device by 6G core network, and one or more temporary IDs that are used for communications. The device ID (i.e., real ID and / or information indicative of the real ID) and the temporary IDs are known to (e.g., kept by, kept at, stored at) an identity manager (e.g., a network function (such as an IDM) of a same domain the device is associated with. To protect privacy of the device, the real ID of the device is only known by the identity manager, such as the IDM. Other network functions (of a same domain the device is associated with (e.g., 6G core network) , or of any other domain (e.g., NET4DW) ) have no knowledge about the real ID of the device (i.e., do not have access to the real ID of the device or the information indicative of the device ID) . A NET4DW service provides digital world services for the device, e.g., metaverse services. There may be multiple D-users in the NET4DW service. When the device requires NET4DW service with or using a temporary ID of its multiple temporary IDs, the 6G core network launches or initiates a cross-domain authentication procedure for the device and the D-user. After a successful cross-domain authentication, there are security protections, that involve share keys (e.g. first key K, second key K-D) , used for cross-domain communications between the device and the D-user.

[0131] Notably, in this scenario, there are two domains as schematically shown in FIG. 8 by way of an example. The scenario including two domains is used herein as an example. More than two domains may be present in the network. In a non-limiting example, domain 1 810 could be a 6G core network, and domain 2 820 could be a NET4DW service. In FIG. 8, GW1 811 is responsible for domain 1 810 message forwarding (could be an AMF or a SCP in 5G) with respect to a device 805 associated with the domain 1 810, identity manager such as an IDM 812 is associated with the domain 1 810 responsible for domain 1 810 ID management (could be a UDM in 5G) , a first authenticator such as AUSF1 815 is associated with the domain 1 810 and is responsible for authentication for entities (e.g., device) that may need or request access to the domain 1 810. ) Similarly, a second authenticator 825 such as AUSF2 is associated with the domain 2 820 and is responsible for authentication for entities (e.g., ) that may need or request access to the domain 2 820. GW2 821 is responsible for domain 2 820 message forwarding (could be a control function of a sub-service (e.g., metaverse) or a sub-network) , GW22 823 is responsible for domain 2 820 message forwarding with respect to user 2 832 associated with domain 2 820, and GW21 822 is responsible for domain 2 820 message forwarding with respect to user 1 831 associated with domain 2 820. Users 831, 832 in domain 2 820 could be D-users in the NET4DW service (e.g., respective user accounts of one or more service provided by the second domain 2) . The NET4DW service could provide sub-services (e.g., metaverse, virtual city) .

[0132] In embodiments, the scenario is not limited to two domains. For example, user 1 831 may be associated with the second domain 820, as shown, and user 2 832 may be associated with a third domain (not shown) . In such case, cross domain authentication, validation and identification would be between the device 805 associated with the first domain 810 and user 2 associated with the third domain (not shown) .

[0133] In embodiments, several underlying assumptions are made pertaining to the above described scenario and cross-domain authentication procedures disclosed herein. One assumption is that the real ID of the device associated with a first domain is kept at and is known only to the identity manager, such as the IDM or a similar network system, in the first domain that is configured to manage device IDs, and is unknown by NFs in any other domain, such as a second domain, a domain providing NET4DW services.

[0134] Another assumption is that in order to protect ID privacy of the device, temporary IDs (e.g., 5G-GUTI in 5G) of the device are used for inter-domain (i.e., within the first domain) and cross-domain (i.e., between the first domain and the second domain, and functions and services thereof) communications. As readily understood by a person skilled in the art, temporary IDs of the device are generated based on the real ID of the device.

[0135] Another assumption is that NFs in the second domain, such as a domain providing NET4DW services, are curious (i.e., may require, may monitor or collect or attempt to collect information) about the devices which access their services frequently. Another assumption is that GW1 of the first domain honestly (i.e., without malicious intent, third party involvement, etc. ) executes message forwarding and responds to a device’s request for one or more service provided by the second domain, and is curious (i.e., may require, may monitor or collect or attempt to collect information) about device’s privacy, such as information indicative of or  associated with the real ID of the device. Another assumption is that in the context of the one or more service provided by the second domain or one or more network function thereof, such as the NET4DW services, the D-user is already created, and is activated (e.g., the system allocates resources for the D-user, e.g., in relation to associated services) in the second domain, but not in the first domain prior to cross-domain authentication. Similarly, an assumption is made that the device is activated (e.g., device status or state has transitioned from idle to connected with respect to the first domain, in 5G) in the first domain, but not in the second domain prior to cross-domain authentication. Another assumption is that a primary authentication of the device by the 6G core network (e.g. using existing 5G-AKA’ technique) of the first domain is done prior to cross-domain authentication.

[0136] In the scenario (e.g. described herein with reference to FIG. 8) , there are several issues that may arise when considering a cross-domain authentication using existing methods, and to which the embodiments of the present disclosure are, at least in part, intended to provide solutions for. According to one such issue, when a device and a D-user are associated or linked or bound together, which credential may be used for the D-user? Should the D-user request for a certificate from the CA, or its credential could be associated with the device and the D-user? According to another such issue, to protect the device’s ID privacy, both of the second domain service, such as a NET4DW service, and the D-user have no knowledge of (e.g., information indicative of, representative of, or associated with) the device’s real ID. In such case, how can the D-user identify, authenticate, and / or validate the device during the cross-domain authentication procedure? According to another such issue, when the device uses different temporary IDs for the NET4DW service, should the 6G core network run an authentication procedure in cross-domain communications? According to another such issue, if the 6G core network does not run the authentication procedure mentioned above, how can the D-user identify, authenticate, and / or validate the device?

[0137] For the purpose of an illustrative example, an assumption is made that domains (e.g., the first domain and the second domain) are deployed by different providers. A device authenticated in the first domain 1 requests a service in the second domain 2, but the device’s profile (i.e., indicative or representative of, or associated with the real ID of the device) is kept in the first domain 1 by or at a network system suitably provided or configured, such as an IDM. This requested service is associated with the device and a first user 1 or a second user 2 in domain 2. An example situation may include a physical user having one or more digital representations thereof (i.e., user, e.g., a metaverse account) in one or more service (e.g., metaverse service) provided by the second domain, the physical user may use a device to access the system and uses a digital account (e.g., metaverse account) to access metaverse services.

[0138] The device has multiple (i.e., one or more) temporary IDs for the duration of the requested service. The requested service may have a set of different applications (e.g., social media, metaverse, etc. ) . Each application may have different IDs for the device or for the user 1 (e.g., different user accounts) .

[0139] According to the above discussed issues and with reference to FIG. 8, some technical problems are as follows. A device and a user are associated each for the duration of the requested service, but, to protect ID privacy for the device, the device’s profile (e.g., real ID) should be secret for the second domain 2 and any service, function or application thereof. Therefore, a technical problem arises of how does the second domain 2 identify and authenticate the device during this requested service implementation. In a roaming scenario in a 5G network, the existing technique assumes that both the first domain 1 and the second domain 2 know the device’s real ID (e.g., SUPI) . This existing technique cannot solve the above noted issues.

[0140] Another technical problem is that before implementing the requested service, the device and the user should be authenticated by the network (i.e., the first domain 1) . Existing authentication techniques in 5G roaming scenarios only provide authentication procedures between the device and the second domain 2, but not between the user and the device. Moreover, the existing authentication techniques (e.g., 5G-AKA’) assume that there is a shared key between the device and the first domain 1 before implementing authentication during the roaming scenario. But, according to the above noted assumptions, the scenario being considered herein has the underlying assumption that there is no shared key between the device and the first domain 1. Thus, existing authentication techniques are not applicable in the scenario being considered herein.

[0141] Another technical problem is that temporary IDs are used during implementation of the requested service, but the second domain 2 does not have access to the device’s ID profile (e.g., ID mapping table with the real ID and temporary IDs) . So, the question arises of how does the user in the second domain 2 identify the device in the first domain. In other words, a problem  to be solved includes determining whether the first domain 1 should run the authentication process again if the second domain 2 cannot identify the device.

[0142] In embodiments, a user, also referred to herein as a D-user, is a digital user or a virtual representation of a physical user. Non-limiting examples of a user include a metaverse user account, a social media user account, etc. Herein, steps and procedures performed by the user or at the user include steps and procedures performed by a system or a function at the user, used by the user, associated with the user, or a combination thereof, suitably configured to perform such steps and procedures.

[0143] In embodiments, a device is a UE, an ED, or a combination thereof. The device is used by a physical user, such as a person or an organization. In some embodiments, the device may be a user in one domain and methods and systems disclosed herein provide for cross-domain authentication of such user / device of one domain with one or more other users of another domain. Herein, steps and procedures performed by the device or at the device include steps and procedures performed by a system or a function at the device, used by the device, associated with the device, or a combination thereof, suitably configured to perform such steps and procedures.

[0144] A domain, a used herein, refers to an area or a region of the network having a particular set of functions, services, resources, functions, policies, etc., or a combination thereof. A domain may include or be communicatively coupled to any one or more sub-networks, such as an underlay network 170 (e.g., a transport network) , an overlay network 180 (e.g., a mobile network, an application-driven network 190, a core network 130, a RAN 120, a PSTN 140, the internet 150, and other networks 160, described elsewhere herein, for example with reference to FIGs. 1 and 2. A domain may be deployed by one or multiple providers. A domain may be, may include, or may be associated or coupled with one or more infrastructure, such as wireless networks, RAN 531, CN infrastructures 532, Cloud / data center infrastructures, satellite networks 533, storage / database infrastructures 535, sensing networks 534, described herein with reference to FIG. 5.

[0145] In embodiments, identification information is defined as a value that is associated with the device’s temporary IDs (e.g., all temporary IDs for a predefined application, request, session, etc. ) and the ID of the user. The identification information could be a function, could be obtained using a function, or both. The identification information is used for identification of the device and the user without disclosing the device’s real ID by the identity manager of the first domain to any other entity (e.g., function) or domain. The purpose of using the identification information is to enable the second domain 2 to recognize (i.e., identify, authenticate) the device while still protecting ID privacy of the device.

[0146] In embodiments, the identification information is generated by an identity manager (e.g., an IDM) of the first domain (i.e., the domain the device is associated with (i.e., in communication with or having access to) ) in accordance with or using, as an input of a function, the user identifiers (IDs) of one or more users associated with (i.e., in communication with and having access to) the second domain of the network, and all temporary IDs for the device associated with (i.e., in communication with or having access to) the first domain of the network.

[0147] FIG. 9A schematically illustrates the identification information 901 generated by the identity manager of the first domain and included in a first validation information 952 to be provided towards a user of the second domain. The identity manager generates the identification information 901 based on all temporary IDs 902 of the device which are mapped to the real ID 903 of the device, which is secured with the identity manager and not shared with other entities during cross-domain authentication, and user IDs 904 of one or more users of the second domain. These temporary IDs are un-linkable. The identification information is used for cross-domain authentication between the device and the one or more users.

[0148] In embodiments, as described further herein, the first validation information generated by the identity manager may include a certificate for the identification information that is generated based on the identification information, and is used in validation of the first validation information and generation of subsequent respective credentials for other entities (e.g., first authenticator, second authenticator) . Additionally or alternatively, the first validation information may include user certificates for each user of the one or more users of the second domain that can be used in validation of the first validation information and generation of subsequent respective certificates for other entities (e.g., first authenticator, second authenticator) .

[0149] In embodiments, a credential for identification information is defined as an authentication vector that is associated with the identification information. This authentication vector may include an authentication code that is an output of a function  having the identification information as an input, and / or a code that is associated with information of the user (e.g., user ID) , nonce, etc. ) . The purpose of the credential for identification information is its use in the verification procedures of the device and the user.

[0150] In embodiments, there is provided a method that enables the second domain 2 to identify (e.g., authenticate) the device having multiple temporary IDs while protecting the device (i.e., real) ID privacy during implementation of the requested services in the second domain 2. The method procedures include cross-domain authentication of the device and the user that are in different respective domains (i.e., the first domain and the second domain, respectively) . With reference to FIG. 9B, basic steps of implementing the method are as follows.

[0151] In a first step 910, the identity manager, such as the IDM (or another suitably configured network system of the first domain) , generates identification information and a credential for identification information when the authentication process is triggered. The identity manager (e.g., IDM) sends a first validation information that includes the identification information and the credential for identification information to a first authenticator, such as an Authentication Server function (AUSF1) , associated with the first domain.

[0152] In a second step 920, the first authenticator (e.g., AUSF1) , in a first validation, firstly verifies (or validates) the received credential for the identification information of the received first validation information, and, when verification is successful, generates a credential for the first authenticator (e.g., credential for the AUSF1) (also referred to herein as the first authenticator credential, e.g. AUSF1 credential) based on the received identification information. This credential for the first authenticator may be associated with the first authenticator’s information (e.g., AUSF1 ID) , for example. Then, the first authenticator provides or sends a second validation information that includes the credential for the first authenticator and the identification information to a second authenticator, such as an Authentication Server function (AUSF2) , associated with the second domain.

[0153] In a third step 930, the second authenticator (e.g., AUSF2) , in a second validation, firstly verifies the received first authenticator credential of the received second validation information, and, when validation is successful, generates a credential for the second authenticator (also referred to herein as the second authenticator credential, e.g. AUSF2 credential) based on the received identification information. This credential for the second authenticator may be associated with the second authenticator’s information (e.g., AUSF2 ID) , for example. Then, the second authenticator sends a third validation information that includes the credential for the second authenticator and the identification information to the user associated with the second domain.

[0154] In a fourth step 940, the user, in a third validation, firstly verifies or validates the received second authenticator credential of the received third validation information and then validates the identification information of the received third validation information using its user ID, and, when both the third validation that includes validation of the second authenticator credential and the identification information is successful, then the user may generate a credential for the user (also referred to herein as the user credential) based on the user ID. Then, the user may send the credential for user to the second authenticator.

[0155] In a fifth step 950, the second authenticator may verify the received user credential, if such was received.

[0156] In a sixth step 960, the first authenticator provisions (e.g., negotiates with the user, or generates) , using corresponding parameters (i.e., parameters for key provisioning) generated at or by the user, share keys, namely a first key (K) for secure communication between the user and the first authenticator and a second key (K-D) for secure communication between the user and the second authenticator, that will be further used as an input for key derivation of terminal keys for secure communication between the device, the user and the network. The first authenticator provides a fourth validation information that includes the identification information and the first key and the second key to the device.

[0157] In a seventh step 970, the device, in a fourth validation, verifies the identification information of the received fourth validation information using its ID (i.e., the of the device) .

[0158] In prior art, existing techniques in 5G System as defined in the 3GPPTM Technical Specifications, assume that both the first domain 1 and the second domain 2 know the device’s unique ID (SUPI) , but in the present scenario, the second domain 2 does not know the device’s unique ID (also referred to herein as device ID, ID of the device, real ID of the device) . Thus, current techniques cannot provide user authentication / identification while still protecting device ID privacy. Moreover, the existing authentication techniques (e.g., 5G-AKA’) assume that there is a share key between the device and the user before implementing authentication during a roaming scenario. But according to the assumption for the present scenario, there is initially no share key  between the device and the user 1. Thus, current techniques do not offer any solutions for the present scenario. Advantageously, embodiments disclosed herein provide systems and methods on multiple user authentication / identification in cross-domain communications, where network functions and / or entities (e.g., services, applications) could identify and validate a device that has multiple temporary IDs, and at the same time, these network functions or entities cannot link these temporary IDs with the (i.e. specific) device.

[0159] In embodiments, four example use cases pertaining multiple user authentication / identification in cross-domain communications are described below with corresponding embodiment examples.

[0160] The first use case 1 includes a 6G core network as the first domain 1 810 and NET4DW as the second domain 2 820 with reference to FIG. 8. It is assumed in this use case 1 that a D-user (i.e., user) is already created by the 6G core network, i.e., by the first domain 1 810. This D-user is already binding (e.g., linked, assigned) to (or bound with) a device (e.g., a 6G device) . The D-user’s information, such as D-user ID, is kept at or known to the identity manager, such as an IDM or another suitable network system, of the first domain 1. It is further assumed that the device is authenticated by the 6G core network when the device initially accesses the 6G core network. The user authentication / identification process is triggered by the 6G core network.

[0161] In a first embodiment, a system and method for multiple user authentication and identification in the first use case 1 are described by way of an example. The purpose of the procedures of the first embodiment is as follows. Firstly, when the 6G core network creates the D-user, the 6G core network assigns the D-user to the device (i.e., binds them together) . Thus, the D-user’s credential for authentication could be related to the device. In other words, the 6G core network can generate a credential for the D-user. Secondly, the 6G core network launches or initiates an authentication of the D-user of the second domain and the device of the first domain. Thirdly, since the device has multiple temporary IDs, the D-user could identify the device using one or more of the temporary IDs. The results of implementing the procedures of this embodiment include the D-user having a provisioned (e.g., negotiated or generated) first key K with the device, and another provisioned (e.g., negotiated or generated) second key K-D with the NET4DW, and that the device has a provisioned (e.g., negotiated or generated) first key K with the D-user.

[0162] With reference to FIGs. 10A and 10B, when a device 1005 associated with the first domain 810 requests for a NET4DW service of the second domain 820, in a first step 1051 the 6G core network runs (or may run) a secondary authentication / authorization for the device 1005. The current 5G technique known in the art according to 3GPPTM TS 23.502 titled "Security architecture and procedures for 5G System” can be used to provide the secondary authentication / authorization procedure at the first 1051 for the device 1005. After the secondary authentication / authorization procedure (e.g., if it is successful) , the 6G core network triggers multiple user authentication / identification in cross-domain communications described in the following steps below.

[0163] In a second step 1052, the IDM 1012 generates identification information based on device’s temporary IDs and D-user ID, and later, following the generation of credential for identification information, the IDM 1012 generates a credential for identification information based on the generated identification information. The credential for identification information is to be used for validation of the D-user and the device.

[0164] In a third step 1053, the IDM 1012 sends message3 1053a to the AUSF1 1015. As detailed in FIG. 10B, message3 1053a may have a name of “Auth_6G request” and key content that includes identification information, credential for identification information, and D-user ID.

[0165] In a fourth step 1054, the AUSF1 1015 validates the credential for identification information based on the D-user ID. When the validation is successful, the AUSF1 1015 then generates a credential for AUSF1 (also referred to herein as AUSF1 credential) according to the received credential for identification information from the IDM 1012, or according to the identification information, or according to the AUSF1’s information (e.g., AUSF1 ID) .

[0166] In a fifth step 1055, the AUSF1 1015 sends a message5 1055a to the AUSF2 1025. As detailed in FIG. 10B, message5 1055a may have a name of “Auth_cross_domain request” and key content that includes identification information, AUSF1 credential, and D-user ID.

[0167] In a sixth step 1056, the AUSF2 1025 validates the received AUSF1 credential based on the identification information, or based on the AUSF1’s information (e.g., AUSF1 ID) , and, when validation is successful, generates a new credential for AUSF2 (also referred to herein as AUSF2 credential) according to the received AUSF1 credential, or according to the  identification information, or according to the AUSF2’s information (e.g. AUSF2 ID) . If the validation is not successful, the AUSF2 1025 can consider the authentication as failed, and indicate a failure to the AUSF1 1015.

[0168] In a seventh step 1057, the AUSF2 1025 sends message7 1057a to the D-user 1031. As detailed in FIG. 10B, message7 1057a may have a name of “Auth_NET4DW request” and key content that includes identification information and AUSF2 credential.

[0169] In an eighth step 1058, the D-user 1031 validates the received AUSF2 credential based on the identification information, or based on the AUSF2’s information (e.g. AUSF2 ID) . Then, when the validation of the AUSF2 credential is successful, the D-user 1031 validates the identification information based on the inputs of the D-user ID and the device’s current temporary ID of device’s all temporary IDs. If the validation of the identification information is successful, the D-user 1031 may generate parameters for key negotiation, and may, optionally, generate a credential for the D-user (also referred to herein as D-user credential) . If the validation is not successful, the D-user 1031 considers the authentication as failed, and indicates a failure to the AUSF1 1015.

[0170] In a ninth step 1059, the D-user 1031 generates parameters for key negotiation, and sends message9 1059a to the AUSF2 1025. As detailed in FIG. 10B, message9 1059a may include, as key content, the D-user credential if the D-user 1031 generates the D-user credential based on the D-user ID. Alternatively, the D-user credential, if generated, may be sent to the AUSF2 1025 in a separate message (not shown) . Message9 1059a may have a name of “Auth_NET4DW response” and key content that includes the optional D-user credential, and parameters for key negotiation.

[0171] In a tenth step 1060, the AUSF2 1025 may validate the D-user credential if mssage9 1059a, or another message, includes the D-user credential.

[0172] In an eleventh step 1061, the AUSF2 1025 sends message11 1061a to the AUSF1 1015. As detailed in FIG. 10B, message11 1061a may have a name of “Auth_cross_domain response” and key content that includes the parameters for key negotiation.

[0173] In a twelfth step 1062, the AUSF1 1015 and the D-user 1031 negotiate a first key K, or each of them generates the first key K, according to the received parameters for key negotiation. The AUSF2 and the D-user 1031 negotiate a second key K-D, or each of them generates the second key K-D, according to the received parameters for key negotiation.

[0174] In a thirteenth step 1063, the AUSF1 1015 sends message13 1063a to the device 1005. As detailed in FIG. 10B, message13 1063a may have a name of “Auth_response” and key content that includes identification information, D-user ID, and parameters for key negotiation or (negotiated or generated) first key K.

[0175] In a fourteenth step 1064, the device 1005 validates the identification information based on the inputs of D-user ID and the device’s current temporary ID (i.e., same current temporary ID used in eighth step 1058) .

[0176] The second use case 2 involves the 6G core network as the first domain 1 810 and NET4DW as the second domain 2 820 with reference to FIG. 8. It is assumed that the D-user is already created by the 6G core network, but the D-user is not binding to (or not bound with) the device (e.g., 6G device) . When the D-user is created, the 6G core network registers the D-user to a CA to obtain a D-user certificate. The D-user’s information, such as D-user ID and the D-user certificate, is kept at or known to the identity manager, such as the IDM or another suitable network system, of the first domain 1. It is also assumed that the device is authenticated by the 6G core network when the device initially accesses the 6G core network. The user authentication / identification process is triggered by the 6G core network.

[0177] In a second embodiment, a system and method for multiple user authentication and identification in the second use case 2 are described by way of an example. The purpose of the procedures of the second embodiment is as follows. Firstly, the 6G core network launches the authentication of the D-user and the device. Secondly, due to temporary IDs for the device, the D-user can identify the device using one or more of the temporary IDs.

[0178] The results of implementing the procedures of the second embodiment include the D-user having a first provisioned (e.g., negotiated or generated) key K with the device and having a second provisioned (e.g., negotiated or generated) key K-D with the NET4DW; and that the device having a first provisioned (e.g., negotiated or generated) key K with the D-user.

[0179] With reference to FIGs. 11A and 11B, when the device 1105 associated with the first domain 810 requests for a NET4DW service of the second domain 820, in a first step 1151, the 6G core network runs a secondary authentication / authorization  for device 1105. The current 5G technique known in the art according to 3GPPTM TS 23.502 titled " Security architecture and procedures for 5G System” can be used to provide the secondary authentication / authorization procedure for the device 1105. After the secondary authentication / authorization procedure (i.e., if it is successful) , the 6G core network triggers multiple user authentication / identification in cross-domain communications described in the following steps below.

[0180] In a second step 1152, the IDM 1112 generates identification information based on the device’s temporary IDs and the D-user ID.

[0181] In a third step 1153, the IDM 1112 sends message3 1153a to the AUSF1 1115. As detailed in FIG. 11B, message3 1153a may have a name of “Auth_6G request” and key content that includes identification information, D-user certificate, and D-user ID.

[0182] In a fourth step 1154, the AUSF1 1115 validates the D-user certificate. When the validation of the D-user certificate is successful, the AUSF1 may generate a certificate for AUSF1 (also referred to herein as AUSF1 certificate) based on AUSF1’s information (e.g., AUSF1 ID) .

[0183] In a fifth step 1155, when the validation of the D-user certificate at the fourth step 1154 is successful, the AUSF1 1115 sends message5 1155a to the AUSF2 1125. As detailed in FIG. 11B, message5 1155a may have a name of “Auth_cross_domain request” and key content that includes identification information, (optional) AUSF1 certificate (i.e., if such was generated or obtained) , D-user ID, (optional) D-user’s certificate is such was generated at or following step 1154 above, and (optional) device certificate from the identity manager IDM 1112.

[0184] In a sixth step 1156, the AUSF2 1125 validates the received certificates from the AUSF1 1115. If the validation fails, the AUSF2 1125 considers the authentication as failed, and indicates a failure to the AUSF1 1115. When the validation is successful, the AUSF2 1125 generates a certificate for the AUSF2 1125 (also referred to herein as AUSF1 certificate) based on AUSF2’s information (e.g., AUSF2 ID) .

[0185] In a seventh step 1157, the AUSF2 1125 sends message7 1157a to the D-user 1131. As detailed in FIG. 11B, message7 1157a may have a name of “Auth_NET4DW request” and key content that includes identification information, and the AUSF2 certificate.

[0186] In an eighth step 1158, the D-user 1131 validates the received AUSF2 certificate. Then, when the validation of the AUSF2 certificate is successful, the D-user 1131 validates the identification information based on the inputs of D-user ID and the device’s temporary ID. If the validation fails, then the D-user 1131 considers the authentication as failed, and indicates a failure to the AUSF2 1125.

[0187] In a ninth step 1159, the AUSF2 1125 and the D-user 1131 negotiate a second key K-D, or each of them generates the second key K-D.

[0188] In a tenth step 1160, the AUSF2 1125 sends message10 1160a to the AUSF1 1115. As detailed in FIG. 11B, message10 1160a may have a name of “Auth_cross_domain response” and key content that includes an indication of key negotiation (e.g., indicative of a successful authentication between AUSF1 and the user) .

[0189] In an eleventh step 1161, the AUSF1 1115 generates parameters for key negotiation. Then, the AUSF1 1115 and the D-user 1131 negotiate a first key K, or each of them generates the first key K, according to the parameters for key negotiation.

[0190] In a twelfth step 1162, the AUSF1 1115 sends amessage12 1162a to the D-user 1131. As detailed in FIG. 11B, message12 1162a may have a name of “Negotiation notify message” and key content that includes parameters for key negotiation.

[0191] In a thirteenth step 1163, the AUSF1 1115 sends message13 1163a to the device 1131. As detailed in FIG. 11B, message13 1163a may have a name of “Auth_response” and key content that includes identification information, D-user ID, and parameters for key negotiation or the (negotiated or generated) first key K.

[0192] In a fourteenth step 1164, the device 1105 validates the identification information based on the inputs of D-user ID and the device’s current temporary ID.

[0193] The third use case 3 involves the 6G core network as the first domain 1 810 and NET4DW as the second domain 2 820 with reference to FIG. 8. It is assumed that the D-user is already created by NET4DW, and the D-user is binding to (or is bound with) the device (e.g., 6G device) . The D-user’s information, such as D-user ID, is kept at or known to the identity manager, such as the IDM or another suitable network system, of the first domain 1. It is also assumed that the device is authenticated by the 6G  core network when the device initially accesses the 6G core network. In this use case 2, the user authentication / identification process is triggered by the NET4DW.

[0194] In a third embodiment, a system and method for multiple user authentication and identification in the third use case 3 are described by way of an example. The purpose of the procedures of this embodiment is as follows. Firstly, the 6G core network should generate a credential for the D-user. Secondly, the 6G core network launches an authentication of the D-user and the device. Thirdly, due to multiple (i.e., one or more) temporary IDs for the device, the D-user could identify the device using one or more of the (all) temporary IDs.

[0195] The results of implementing the procedures of the third embodiment include the D-user having a first provisioned (e.g., negotiated or generated) key K with the device and having a second provisioned (e.g., negotiated or generated) key K-D with a NET4DW; and that device having the first key K with the D-user.

[0196] With reference to FIGs. 12A and 12B, in a first step 1251, the D-user 1231 of a second domain 820 sends message1 1251a to the AUSF2 1225 of the second domain 820. As detailed in FIG. 12B, message1 1151a may have a name of “Auth_NET4DW request” and key content that includes the D-user ID. In response to message1 1251a, the AUSF2 1225 may generate a certificate for AUSF2 (also referred to herein as AUSF2 certificate) based on AUSF 2’s information (e.g., AUSF2 ID) .

[0197] In a second step 1252, the AUSF2 1225 sends message2 1252a to the AUSF1 1215 of the first domain 810. As detailed in FIG. 12B, message2 1252a may have a name of “Auth_cross_domain request” and key content that includes the AUSF2 certificate (if such was generated and provide by the AUSF2) , and the D-user ID.

[0198] In a third (optional) step 1253, the AUSF1 1215 validates the AUSF2 certificate. If validation fails, the AUSF1 1215 considers the authentication as failed, and indicates a failure to the AUSF2 1225.

[0199] In a fourth step 1254, the AUSF1 1215 sends message4 1254a to the IDM. As detailed in FIG. 12B, message4 1254a may have a name of “Auth_6G request” and key content that includes the D-user ID.

[0200] In a fifth step 1255, the IDM 1212 generates identification information based on the device’s temporary IDs and the D-user ID. Later, following the generation of credential for identification information, the IDM 1212 generates a credential for identification information based on the identification information. The credential for identification information is to be used for validation of the D-user 1231 and the device 1205.

[0201] In a sixth step 1256, the IDM 1212 sends message6 1256a to the AUSF1 1215. As detailed in FIG. 12B, message6 1256a may have a name of “Auth_6G response” and key content that includes identification information, and credential for identification information.

[0202] In a seventh step 1257, the AUSF1 1215 validates the credential for identification information based on the D-user ID. If the validation is successful, then the AUSF1 1215 generates a credential for the AUSF1 (also referred to herein as the AUSF1 credential) according to the received credential for identification information from the IDM 1212, or according to the identification information, or according to the AUSF1’s information (e.g. AUSF1 ID) .

[0203] In an eighth step 1258, the AUSF1 1215 sends message8 1258a to the AUSF2 1225. As detailed in FIG. 12B, message8 1258a may have a name of “Auth_cross_domain response” and key content that includes identification information, and AUSF1 credential.

[0204] In a ninth step 1259, the AUSF2 1225 validates the received AUSF1 credential based on the identification information, or based on the AUSF1’s information, and generates a new credential for the AUSF2 (also referred to herein as the AUSF2 credential) according to the received credential from AUSF1, or according to the identification information, or according to the AUSF2’s information (e.g. AUSF2 ID) , if the validation is successful. Otherwise, if the validation is fails, the AUSF2 1225 considers the authentication as failed, and indicates a failure to the AUSF1 1215.

[0205] In a tenth step 1260, the AUSF2 1215 sends message10 1260a to the D-user 1231. As detailed in FIG. 12B, message10 1260a may have a name of “Auth_NET4DW response” and key content that includes identification information, and AUSF2 credential.

[0206] In an eleventh step 1261, the D-user 1231 validates the received AUSF2 credential based on the identification information, or based on the AUSF2’s information (e.g. AUSF2 ID) . Then, when the validation of the AUSF2 credential is successful, the D-user 1231 validates the identification information based on the inputs of D-user ID and the device’s temporary  ID.If the validation of the identification information is successful, the D-user 1231 may generate parameters for key negotiation and may generate a credential for the D-user based on the D-user ID. Otherwise, the D-user 1231 considers the authentication as failed, and indicates a failure to the AUSF2.

[0207] In a twelfth step 1262, the D-user 1231 sends message12 1262a to the AUSF2 1225. This message12 1262a may include the D-user credential if the D-user 1231 generates a D-user credential based on the D-user ID. As detailed in FIG. 12B, message12 1262a may have a name of “Auth_NETDW response” and key content that includes (optional, if generated) D-user credential, and parameter for key negotiation.

[0208] In a thirteenth step 1263, the AUSF2 1225 may validate the D-user credential if message 121262a includes the D-user credential.

[0209] In a fourteenth step 1264, the AUSF1 1215 and the D-user 1231 negotiate a first key K, or each of them generates the first key K, according to the received parameters for key negotiation. The AUSF2 1225 and the D-user 1231negotiate a second key K-D, or each of them generates the second key K-D, according to the received parameters for key negotiation.

[0210] In a fifteenth step 1265, the AUSF1 1215 sends message15 1265a to the device 1205. As detailed in FIG. 12B, message15 1265a may have a name of “Auth_response” and key content that includes identification information, D-user ID, and parameters for key negotiation or the first key K.

[0211] In a sixteenth step1266, the device 1205 validates the identification information based on the inputs of the D-user ID and the device’s current temporary ID.

[0212] The fourth use case 4 involves the 6G core network as the first domain 1 and NET4DW as the second domain 2 with reference to FIG. 8. It is assumed that the D-user of the second domain is already created by NET4DW, but the D-user is not binding to (or not bound with) the device (e.g., 6G device) associated with the first domain. When the D-user is created, NET4DW should facilitate registration of the D-user to a CA to obtain the D-user certificate. The D-user’s information, such as the D-user ID and the D-user certificate, is kept at or known to the identity manager, such as the IDM or another suitable network system, in the first domain 1. It is also assumed that the device is authenticated by the 6G core network when the device initially accesses the 6G core network. In this use case 2, the user authentication / identification process is triggered by NET4DW.

[0213] In a fourth embodiment, a system and method for multiple user authentication and identification in the fourth use case 4 are described by way of an example. The purpose of the procedures of this embodiment is as follows. Firstly, the 6G core network launches an authentication of the D-user and the device. Secondly, due to the temporary IDs for the device, the D-user is able to identify the device.

[0214] The results of implementing the procedures of the fourth embodiment include the D-user having a first provisioned (e.g., negotiated or generated) key K with the device and having a second provisioned (e.g., negotiated or generated) key K-D with the NET4DW; and the device having the first key K with the D-user.

[0215] With reference to FIGs. 13A and 13B, in a first step 1351, the D-user 1331 sends message1 1351a to the AUSF2 1325. As detailed in FIG. 13B, message1 1351a may have a name of “Auth_NET4DW request” and key content that includes the D-user certificate, and the D-user ID.

[0216] In a second step 1352, the AUSF2 1325 validates the D-user certificate. If the validation is successful, then the AUSF2 1325 triggers the user authentication / identification procedure and generates the AUSF2 certificate based on AUSF2’s information (e.g., AUSF2 ID) .

[0217] In a third step 1353, the AUSF2 1325 sends message3 1353a to the AUSF1 1315. As detailed in FIG. 13B, message3 1353a may have a name of “Auth_cross_domain request” and key content that includes AUSF2 certificate, D-user ID, and D-user certificate.

[0218] In a fourth step, the AUSF1 1315 validates the D-user certificate and the AUSF2 certificate. If validation fails (i.e., validation of the D-user certificate, the AUSF2 certificate, or both) , then the AUSF1 1315 considers the authentication as failed, and indicates a failure to the AUSF2 1325.

[0219] In a fifth step 1355, the AUSF1 1315 sends message5 1355a to the IDM 1312. As detailed in FIG. 13B, message5 1355a may have a name of “Auth_6G request” and key content that includes D-user ID.

[0220] In a sixth step 1356, the IDM 1312 binds the device and the D-user, and generates identification information.

[0221] In a seventh step 1357, the IDM 1312 sends message7 1357a to the AUSF1 1315. As detailed in FIG. 13B, message7 1357a may have a name of “Auth_6G response” and key content that includes the identification information. In response to receiving message7 1357a, the AUSF1 may generate the AUSF1 certificate based on AUSF1’s information (e.g., AUSF1 ID) .

[0222] In an eighth step 1358, the AUSF1 1315 sends message8 1358a to the AUSF2 1325. As detailed in FIG. 13B, message8 1358a may have a name of “Auth_cross_domain response” and key content of identification information, and AUSF1 certificate.

[0223] In a ninth step 1359, the AUSF2 1325 validates the received AUSF1 certificate. If the validation fails, then the AUSF2 1325considers the authentication as failed, and indicates a failure to the AUSF1 1315. If the validation is successful, the AUSF2 1325 generates the AUSF2 certificate based on AUSF2 information (e.g., AUSF2’s ID) .

[0224] In a tenth step, the AUSF2 1325 sends a message10 to the deviceD-user 1331. As detailed in FIG. 13B, message10 1360a may have a name of “Auth_NET4DW response” and key content that includes identification information, and AUSF2 certificate.

[0225] In an eleventh step 1361, the D-user 1331 validates the received AUSF2 certificate. Then, when the validation of the AUSF1 certificate is successful, the D-user 1331 validates the identification information based on the inputs of the D-user ID and the device’s temporary ID. If the validation of the identification information fails (i.e., following a failed validation of the device) , the validation of the AUSF2 certificate fails, or both, then the D-user 1331 considers the authentication as failed, and indicates a failure to the AUSF1.

[0226] In a twelfth step 1362, the AUSF1 1315 and the D-user 1331 negotiate a first key K, or each of them generates the first key K; and the AUSF2 1325 and the D-user 1331 negotiate a second key K-D, or each of them generates the second key K-D.

[0227] In a thirteenth step 1363, the AUSF1 1315 sends amessage13 1363a to the device 1305. As detailed in FIG. 13B, message13 1363a may have a name of “Auth_response” and key content that includes identification information, D-user ID, and parameters for key negotiation or the first key K.

[0228] In a fourteenth step 1364, the device 1305 validates the identification information based on the inputs of the D-user ID and the device’s current temporary ID.

[0229] Cross-domain authentication may be triggered or initiated by a user of one or more users of the domain associated with the one or more users (e.g., the first user 831 or the second user 832 of the second domain 820 of FIG. 8) . Additionally, or alternatively, the cross-domain authentication may be triggered or initiated by a network function (e.g., NET4DW) of the domain associated with the one or more users (e.g., the second domain 820 of FIG. 8) . Such triggering or initiating may include providing, by the user or the network function of the domain associated with the one or more users, a request, such as, but not limited to, message1 1251a of FIG. 12B, or message1 1351a of FIG. 13B. Such request may be indicative of the user requesting access to a service (e.g., metaverse) associated with the domain associated with the one or more users. The request, or a message indicative thereof may be received and processed by the authenticator of the domain associated with the one or more users (e.g., AUSF2 1325 of FIG. 13A) .

[0230] Methods and systems disclosed herein provide for improvement of communication privacy by protecting the device ID privacy during cross-domain authentication process. In other words, another domain, outside the domain that the device is associated with, does not have any information indicative of the unique (i.e., real) ID of the device.

[0231] Methods and systems disclosed herein provide for improvement of communication security by providing authentication procedures of the device and the D-user in cross-domain communications.

[0232] Methods and systems disclosed herein provide for improved communication overhead. Using the identification information generated using the temporary IDs of the device and the user ID of the D-user, cross-domains external to the domain the device is associated with are able identify the device without knowing the device ID, thereby avoiding having to run a new authentication of the device and the D-user, which may reduce communication overhead.

[0233] Although this disclosure refers to illustrative embodiments, this is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the disclosure, will be apparent to persons skilled in the art upon reference to the description.

[0234] Features disclosed herein in the context of any particular embodiments may also or instead be implemented in other embodiments. Method embodiments, for example, may also or instead be implemented in apparatus, system, and / or computer program product embodiments. In addition, although embodiments are described primarily in the context of methods and apparatus, other implementations are also contemplated, as instructions stored on one or more non-transitory computer-readable media, for example. Such media could store programming or instructions to perform any of various methods consistent with the present disclosure.

[0235] In the present disclosure, the terms “a” or “an” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0236] In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an example embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of the example embodiment for its intended application.

[0237] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0238] In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching the two elements but also “substantially” , “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

[0239] In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

[0240] In the present disclosure, the terms "system" and "network" may be used interchangeably in different embodiments of this application. "At least one" means one or more, and "a plurality of" means two or more. The term "and / or" describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character " / " indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes: only A; only B; only C; A and B; A and C; B and C; or A, B, and C, and "at least one of A, B, and C" may also be understood as including: only A; only B; only C; A and B; A and C; B and C; or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0241] This application is described with reference to the flowcharts and / or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device and enable a machine to execute the instructions. When executed by any computer or the processor of a programmable data processing device, the instructions cause the apparatus to implement specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams. The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that  includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0242] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or on another programmable device provide steps for implementing specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0243] It is clear that a person skilled in the art can make various modifications and variations to this application without departing from the scope of this disclosure. This disclosure is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

Claims

1.A method for cross-domain authentication, the method comprising:generating, by an identity manager configured to manage identifiers (IDs) at a first domain in a network, a first validation information, the first validation information including an identification information generated based on all temporary IDs of a device associated with the first domain in the network and user IDs of one or more users associated with a second domain in the network, the identification information being for authentication between the device and the one or more users; andsending, by the identify manager, the first validation information towards a user of the one or more users.2.The method of claim 1, wherein the all temporary IDs of the device are generated by the identity manager and are mapped to a real ID of the device.3.The method of claim 1, wherein each user of the one or more users is a physical user or a virtual representation of the physical user.4.The method of claim 1, wherein the first validation information further includes a credential generated based on the identification information.5.The method of claim 1, wherein the first validation information further includes a respective one or more certificates for the one or more users.6.The method of claim 1, further comprising binding, by the identity manager, the device with the one or more users.7.The method of claim 1, further comprising receiving, by the identity manager, the user IDs of the one or more users.8.A method for cross-domain authentication, the method comprising:by a first authenticator associated with a first domain of a network:obtaining a first validation information that includes an identification information, the identification is generated based on:user identifiers (IDs) for one or more users associated with the first domain; andall temporary IDs for a device associated with the second domain;subsequent the validating of the first validation information, generating a second validation information that includes the identification information; andproviding the second validation information towards a user of the one or more users for a second validation.9.A method for cross-domain authentication, the method comprising:generating, by an identity manager configured to manage identifiers (IDs) at a first domain in a network, a first validation information including:an identification information generated by the identity manager based on:user IDs of one or more users associated with a second domain in the network; andall temporary IDs of a device associated with the first domain in the network;providing the first validation information to a first authenticator associated with the first domain for a first validation;generating, at the first authenticator, when the first validation is successful, a second validation information comprising the identification information;providing the second validation information to a second authenticator associated with the second domain for a second validation;generating, at the second authenticator, when the second validation is successful, a third validation information comprising the identification information; andproviding, the third validation information to a user of the one or more users for a third validation.10.The method of claim 9, further comprisinggenerating, at the user, when the third validation is successful, parameters for provisioning:a first key for secure communication between the user and the first domain; anda second key for secure communication between the user and the second domain; andproviding, to the device, for a fourth validation:the identification information;a user ID of the user; andthe parameters or the first key.11.The method of claim 9 or 10, the all temporary IDs of the device being mapped to a real device ID of the device, the real ID of the device being secured with the identity manager.12.The method of any one of claims 9 to 11, wherein the user is physical user or virtual representation of the physical user.13.The method of any one of claims 9 to 12, wherein:the first validation information further includes a credential for the identification information generated based on the identification information;the first validation comprises validating the credential for the identification information.14.The method of claim 13, wherein:the second validation information further includes a first authenticator credential for the first authenticator, the first authenticator credential being generated in response to the successful validation of the credential for the identification information; andthe second validation comprises validating the first authenticator credential.15.The method of claim 14, the first authenticator credential is generated according to one or more of:the credential for the identification information;the identification information; andfirst authenticator information.16.The method of claim 14 or 15, wherein:the third validation information further includes a second authenticator credential for the second authenticator, the second authenticator credential being generated based on the first authenticator credential in response to the successful validation of the first authenticator credential; andthe third validation comprises validating the second authenticator credential.17.The method of claim 16, whereinthe second authenticator credential is generated according to one or more of:the first authenticator credential;the identification information; andsecond authenticator information.18.The method of any one of claims 9 to 12, wherein:the first validation information further includes a user certificate for the user;the first validation comprises validating the user certificate.19.The method of claim 18, wherein:the second validation information further includes one or more of:the user certificate;a first authenticator certificate for the first authenticator; anda device certificate for the device.20.The method of claim 19, wherein:the second validation comprises, respectively, validating, the one or more of:the user certificate;the first authenticator certificate; andthe device certificate.21.The method of claim 20, wherein:the third validation information further includes a second authenticator certificate for the second authenticator; andthe third validation comprises validating the second authenticator certificate.22.The method of claim 9, further comprising binding, at the identity manager, the device with the one or more users.23.The method of claim 18, further comprising:by the second authenticator:receiving, from the user, an authentication request comprising the user ID;generating a second authenticator certificate for the second authenticator;providing, by the second authenticator to the first authenticator, the user ID and the second authenticator certificate; andby the first authenticator:validating the second authenticator certificate;providing to the identity manager, when validating the second authenticator certificate is successful, the user ID.24.An apparatus, configured to perform the method of any one of claims 1 to 8.25.The apparatus of claim 24, wherein the apparatus is configured to:manage identifiers (IDs) at the first domain in the network;the apparatus comprising:a processing unit configured to generate a first validation information, the first validation information including an identification information generated based on all temporary IDs of a device associated with the first domain in the network and user IDs of one or more users associated with a second domain in the network, the identification information being for authentication between the device and the one or more users; anda transmitting unit configured to send the first validation information towards a user of the one or more users.26.The apparatus of claim 25, wherein the all temporary IDs of the device are mapped to a real ID of the device.27.The apparatus of claim 25, wherein each user of the one or more users is a physical user or a virtual representation of the physical user.28.The apparatus of claim 25, wherein the first validation information further includes a credential generated based on the identification information.29.The apparatus of claim 25, wherein the first validation information further includes a respective one or more user certificates for the one or more users.30.The apparatus of claim 25, the processing unit is further configured to bind the device with the one or more users.31.The apparatus of claim 25, further comprising a receiving unit configured to receive the user IDs of the one or more users.32.An apparatus, comprising one or more processors, the one or more processor is configured to execute instructions stored in one or more memory to implement the method of any one of claims 1 to 8.33.A computer-readable storage medium having instructions stored thereon which, when executed by a one or more processors cause the one or more processors to perform the method of any one of claims 1 to 8.34.A system for cross-domain authentication, the system comprising:an identity manager associated with a first domain in a network, the identity manager configured to:manage identifiers (IDs) at a first domain in a network; andgenerate a first validation information including an identification information generated based on:user IDs of one or more users associated with a second domain in the network; andall temporary IDs of a device associated with the first domain in the network;a first authenticator associated with the first domain of the network, the first authenticator configured to:obtain the first validation information for a first validation;generate, when the first validation is successful, a second validation information comprising the identification information; andprovide the second validation information to a second authenticator associated with the second domain for a second validation.35.The system of claim 34, wherein the second authenticator is configured to:generate, when the second validation is successful, a third validation information comprising the identification information; andprovide the third validation information to a user of the one or more users for a third validation.36.The system of claim 34, wherein:the first validation information further includes a credential for the identification information generated based on the identification information; andthe first validation comprises validating the credential for the identification information.37.The system of claim 36, wherein:the second validation information further includes a first authenticator credential for the first authenticator, the first authenticator credential being generated in response to the successful validation of the credential for the identification information; andthe second validation comprises validating the first authenticator credential.38.The system of claim 37, wherein the first authenticator credential is generated according to one or more of:the credential for the identification information;the identification information; andfirst authenticator information.39.The system of claim 35, wherein:the first validation information further includes a user certificate for the user; andthe first validation comprises validating the user certificate.40.The system of claim 39, wherein the second validation information further includes one or more of:the user certificate;a first authenticator certificate for the first authenticator; anda device certificate for the device.41.The system of claim 40, wherein the second validation comprises, respectively, validating, the one or more of:the user certificate;the first authenticator certificate; andthe device certificate.42.The system of claim 34, wherein the identity manager is further configured to bind the device with the one or more users.

Images