User identifier and credential management for wireless mobile networks

Abstract

In one or more methods, devices, and / or systems, solutions are provided for managing wireless communication. For example, managing wireless communication may include a trust enabler client registration process implemented by one or more devices. For example, managing wireless communication may include a distributed user identifier registration process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, for multiple mobile devices, etc.). For example, managing wireless communication may include a distributed verifiable user credential generation process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, etc.).

Description

USER IDENTIFIER AND CREDENTIAL MANAGEMENT FOR WIRELESS MOBILE NETWORKSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 554,044, filed February 15, 2024, the contents of which are incorporated herein by reference.BACKGROUND

[0002] In wireless systems, there is a need for security between devices and the network.SUMMARY

[0003] In one or more methods, devices, and / or systems, solutions are provided for managing wireless communication. For example, managing wireless communication may include a trust enabler client registration process implemented by one or more devices. For example, managing wireless communication may include a distributed user identifier registration process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, for multiple mobile devices, etc.). For example, managing wireless communication may include a distributed verifiable user credential generation process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, etc.).BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0005] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0006] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0007] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0008] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0009] FIG. 2 illustrates an example of 5G security.

[0010] FIG. 3 illustrates an example of two use cases where improved or new security approaches are needed in mobile networks.

[0011] FIG. 4 illustrates an example of a trust enabler framework including related entities and functions.

[0012] FIG. 5 illustrates an example of a trust enabler framework with respect to a 3GPP system.

[0013] FIG. 6 illustrates an example of an on-network trust enabler framework.

[0014] FIG. 7 illustrates an example of an off-network trust enabler framework with a server (WTRU2) providing services to a client (WTRU1).

[0015] FIG. 8 illustrates an example of an off-network trust enabler framework with respect to a client (WTRU1) client (WTRU2) relationship.

[0016] FIG. 9 illustrates an example of TEC registration.

[0017] FIG. 10 illustrates an example of a WTRU initiated DUID registration.

[0018] FIG. 11 illustrates an example of a selection of shared WTRUs / TECs.

[0019] FIG. 12 illustrates an example of a network-initiated DUID registration.

[0020] FIG. 13 illustrates an example of a DUID registration for multiple TECs.

[0021] FIG. 14 illustrates an example of a process for WTRU initiated DVUC generation.

[0022] FIG. 15 illustrates an example of a relevant DVUC-ID.

[0023] FIG. 16 illustrates an example of network initiated DVUC generation.DETAILED DESCRIPTION

[0024] As used herein, one or more of the following acronyms / abbreviations may be used: 3GPP (3rd Generation Partnership Project), 5G (5th Generation), 5GC (5G Core Network), 5G DDNMF (5G Direct Discovery Name Management Function), 5GS (5G System), 5G-GUTI (5G Globally Unique Temporary Identity), 6G (6th Generation), 6GC (6G Core Network), 6GS (6G System), Addr (Address), AF (Application Function), AMF (Access and Mobility Management Function), API (Application Programming Interface), AS (Access Stratum), AUSF (Authentication Server Function), CAPIF (Common API Framework), CMF (Credential Management Function), DLS (Distributed Ledger System), DN (Data Network), DUID (Decentralized User Identifier), DVUC (Distributed Verifiable User Credential), ETSI (European Telecommunications Standards Institute), GPSI (Generic Public Subscription Identifier), GR (Group Report), GS (Group Specification), ID (Identifier), ISG (Industry Specification Group), LMF (Location Management Function), ME (Mobile Equipment), NAS (Non-Access Stratum), NEF (Network Exposure Function), NF (Network Function), NPN (Non-Public Network), NRF (Network Repository Function), NWDAF (Network Data Analytics Function), PCF (Policy Control Function), PDU (Protocol Data Unit), PLMN (Public Land Mobile Network), SA (Service Architecture), SBA (Service-Based Architecture), SEAF (Security Anchor Function), SIDF (Subscription Identifier Deconcealing Function), SNPN (Standalone NPN), SSI (Self-Sovereign Identity), SUCI (Subscription Concealed Identifier), SUPI (Subscription Permanent Identifier), TEC (Trust Enabler Client), TES (Trust Enabler Server), UCT (User-Centric Trust), UDM (Unified Data Management), UDR (Unified Data Repository), UDSF(Unstructured Data Storage Function), WTRU (User Equipment), ULT (User-Level Trust), USIM (Universal Subscriber Identity Module), ZTA (Zero-Trust Architecture).

[0025] In one or more methods, devices, and / or systems, solutions are provided for managing wireless communication. For example, managing wireless communication may include a trust enabler client registration process implemented by one or more devices. For example, managing wireless communication may include a distributed user identifier (DUID) registration process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, for multiple mobile devices, etc.). For example, managing wireless communication may include a distributed verifiable user credential (DVUC) generation process implemented by one or more devices (e.g., mobile device(s) initiated, network device(s) initiated, etc.).

[0026] As used herein, a device is a term equivalent to UE or WTRU (e.g., as further discussed herein). Device and WTRU may be interchangeably used herein unless explained otherwise.

[0027] As used herein, a Network Function (NF) is a processing function in a network (e.g., 5GC). A NF may also be, and may be interchangeable with as discussed herein, an AF, an edge application or service, a service provided by a device, an application provided at a device, server or service in a data network, and / or the like, unless disclosed otherwise.

[0028] As used herein, a User is an entity (e.g., such as a human, but not necessarily a human) that uses a WTRU (e.g., one who uses a device). A user may be outside of a WTRU, an entity within the WTRU, a construct of the authorization / authority / permission / access within a WTRU, within software of the WTRU, within a network, and / or the like. A NF consumer may be a user. An application running on a WTRU may be regarded as a user. A WTRU (e.g., especially a WTRU without USIM) may be regarded as a user. A device that uses a WTRU to get access to a (e.g., 3GPP, WALN, etc.) network may also be a user of this WTRU.

[0029] As used herein, a Distributed Ledger System (DLS) is a system that comprises of or uses distributed ledgers or distributed repositories. A DLS may include permissioned distributed ledgers / repositories and / or permissionless distributed ledgers / repositories. DLS as disclosed herein may also be referred to as trustworthy data storage or repository functions that cannot be attacked or fully dependent on a centralized party.

[0030] As used herein, a Distributed Trust (DT) is a direct trust relationship between two entities that does not rely on a centralized third party. Those two entities may be: a WTRU and a network; a user of a WTRU and a network; two or more users; two or more WTRUs; two or more NFs; and / or the like (e.g., as disclosed herein).

[0031] As used herein, a User-Level Trust (ULT) or User-Centric Trust (UCT) is a trust relationship between a user of a WTRU and a network, between a user of a WTRU and another WTRU, between a user of a WTRU and a network function, between a user of a WTRU and another user of another WTRU, between a NF consumer and a NF provider, and / or the like (e.g., as disclosed herein). ULT may be established without relying on a centralized party; in this case, ULT and DT may be the same or similar. ULT may be referred to as User- Centric Trust (UCT). ULT and UCT may be interchangeably as used herein unless otherwise disclosed.

[0032] As used herein, a T rusted Device refers to a device or WTRU that can be trusted by another Device, entities / users, and / or by a wireless system (e.g., such as 6G System (6GS), etc.). Trusted Device and Trusted WTRU may be used interchangeably in this disclosure unless otherwise disclosed.

[0033] As used herein, an identifier is the name / identifier / address of an entity (e.g., a device / WTRU, a network function such as 3GPP NFs and the proposed trust enabler server, an entity using a WTRU, etc.). An identifier may be a 3GPP identifier, an IP address, a URL (Uniform Resource Locator), a FQDN (Fully Qualified Domain Name), a blockchain address, etc. The identifier of an entity enables or gives access details based on which other entities may access and interact with this entity.

[0034] As used herein, a Distributed User Identifier (DUID) is a special type of globally unique identifier for a user that may be created and owned by the user without relying on a third party. A DUID may be independently formed or established by the user using a DUID generation algorithm or function, which may be based on some unique and private information of the user such as a private key, user attributes or properties, user biometrics. Any entity (e.g., a device, an application on the device, a service provided at a device, a NF) may create and possess a DUID as well.

[0035] As used herein, a Distributed Verifiable User Credential (DVUC) is a credential created or issued for a user. DVUC may be verified and authenticated in a distributed manner without contacting the party that creates DVUC. A user may have one or multiple DVUCs. When an unauthorized user needs to access services from an entity such as a NF, the user may present a DVUC to the entity to get the DVUC authenticated and eventually establish ULT / DT with the entity offering services. A new DVUC may deprecate an existing DVUC. A new DVUC may be dependent on one or multiple existing DVUC.

[0036] As used herein, a Service-Aware User Credential (SAUC) is a type of DVUC containing target services that DVUC may be applied to and service policies for these target services. SAUC may enable users to choose the right service providers more efficiently without an extra step(s) to consult with other parties. SAUC may allow service providers to check service policies directly avoiding contacting extra NFs such as PCF.

[0037] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0038] As shown in FIG. 1 A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0039] The com munications systems 100 may also incl ude a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0040] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0041] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0042] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

[0043] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0044] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.

[0045] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0046] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0047] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet anotherembodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0048] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0049] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0050] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0051] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0052] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0053] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0054] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0055] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0056] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, andstore data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0057] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.

[0058] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0059] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0060] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0061] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0062] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0063] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0064] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0065] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0066] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0067] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0068] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0069] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0070] In representative embodiments, the other network 112 may be a WLAN.

[0071] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0072] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0073] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0074] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may betransmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0075] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0076] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all ST As in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0077] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0078] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0079] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / orreceive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0080] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0081] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0082] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0083] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0084] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0085] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0086] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0087] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0088] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functionsdescribed herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0089] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

[0090] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0091] Generally, for a given system architecture of any past, present, or future wireless generation of technology, there may be a mobile device that communicates with one or more network devices and / or other mobile devices. Network devices, or functions, may interact with each other to provide communication services to the mobile device. As discussed herein, reference to any specific generation of a wireless system is for illustration purposes only, and intended to be non-limiting examples, where the specific generation mentioned could be interchangeable with any generation of technology (first gen, second gen, third gen, fourth gen, sixth gen, seventh gen, etc.). In a 5G system (5GS) (e.g., its architecture) may comprise of a mobile device (e.g., UE / WTRU), Radio Access Network (RAN), and Core Network (e.g., as described herein, such as with reference to FIG. 1 or any other figure). One of the design principles for the 5G System (5GS) is service-centric or servicebased. 5G Core Network (5GC) follows Service-Based Architecture (SBA) and contains a variety of Network Functions (NFs), which work together to fulfill and provide needed services to the RAN, WTRUs, and Application Servers / Service Providers. A WTRU may interact with the RAN / 5GC via Non-Access Statum (NAS) and Access Stratum (AS) signaling.

[0092] An NF may access other network functions in request / response mode or subscription / notification mode. Before two NFs interact with each other, they first register with a Network Repository Function (NRF) so that they can discover each other via the NRF. Among these network functions, an Access and Mobility Management Function (AMF) may be dedicated to managing a WTRU’s access to 5GS and its mobility, a Session Management Function (SMF) may be responsible for establishing sessions between a WTRU and 5GC, and a Authentication Server Function (AUSF) may handle WTRU authentication. Additionally, a PolicyControl Function (PCF) may manage / provide policy rules for other control plane network functions and WTRUs; the PCF may assign an identifier for each created policy rule, which other control plane network functions and / or WTRUs may use to refer to the corresponding policy rule. A User Plane Function (UPF) may be a core network function in the data plane that facilitates monitoring, managing, controlling, and redirecting user plane traffic flows such as between a WTRU and an Application Function (AF); in some instances, the UPF may be the only network node that does this. A Network Exposure Function (NEF) may enable access to 5G control plane functions to entities such as network applications and AFs which are outside of 5GS and not in the same trusted domain.

[0093] The 5GC may (also) provide data storage and / or analytics services through functions like a Unified Data Management (UDM), a Unified Data Repository (UDR), a Unstructured Data Storage Function (UDSF) and / or a Network Data Analytics Function (NWDAF). Another feature / function of 5GS is network slicing, which may be facilitated by a Network Slice Selection Function (NSSF).

[0094] The 5GS may also have Location Management Function (LMF) to support location services. The LMF may be responsible for calculating, determining, or verifying a final location and / or any velocity estimation, and may estimate the achieved accuracy, based on location information from the target WTRU and / or a RAN node. After LMF calculates the location of a target WTRU, other entities may access or query its location from LMF but need to go through a serving AMF.

[0095] Although NFs are defined as separate logical entities, a particular service scenario may require multiple network functions; for instance, WTRU mobility may need not only AMF, but also AUSF and SMF. For a type of network function, multiple instances could be instantiated and NRF may maintain the information of each instantiated network function instance. With the emergence of edge computing, some network functions in 5GC (e.g., UPF and NEF) may be deployed and reside in an edge network that is much nearer to and potentially co-located with the RAN.

[0096] FIG. 2 illustrates an example of 5G security. As shown, there may be 5G security functions may cover four different security domains within a 5G system (e.g., 200): security for network access between WTRU and RAN / 5GC (e.g., 221), network domain security between RAN and 5GC (e.g., 222), user domain security between Mobile Equipment (ME) and Universal Subscriber Identity Module (USIM) (e.g., 223), and SBA domain security in 5GC (e.g., 224). As may be understood from the figure, different (e.g., one or more) security domains may exist and / or are associated with relationships between different elements within a communications network. Additionally, as shown the network security access may be further illustrated at 231.

[0097] 5G network access security may be realized through network access authentication, message encryption, and / or message integrity protection. Network access authentication may include primary authentication and key agreement, and / or secondary authentication.

[0098] The primary authentication and key agreement may be designed to enable: 1 ) mutual authentication between WTRU and network; and 2) agreed keying material (e.g., an anchor key KSEAF) at both network side and WTRU side. The basis behind 5G primary authentication and key agreement is that the same long-termkey K unique to a WTRU may be securely maintained at USIM and network, based on which anchor key KSEAF and other key materials (e.g., keys for encryption and integrity protection for NAS and AS signaling) may independently and identically be derived at the WTRU and at network, without exchanging them over the air. Mutual authentication may be established when the WTRU and network approve to each other they know the same long-term key K. In one scenario where the primary authentication is solely based on the long-term key K, it may not consider user-centric aspects (e.g., user behaviors) and cannot authenticate / differentiate users from the same or different WTRUs.

[0099] The secondary authentication may be designed as an option to provide security between WTRU and external Data Network (DN) as a part of session management. The secondary authentication may rely on SMF to initiate and coordinate the authentication procedure between WTRU and DN (e.g., a DN-AAA Server).

[0100] In one case, Zero Trust Architecture (ZTA) principles may be applicable to a 5G system. For example, there may be a need for continuous security monitoring of NFs, which may be deployed in different environments and scenarios with potential errors and malicious attacks.

[0101] In one case, a distributed ledger system (DLS) may be employed with a 5G system. A blockchain system may be: 1) a permissionless blockchain system (e.g., Bitcoin, Ethereum, etc.) where any party or user can use and participate in the blockchain system without pre-granted permissions; or 2) a permissioned blockchain system where access to the blockchain system needs to be permissioned, controlled and / or governed. Permissioned Distributed Ledgers (PDL) as defined by ETSI Industry Specification Group (ISG) on PDL is an example of permissioned blockchain systems. A permission distributed ledger may be used in a 5GS.

[0102] A PDL in 5GS may involve a distributed ledger anchor function (DLAF), distributed ledger repository function (DLRF), and / or distributed ledger enabler (DLE). DLAF and DLRF may be control plane functions, while DLE may be a data plane function.

[0103] A PDL used with 5GS may have a native Self-Sovereign Identity (SSI) system under one or more constraints (e.g., standardization, telecom networks, etc.) so that a user or a network node holding such an identity may access network services among different operators and service providers seamlessly.

[0104] Cellular wireless systems (e.g., 5GS) may have one or more security functions, such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, data plane encryption and integrity protection, and / or the like. As technology progresses, new use cases arrive that require improved or novel approaches to address problems that arise out of these use cases. For example, there may be new trust requirements compared to a given wireless system, such as one or more of the following use case: 1) need for user-level trust between users of a device (WTRU301) and a network; 2) need trust between users in order to share services across devices (WTRU301 and WTRU302); and / or 3) a combination of the aforementioned, or other needs that arise from a use case not yet known. In all use cases, there is aneed for trust requirements in mobile networks that provide improved and / or novel approaches (e.g., increased functionality, efficiencies, addressing existing shortcomings, etc.).

[0105] FIG. 3 illustrates an example of two use cases where improved or new security approaches are needed in mobile networks. As shown, there may be two WTRUs 301 and 302, and a network 307. Two users may be associated with WTRU 301 and one user may be associated with WTRU 302. In a first use case, there is a need for user-level trust between users of a device (WTRU 301) and the network. In a second use case, there is a need for trust between users in order to share services across devices (WTRU 301 and WTRU 302). Both use cases lead to new trust requirements in future mobile networks as described herein.

[0106] In one use case, (e.g., case 1 in FIG. 3), WTRU 301 may be shared by multiple users (e.g., User 311 and User 312) that may change based on location, time, or other factors. For example, a vehicle with an embedded WTRU could be used to offer connectivity and services to all passengers (e.g., users who use the embedded WTRU to get access to network). Different users show different behaviors; they also may need different network functions, applications functions, and services. As such, the trust of these different users, referred to as user-level trust, should be established and in turn network access requests from them may be better authenticated and served based on user-level trust. The network in this use case may be a visited network or a home network (e.g., a Public Land Mobile Network (PLMN) or a Non-Public Network (NPN)). Use case 2 in FIG. 3 may also need user-level trust since multiple users from WTRU 301 attempt to access services from WTRU302.

[0107] In one example, an existing 5G primary authentication process may be used to authenticate WTRU 301 and build the trust for WTRU 301 , but this may not establish a trust relationship between users and network or between two NFs. Accordingly, there is a need for user-level trust to enable trustworthy network access for different users.

[0108] In one use case (e.g., case 2 in FIG. 3) WTRU 302 may provide some services (e.g., computing service, communication relaying service, local functions, local application functions or services), which WTRU 301 may request access to. As a service provider, WTRU 302 needs to authenticate and trust WTRU 301; as a service consumer, WTRU 301 also needs to authenticate and trust WTRU 302 (e.g., which provides one or more services). Such direct trust between two WTRUs (and / or between their users 311 , 312, and / or 313) is referred to as distributed trust. Another form of distributed trust is the direct trust between roaming WTRUs and a visited network (e.g., use case 1 of FIG. 3), which may be potentially established without relying on home network.

[0109] In one example, an existing 5G primary authentication may be considered to be a centralized solution, which relies on a home network that may have two shortcomings. First, the home network cannot be used to build a direct trust relationship between two WTRUs or users of those WTRUs. Second, when a home network becomes unavailable (e.g., outage, disaster, the event of many concurrent users), the primary authentication cannot be properly fulfilled. As a result, roaming users (e.g., in use case 1 of FIG. 3) cannot get the access to a visited network or home users cannot get the access to a RAN or edge networks. Accordingly,there is a need for distributed trust that does not rely on a home network so that users may access services from other WTRUs or networks even when the home network becomes unavailable.

[0110] In order to address the issues discussed herein, and others that arise from a wireless mobile communication system concerned in part with security, techniques may be employed that enable distributed and user-centric trust in any mobile network.

[0111] For example, to enable user-level trust, an approach is needed for how to manage user identifiers and user credentials, such as in a distributed manner without relying (e.g., fully or otherwise) on a centralized party. User identifier and user credential management may be considered to be a foundation for user-level trust. In systems where that do support user identifier and user credential management, there is a need to provide a solution to this problem. With appropriate user identifier and user credential management, any mobile networks may have the capability to be aware of different users and provide them needed services with a better quality of experience.

[0112] In one or more examples / techniques / approaches disclosed herein, one or more of the following goals / benefits are intended to be achieved: avoid single point of failure in trust authentication; flexible and applicable for different use cases (e.g., use cases such as those disclosed herein); avoid introducing high communication or computation overhead to devices; compatible with 3GPP architecture; easy integration with 3GPP SA2 or SA6 procedures; efficient user-level trust establishment without relying on a centralized party; efficient distributed trust establishment without relying on home network; and / or the like.

[0113] FIG. 4 illustrates an example of a trust enabler framework including related entities and functions. As shown, there may be a user / WTRU (e.g., 401 / 402), a Trust Enabler Client (TEC) (e.g., at the WTRU 402), a Trust Enabler Server (TES) 404 (e.g., note that TES 404 may have functions listed at 407), Credentials Management Function (CMF) 403, Service Provider 405, other network functions 406, and / or the like (e.g., other entity as disclosed herein, such as but not limited to other NFs 406).

[0114] In some cases, there may be a trust enabler framework that may include one or more of a Trust Enabler Client (TEC), Trust Enabler Server (TES), Credentials Management Function (CMF), Service Provider, and / or the like (e.g., other entity as disclosed herein).

[0115] A Trust Enabler Client (TEC) is a client that may be located within WTRU(s). A WTRU may have multiple TECs serving different users or applications. A user may be outside of a WTRU or an entity within the WTRU. A device that uses a WTRU to get access to 3GPP network may be a user of this WTRU. TEC may be implemented as a function, which can interact with TES and CMF on behalf of one or multiple WTRUs and / or users. WTRU may be regarded as a special user from TEC’s perspective.

[0116] A Trust Enabler Server (TES) is a server that provides a list of functions to TECs, CMFs, and other NFs (e.g., such as user identifier management, TEC registration, CMF registration, function exposure, interface to 3GPP NFs, or other entity disclosed herein). TES may be deployed at Edge / Core Network or even at another WTRU.

[0117] A Credentials Management Function (CMF) may provide user credential management (e.g., to issue DVUCs) to TECs. A CMF may also register itself to a TES. A TES may select and assign CMF to TECs and instruct TECs to request user credentials from assigned CMF (e.g., after registration). In one instance, a CMF may be integrated with TES and may be a part of TES; accordingly, even though a TES and CMF may be described separately herein, in at least one case, their respective description should take into the possibility that they are integrated or a part of each other.

[0118] A Service Provider is an entity or a domain providing services to users / WTRUs. TES and CMF may be a part of a service provider and they trust each other. CMF may also be outside of a service provider; for this case, the service provider and TES may trust user credentials generated by CMF. TES may be outside of a service provider; for this case, it is assumed that the service provider trusts TES. A service provider may provide its service through some other NFs, which TES can expose itself to or leverage for itself.

[0119] A trust enabler frame work may indude / enable one or more functions / methods, such as TEC registration, user identifier management, CMF registration, user credential management, exposure to other NFs, leverage other NFs, and / or one or more other functions / methods described herein.

[0120] A user identifier management function manages user identifiers, such as DUID registration, deregistration, update, and / or the like. Each user may have a DUID. A WTRU itself may have a DUID (e.g., as well). For example, in use case 1 of FIG. 3, WTRU 301 may have <WTRU1-DUID>, while Userl and User2 may have two different DUIDs: <User1-DUID> and <User2-DUID>, respectively. A TEC may receive DUIDs from users (e.g., one DUID from each user). The TEC may then register the DUIDs to a TES. Alternatively, a TEC may register different DUIDs to different TESs (e.g., one TES may have a limit on the number of registered DUIDs). The TES may check the ownership of DUIDs and / or verify the DUIDs, which may be based on leveraging a distributed ledger system. The TES may maintain a mapping among a registered DUID and corresponding WTRU identifier (e.g., SUCI, GUTI, identifier, etc.) and TEC-ID, the TES may also send the mapping to 3GPP NFs (e.g., UDM), which may store the mapping.

[0121] A credential management function (CMF) registration is where a CMF may be registered with one or multiple TESs, which may have been provisioned to the CMF (e.g., CMF receives information regarding TES such that the CMF may be registered at the TES). During registration, the CMF may send a CMF registration request to a TES, which may indicate its credential management capability (e.g., the type of DVUCs that the CMF can issue, the list of networks such as PLMN-IDs that the CMF can support for issuing DVUCs for their users, or the like as disclosed herein) and its identifier (CMF-ID). Then, the TES may receive the CMF registration request and processes it. The TES may maintain a list of registered CMFs, which can be selected and assigned to a TEC during TEC registration.

[0122] A user credential management is where a TEC may obtain a CMF from the TES as a result of TEC registration. The TEC may be provisioned with a CMF after TEC registration. Alternatively, the TEC may receive a CMF from other network functions; for example, a CMF may be configured to the TEC using a WTRU configuration update procedure (e.g., WTRU receives an update command and WTRU responds accordingly,WTRU receives new / updated policies and responds accordingly, etc.). Then, the TEC may request to create / obtain DVUC for one or multiple users from the CMF. Alternatively, the CMF may actively generate DVUC for users and push it to them via the TEC.

[0123] Exposure to other NFs and / or AFs is where a TES exposes its functions to other NFs and / or AFs. As discussed herein a NF and an AF may be interchangeable, and reference to one may indicate reference to itself, the other, or both. In other words, other NFs may request to access functionality and information provided by TES; for example, a NF may discover DUIDs being registered to the TES; for example, a NF may discover users and their DUIDs being registered to the TES. NFs may configure and write information to a TES; for example, a NF may request the TES to trigger a WTRU to register its DUID to the TES. A NF may configure the TES with a maximum number of users / DUIDs that may be registered via a WTRU. A NF may also request CMF to generate a DVUC for a WTRU and / or its users.

[0124] Leverage other NFs is where a TES may leverage and interact with other NFs. The TES may interact with SEAF to check if a WTRU has successfully passed through primary authentication. The TES may store registered DUIDs of a WTRU and / or its users and other relevant information (e.g., WTRU-ID, TEC-ID) and user location to a NF (e.g., UDM). The TES may retrieve WTRU / user subscription data from a NF (e.g., UDM). The TES may retrieve policies related to user identifier and user credential management from a NF (e.g., PCF).

[0125] TEC registration is where a TEC (e.g., at a WTRU) registers with a TES. As a result, the TES (e.g., the registered-to TES) may maintain a list of registered TECs. The TES may need to verify if the WTRU hosting the TEC has been passed through the primary authentication; for this purpose, the TES may check with another NF(s) (e.g., SEAF, or the like as described herein). The TES may provision the TEC with one or more TEC configurations, such as: the type of DUID that the TEC can support; the type of DVUC / SAUC that the TEC can support; the conditions (e.g., specific locations and times of the TEC) for activating the TEC; the target entities (e.g., another WTRU, another NF) that TEC may be triggered to establish trust relationships with; and / or, the address or the identifier of CMFs where the TEC may request and obtain DVUCs.

[0126] FIG. 5 illustrates an example of a trust enabler framework with respect to a 3GPP system. As shown, there may be the a WTRU side 591 and a Network 592 side (e.g., 3GPP network system).

[0127] A trust enabler framework may be implemented as one or more new 3GPP NF(s). In an example, a TES may be implemented as a control plane function, which may interact with other 3GPP NFs via SBI (e.g., as illustrated, the AMF may communicate with a TES at the AMF, which in turn may communicate via SBI to other parts of the network, such as other network functions). A CMF may be implemented as a control plane function, which may interact with other 3GPP NFs via SBI. CMF may (also) be implemented as an AF or a non- 3GPP function outside of 3GPP domain, which may interact with TES and TEC via NEF. TEC may be implemented as a function embedded at a WTRU. Interactions between TEC and TES may take place in the control plane via NAS signaling and be relayed by AMF. Interactions between TEC and CMF may take place in the control plane via NAS signaling and be relayed by AMF, when CMF is implemented as a 3GPP NF. Interactions between TEC and TES may be through the data plane; for this case, a PDU session needs to beestablished between TEC and TES for transmitting messages between TEC and TES. Interactions between TEC and CMF may be through the data plane; for this case, a PDU session needs to be established between TEC and CMF for transmitting messages between TEC and CMF, when CMF is implemented as a 3GPP NF. Interactions between TEC and TES may be through SBI directly; for this case, TEC and TES may access each other’s services (e.g., provided functions) through SBI. Interactions between TEC and CMF may be through SBI directly when CMF is a 3GPP NF; for this case, TEC and CMF may access each other’s services (e.g., provided functions) through SBI. TES may (also) be integrated into an existing 3GPP NF (e.g., SEAF, AMF). CMF may (also) be integrated into an existing 3GPP NF (e.g., AUSF).

[0128] In some cases, a trust enabler framework may be implemented as a service layer function. Although one or more examples disclosed herein (e.g., FIG. 6, 7, 8, etc.) may address a 3GPP Service Enabler Architecture Layer (SEAL), these approaches may also be realized as a dedicated service enabler framework, which may interact with SEAL.

[0129] In one case, a trust enabler framework may be integrated with a 3GPP service enabler architecture layer (SEAL) on-network functional model. TEC may be implemented as a part of SEAL clients to serve one or multiple Vertical Application Layer (VAL) clients.

[0130] FIG. 6 illustrates an example of an on-network trust enabler framework. As shown, there may be the WTRU 691 , the (e.g., 3GPP) network system 692, and the server(s) 693 (e.g., VAL server(s) and / or SEAL server(s). A trust enabler framework may be integrated with a 3GPP service enabler architecture layer (SEAL) on-network functional model. TEC may be implemented as a part of SEAL clients to serve one or multiple Vertical Application Layer (VAL) clients. TES / CMF may be implemented as a part of SEAL servers, which may be accessed by one or multiple VAL servers. A VAL client may be implemented for a user, which may use services provided by a VAL server. The VAL client may have a DUID and a DVUC. The VAL client may register its DUID to TES by invoking TEC. TES / CMF may interact with NFs in 3GPP Network System via network interface (e.g., NEF).

[0131] FIG. 7 illustrates an example of an off-network trust enabler framework with a server (WTRU702) providing services to a client (WTRU701). In one case, a trust enabler framework may be integrated with a 3GPP SEAL off-network functional model. In this case, a WTRU2 has SEAL server(s) and VAL server(s). WTRU702 may provide services to WTRU701. In other words, VAL clients at WTRU701 may request to access information and services provided by WTRU702. TEC may be implemented as a part of SEAL clients at WTRU701 to serve one or multiple VAL clients. TES may be implemented as a part of SEAL server at WTRU702, which may be accessed by one or multiple VAL clients. CMF may be provided by a third party. WTRU701 and WTRU702 may have already obtained DVUCs from CMF. A VAL client user, may use services provided by a VAL server. The VAL client at WTRU701 may have a DUID and a DVUC. The VAL client at WTRU701 may register its DUID to TES at WTRU701 by invoking TEC.

[0132] FIG. 8 illustrates an example of an off-network trust enabler framework with respect to a client (WTRU801) client (WTRU802) relationship. In one case, both WTRU801 and WTRU802 have SEAL clientsand VAL clients. TEC811 may be implemented as a part of SEAL clients at WTRU801 to serve one or multiple VAL clients. Similarly, WTRU802 may have TEC812 as a part of its SEAL clients, which may be accessed by one or multiple VAL clients. TEC811 and TEC812 may exchange some information such as: TES-ID, which is the identifier of TESs that TEC811 and TEC812 have been registered with, respectively; DUID, which is the DU I D that TEC811 and TEC812 have register to their TES; and / or when a user moves from WTRU801 / TEC811 to WTRU802 / TEC812, the user information stored at TEC811 (e.g., its credentials) may be transferred from TEC811 to TEC812 under the request of the user.

[0133] In some cases, there may be user identifier and user credential management. A WTRU may have one or multiple users, while a user may have one or multiple user credentials. To enable user-centric trust, user identifiers and user credentials need to be properly managed via the interactions between TEC and TES.

[0134] TEC Registration may involve a scenario where a TES may need to actively push some information to a TEC (e.g., TEC provisioning) and thus the TES also needs to identify TECs. A TEC may register itself to a TES, which may maintain a list of all registered TECs. With TEC Registration, the TES may easily identify the TEC that is hosted at or may be reached by a particular WTRU. When the TEC registers with the TES, it may be assumed that the TEC has been provisioned with a TES or the TEC has discovered a TES from a network function or other network entities such as (but not limited to) a NRF, a configuration server, a device management function, or the like (e.g., as described herein). For example, a NF or a configuration server may configure the TEC with a TES, which the TEC can be registered with. Alternatively, TESs may expose their northbound interface (e.g., higher layer interface) to Common API Interface (CAPIF); then, the TEC may use CAPIF to discover TESs.

[0135] DUID Registration may involve a scenario where a TEC may need to register DUIDs associated with the WTRU and its users to a TES. DUID registration may enable other NFs or AFs to discover DUIDs from the TES. DUID registration may be initiated by a user / WTRU / TEC or by the network (e.g., via a TES). Network- initiated DUID registration may be referred to as the scenario where the network (e.g., a TES) may generate and assign one or multiple DUIDs for a user / WTRU; for this purpose, the TES may need to first identify the corresponding TEC. The above TEC registration may allow the TES to find the TEC that can reach particular users / WTRUs.

[0136] DVUC generation may involve a scenario where, before user-centric trust can be established using DVUC, one or multiple DVUCs may first need to be generated for and assigned to a user / WTRU, which may be initiated by a user / WTRU / TEC or by network. A CMF may provide DVUC generation function. If the user / WTRU / TEC has been configured with the address or identifier of a CMF during TEC registration, the user / WTRU / REC may initiate DVUC generation with the configured CMF.

[0137] FIG. 9 illustrates an example of TEC registration. As shown, there is a TEC (e.g., at a WTRU) 991 , a TES 992, a NFx 993, and a NFy 994.

[0138] In one case, a TEC may register with a TES. As an example, the TEC may be hosted by a WTRU, while the TES may be an NF in edge or core network. NFx may be a 3GPP NF (e.g., SEAF, or the like) andNFy may be another 3GPP NF (e.g., UDR / UDM, or the like). Using this procedure, the TEC may indicate to the TES of its existence and that the WTRU supports user-centric trust. With this procedure, the TES may know TECs at different WTRUs and the TES later may actively generate and push DVUC to selected TECs. Using this procedure, the TES may also provision some TEC configurations to the TEC, so that the TEC may prepare appropriate DUIDs and DVUCs.

[0139] Generally, TEC registration may involve a TEC (e.g., at a WTRU), a TES, and NFx and / or NFy. Initially, there may be a trigger for TEC registration. The TEC may determine the TES. The TEC may then send a registration request. The registration request may include a TEC ID, WTRU ID, and / or TEC capability information. The registration request may be sent to the TES. The TES may send a WTRU verification request (e.g., WTRU ID and TES ID) to NFx, which in turn sends a related response (e.g., verifying or not verifying, etc.). The TES may authenticate and authorize the TEC. The TES may create a TEC registration record. The TES may store the registration record at NFy, which in turn sends a related response (e.g., ID of the record as stored). The TES may send a registration response (e.g., in response to the TEC registration request). The registration response may include the TES ID, TES capability, and / or TEC configuration. The TEC may store the registration response. The TEC may start to interact with the TES (e.g., based on what it received).

[0140] A TEC registration may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0141] In a more specific example (e.g., where numbers indicate an example order), at 901 a TEC registration may be triggered by one or multiple of these entities / events / conditions such as a user of the WTRU, an application on the WTRU, some timers installed on the WTRU, some local rules installed on the WTRU (e.g., when the WTRU moves in or out of a proximity), an interaction event with network (e.g., after a successful primary registration), etc. In one instance, events shown / performed at 901 may take place right after 902 but before 903. Alternatively, an AF (or a NF) may decide to initiate trust an enabler function at a WTRU; the AF may send a TEC registration notification to the TES; the TEC registration notification may contain the identifier of the AF, the identifier of the WTRU, etc. (e.g., as described herein); the TES receives the TEC registration notification and may extract the identifier of the AF and the identifier of the WTRU; the TES may authenticate the AF (e.g., based on some policies or the WTRU’s subscription data); the TES may forward the TEC registration notification to the WTRU; the WTRU may trigger its TEC to perform TEC registration (e.g., to execute 903 and other actions / events). Alternatively, when a user of the WTRU unlocks the WTRU and starts to use it, the TEC on the WTRU may not have been registered to a TES yet; in order for the user to register its DUID, the TEC may first need to register itself to the TES; as such, the user / WTRU triggers its TEC to perform TEC registration (e.g., to execute 902 and other actions / events).

[0142] At 902, the TEC may need to find a TES. There may be multiple approaches for finding the TES: The TEC may have been provisioned with the TES by network (e.g., during primary authentication); The TEC may have discovered the TES from a network function such as NRF, a configuration server, CAPIF, or a device management function; a NF or a configuration server could configure the TEC with a TES; and / or, the TEC may receive the TES from another TEC / WTRU. In one instance, the events shown / performed at 902 may take place before 901.

[0143] At 903, the TEC may send a TEC registration request to the TES. This request may include one or more of the following parameters: WTRU-ID, which is the 3GPP identifier of the WTRU that hosts the TEC, which may be a SUCI, a GUTI, etc.; TEC-ID, which is the identifier of the TEC, which could be generated by TEC itself or assigned by the WTRU, and / or the TEC-ID could be based on WTRU-ID; and / or, TEC-Capability, which is the capability of the TEC. The TEC capability may indicate one or more of the following: whether the TEC needs the TES to generate DUID and DVUC for it; whether the TEC needs a CMF; notification-addr, which is the address or communication endpoint for receiving information or notifications that the TES may need to push or asynchronously send to the TEC (e.g., network-generated DUID); and / or, DVUC-Auth-Capa, which may indicate if the TEC has the capacity to authenticate DVUC (e.g., DVUCs of other TECs and / or TESs).

[0144] At 904, the TES receives the TEC registration request from 903. It may first need to verify WTRU- ID and verify if the WTRU has been successfully authorized as a result of a primary authentication. For this purpose, the TEC may send a WTRU verification request to NFx (e.g., SEAF), which may maintain the primary authentication result for the WTRU. The WTRU verification request may include one or more of the following parameters: WTRU-ID, which is the 3GPP identifier of the WTRU that hosts the TEC, and / or TES-ID, which is the identifier of the TES that may be a DUID.

[0145] At 905, the NFx receives the WTRU verification request from 904. NFx may first check if the TES has the right to access the status of the WTRU as denoted by WTRU-ID, for example, based on some policies pre-configured at NFx and / or extra policies to be retrieved from PCF. If the TES is allowed to access WTRU status, NFx may continue to check if the WTRU has been authorized through primary authentication. If the WTRU indeed has been authorized, NFx may check its current identifiers. Then, NFx may send a response to the TES; this response may include a different format of WTRU identifier. For example, if WTRU-ID received at 904 is a SUCI (or a GUTI), NFx may send the WTRU’s GUTI (or a SUCI) to the TES at 905.

[0146] At 906, after WTRU verification, the TES may continue to authenticate and authorize if the TEC can be registered with the TES. For example, if there are some other TECs with different TEC-IDs from the same WTRU that have already been registered with the TES, the registration request from 903 may be rejected if only one or certain number of TECs from the same WTRU are allowed for registration; this feature may help prevent one WTRU from registering too many TECs and potentially prevent Denial of Service (DoS) attacks. In another example, if the WTRU has subscribed services which does not need the WTRU to support usercentric trust, the registration request from 903 may also be rejected; for this scenario, the TES may retrieve the WTRU’s subscription data from UDM. If the WTRU’s subscription data indicates that the WTRU must supportuser-centric trust, the TES may approve the registration request from 903. Also, the TES may have been configured with one or more TEC registration policies, based on which the TES may decide to approve or reject the registration request from 903. At 906, the TES may generate a new identifier for the authorized TEC (New- TEC-ID), which may be based on WTRU-ID and the identifier of the TES. If the TES cannot perform WTRU verification and / or if an authorization rejection was generated at 906, the TES may simply send a rejection with a New-TES-ID to the TEC so that the TEC may register itself to the new TES as denoted by New-TES-ID; other steps may be skipped. If the registration with the present TES (TES-ID), the TEC may re-perform TEC registration (e.g., as illustrated with the new TES as denoted by New-TES-ID). For example, if the current TES as denoted TES-ID may be at a high risk of being attacked or being congested, it may reject this TEC registration and redirect the TEC to a new and more secure TES (New-TES-ID).

[0147] At 907, if the TES approved the registration request at 906, the TES may create a TEC Registration Record (TECRR), which may contain one or more of the following information: WTRU-ID, as received at 903 and / or received at 905; TEC-ID, as received at 903; New-TEC-ID: as generated at 906; TEC-Capability: as received at 903; TES-ID, which is the identifier of the TES that may be a DUID; Reg-Time, which is the TEC registration time that may be set to the time when the TECRR is created; and / or, Expiration-Time, which is the time when this approved TEC registration becomes expired.

[0148] At 908, the TES may send the TECRR to NFy (e.g., UDR) that may store the TECRR.

[0149] At 909, NFy may send a response to the TES. This response may contain a TECRR-ID, which can uniquely identify the TECRR stored at NFy.

[0150] At 910, the TES may send a TEC registration response to the TEC. The registration response may include one or more of the following information: TES-ID, TES-Capability, New-TEC-ID, and / or a TEC-Config. The TES-ID is the identifier of the TES. The TES-Capability is the capability of the TES, which may include one or more of the following: Supported-UCT-Function, which is a list of supported UCT functions at the TES (e.g., network-initiated DUID registration, network-initiated DVUC generation, etc.); Supported-DUID-Types, which is a list of DUID types that TES can support; and / or, Supported-DVUC-Types, which is a list of DVUC types that TES can support. The New-TEC-ID may have been generated at 6. The TEC-Config may include provisioning or confirmation information for the TEC, which may include one or more of the following: TES-ID- for-DUID-Reg, TES-ID-for-DVUC-Gen, CMF-ID-for-DVUC-Gen, CMF-ID-for-DVUC-Gen, Supported-Apps, and / or Max-Num-of-DUID. TES-ID-for-DUID-Reg is the identifier of an assigned new TES from which the TEC may register DUIDs. The TES-ID-for-DUID-Reg may be the same or different from the present TES as denoted by TES-ID. If it is a new TES, it means that the present TES may only handle TEC registration; when the TEC performs DUID registration with the new TES, the new TES may contact DLS or the present TES to check if the TEC has been successfully registered with the present TES. TES-ID-for-DVUC-Gen is the identifier of an assigned new TES from which the TEC may request or obtain DVUC. The TES-ID-for-DVUC-Gen may be the same or different from the present TES as denoted by TES-ID. If it is a new TES, it means that the present TES may only handle TEC registration; when the TEC requests DVUC generation from the new TES, the newTES may contact the present TES to check if the TEC has been successfully registered with the present TES. CMF-ID-for-DVUC-Gen is the identifier of an assigned CMF from which the TEC can request or obtain DVUC. Supported-DUID is where the TES may assign one or multiple DUIDs to the users served by the TEC; then, the TEC may only support or use these assigned DUIDs on behalf of the served users. Supported-Apps is a list of applications that the TEC can support. Max-Num-of-DUID is the maximum number of DUIDs that the TEC can support, where the Max-Num-of-DUID may be a part of WTRU subscription data, which the TES may have retrieved from a NF (e.g., UDM).

[0151] At 911 , the TEC may store the received registration response from 910.

[0152] At 912, the TEC may start to interact with the TES and / or other TES / CMF according to TEC-Config and TES-Capability, for instance, to perform DUID registration or obtain DVUCs from designated CMF / TES (e.g., as described in TEC-Config).

[0153] An NF (e.g., UDM) may send a TES configuration request to a TES to configure and / or update some parameters at the TES. The TES configuration request may contain the information contained in TEC-Config (e.g., Max-Num-of-DUID), the information contained in TES-Capability, etc. After the TES receives the TES confirmation request, the TES may store the contained information and use it for its future interactions with TECs and / or other NFs / AFs. Then, the TES may send a TES configuration response to the NF indicating the list of parameters being successfully configured. Alternatively, the TES may send a TES configuration retrieval request to an NF (e.g., UDM); the NF may send a TES configuration retrieval response to the TES. The TES configuration retrieval response may contain the same information as contained in a TES configuration request.

[0154] In one case, a DUID may be the hash value of a hash function with the private key and some additional information as inputs. The owner of the private key may be the owner of the corresponding DUID. A DUID may or may not contain a signature of the owner. The signature may be used to verify and authenticate the ownership of a DUID. A DUID may contain a “type” field indicating the target system type / name / identifier where this DUID may be used / verified / authenticated. A DUID has some associated information that may be or should be shared with other users / entities, referred to as DUID Public Information (DUID-Public-Info). DUID- Public-lnfo may include one or more of the following: DUID, which is the DUID itself; DUID-Type, which is the type of DUID that may indicate the target system type / name / identifier where this DUID may be used / verified / authenticated; Public-Key, which is a public key corresponding to the private key that was used to generate DUID; DUID-Sign-Scheme, which is the algorithm or the scheme used to generate DUID-Sign; and / or, DUID-Sign, which is the signature of the DUID that was generated based on the private key and DUID- Sign-Scheme.

[0155] FIG. 10 illustrates an example of a WTRU initiated DUID registration. As shown, there is a TEC (e.g., at a WTRU) 1091 , a TES 1092, a NFx 1093, and a NFy 1094.

[0156] In one case, there may be a WTRU-initiated DUID registration procedure, which allows a TEC to register DUIDs to a TES. As an example, the TEC may use this procedure to register one DUID for a user of the WTRU or for the WTRU. In another example, the TEC may use this procedure to register multiple DUIDs(e.g., one for a different user of the WTRU). WTRU-initiated DUID registration usually takes place after TEC registration. As an example, the TEC may be hosted in a WTRU, while the TES may be an NF in edge or core network. NFx may be a 3GPP NF such as SEAF and NFy may be DLS or another 3GPP NF such as UDR / UDM. Using this procedure, the TEC may indicate to the TES one or multiple DUIDs, which identify the WTRU or the users of the WTRU. By indicating DUIDs to the TES, the mapping among WTRU-ID, TEC-ID and WTRU-DUIDs (e.g., in the form of a set or tuple {WTRU-ID, TEC-ID, WTRU-DUIDs}) may be established by the TES and may be stored at the TES and / or other NFs in network to be consumed / retrieved by other NFs / AFs. For example, an AF that requires user-centric trust can look up WTRU-DUIDs supported at a WTRU by giving the WTRU- ID; then, the AF may interact with the entity represented by a discovered WTRU-DUID.

[0157] Generally, for a WTRU initiated DUID registration, there may be a TEC (e.g., at a WTRU), a TES, an NFx, and / or a NFy. Initially, there may be a trigger for DUID registration (e.g., as described herein). The TEC may send a DUID registration request to the TES. The registration request may include a WTRU-DUID, a WTRU-ID, and / or a TEC-ID. The TES may send a WTRU verification request to the NFx, and receive a response in turn (e.g., verifying the WTRU based on one or more pieces of information, such as described herein). The TES may verify the WTRU-DUID. The TES may add a WTRU-DUID to a registered DUID list. The TES may store the WTRU-DUID record at NFy, and receive a response in turn (e.g., confirming storage, and perhaps an identifier for the store record). The TES may send a DUID registration response (e.g., in response to the registration request), which may include a DUID config. The TEC, upon receiving the response, may store the registration response and may continue to interact with the TES.

[0158] A DUID registration may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0159] In a more specific example (e.g., where numbers indicate an example order), at 1001 DUID registration may be triggered by one or multiple of those entities / events / conditions such as a successful TEC registration, a successful generation of DUID by the TEC, a DUID being provided to a user of the WTRU, an application on the WTRU, some timers installed on the WTRU (a DUID may need to be periodically registered since TES may actively recall or de-register DUIDs), an interaction event with network (e.g., after a successful primary registration), etc. For example, when a user unlocks the WTRU and starts to use the WTRU, the WTRU may pop up or present a message requesting the user to enter their DUID; then, the user enters their DUID (e.g., or necessary information such as a password that can be used by the WTRU to generate their DUID); the WTRU may generate the signature of DUID (WTRU-DUID-Sign) using the information provided by the user; the entered DUID may be passed to the TEC; as a result, the TEC may trigger DUID registration. If the WTRUis currently used by multiple users, each user may enter her DUID (e.g., the procedure in FIG. 10 may be used to register one single DUID for one user or multiple DUIDs for all users).

[0160] At 1002, the TEC may send a DUID registration request to the TES, which may be the same TES that the TEC has registered itself to or another TES that was designated by the registered-to TES. This request may include one or more of the following parameters: DUID-Type, which is the type of WTRU-DUID; WTRU- DUID, which is one or multiple DUIDs to be registered to the TES; where the WTRU-DUID could be for the users of the WTRU or for the WTRU itself; WTRU-DUID-Sign, which is the signature of WTRU-DUID, where each WTRU-DUID may have its signature WTRU-DUID-Sign, and / or where it may be assumed that WTRU- DUID has been generated based on a private key, and / or the owner of the private key (e.g., the WTRU or its user) may use the private key to generate a signature of WTRU-DUID; WTRU-ID, which is the 3GPP identifier of the WTRU that hosts the TEC, which may be a SUCI, a GUTI, etc.; and / or, TEC-ID, which is the identifier of the TEC, which may be generated by TEC itself, assigned by the WTRU, or generated by the registered-to TES. TEC-ID may be based on WTRU-ID.

[0161] At 1003, this may be similar or the same as 904 of FIG. 9, except instead of for TEC registration, this is WTRU-lnitiated DUID registration.

[0162] At 1004, this may be similar or the same as 905 of FIG. 9, except instead of for TEC registration, this is WTRU-lnitiated DUID registration.

[0163] In one instance, 1003 and 1004 may be skipped if both steps have been performed during TEC registration.

[0164] At 1005, the TES may verify WTRU-DUID received at 1002. The TES may first verify if the DUID- Type meets the TES’s Supported-DUID-Types; otherwise, WTRU-DUID may be regarded as an invalid one.

[0165] The TES may verify WTRU-DUID-Sign using the WTRU’s or user’s public key. The TES may retrieve the WTRU’s or user’s public key from other NFs such as UDM, or may retrieve such information from DU I D- Public-lnfo. If the WTRU-DUID-Sign is invalid, the DUID registration request from 1002 may be rejected, and the TES may skip other steps but simply send a quick response containing “Invalid DUID Signature” to the TEC at 1009.

[0166] The TES may maintain the status of all previously registered WTRU-DUIDs, which may be one or more of the following: Registered, which is where the WTRU-DUID has been registered and may still be used; Recalled, where the WTRU-DUID has been registered previously but it was recalled and cannot be used anymore); and / or Unregistered, where the WTRU-DUID has never been registered.

[0167] The status of all previously registered WTRU-DUID may (also) have been maintained in the DLS for any entity and NFs, including the TES, to retrieve. Then, the TES may check the status of WTRU-DUID from 1002.

[0168] If the status is Registered, the TES may skip 1006-1008 and proceed to 1009, replying to the TEC with a response informing that “WTRU-DUID has been registered and still valid”. Alternatively, 1006-1008 maynot be skipped, and the TES may simply extend the registration expiration time for WTRU-DUID. As another option, the TES may discard the previous registration and proceed from there as a new registration for WTRU- DUID.

[0169] If the status is Recalled, the TES may skip 1006-1008 and proceed to 1009, replying to the TEC with a response informing that ‘WTRU-DUID has been recalled”.

[0170] If the status is Unregistered, the TES may continue to verify WTRU-DUID and process the registration request from 1002.

[0171] The TES may also check if the number of registered DUID from the same TEC exceeds Max-Num- of-DUID. If YES, the TES may reject the registration request from 1002.

[0172] A user may subscribe to use multiple WTRUs, referred to as Shared WTRUs, to access services from a service provider. In other words, a user may register a WTRU-DUID from one WTRU with a TES and it may be considered registered from other WTRUs with the same TES. A list of those multiple WTRUs may be included in the user’s subscription data and stored in a NF (e.g., UDM). The user may not need to repeat DUID registration via each WTRU to the same TES. As such, the TES may also determine and select other shared TECs / WTRUs, referred to as (Shared-TEC-I D-List and / or Shared-WTRU-ID-List), through which the user may use the same WTRU-DUID to access services provided by network and / or other WTRUs.

[0173] If multiple WTRU-DUIDs were included at 1002, the above description for 1005 may be repeated for each WTRU-DUID.

[0174] At 1006, the TES may maintain a list of registered WTRU-DUID list (Reg-DUID-List). If the registration request was not rejected or already registered from 1005, the TES may add a new DUID record to Reg-DUID-List. The new DUID record may include one or more of the following: WTRU-DUID, which is the list of WTRU-DUIDs received from 1002 and being registered; TEC-ID, which is the TEC-ID as received at 1002 and / or Shared-TEC-ID-List / Shared-WTRU-ID-List (a list of TEC-IDs / WTRU-IDs) as determined at 1005. TES- ID, where the identifier of the TES may be a DUID; DUID-Status, which is the status of WTRU-DUID from 1002 (e.g., “registered”); Reg-Time, which is the DUID registration time that may be set to the time when this new DUID record is created; Expiration-Time, which is the time when this registered DUID becomes expired.

[0175] If WTRU-DUID has been previously registered and is still valid / unexpired, the TES may extend the previous registration expiration time.

[0176] If WTRU-DUID has been previously registered and is still valid / unexpired, the TES may use the new DUID record created at 1006 to overwrite the previous DUID record being created during previous DUID registration.

[0177] At 1007, the TES may send the new DUID record to NFy (e.g., UDR, DLS), which will store the new DUID record.

[0178] At 1008, NFy may send a response to the TES. This response may contain a DUID record identifier, which may uniquely identify the new DUID record stored at NFy.

[0179] At 1009, the TES may send a DUID registration response to the TEC, which may include one or more of the following information: TES-ID, which is the identifier of the TES which may be a DUID; and / or DUID-Config, which is the configuration information about how the registered DUID can be used in future. DU I D-Config parameter may include one or more of the following: Shared-TEC-I D-List (e.g., as determined at 1005); New-TES-ID, which is the identifier of other TESs which the WTRU-DUID can be registered to (e.g., this parameter may still be contained even if the registration request at 1002 was rejected at 1005); DVUC-Type, which is the type of DVUCs that the registered WTRU-DUID may use and / or be associated with.

[0180] At 1010, the TEC may store the received registration response from 1009.

[0181] At 1011, the TEC may continue to interact with the TES according to DUID-Config, for instance, to perform DUID registration with other TES as indicated in New-TES-ID.

[0182] FIG. 11 illustrates an example of a selection of shared WTRUs / TECs. The selection of shared WTRUs / TECs at 1005 of FIG. 10 may be expanded to a general function at a TES. As shown, there may be a selected WTRU / TEC 1191 , a user 1192, a TES 1193, an AF 1194, and a NF 1195. Note, while the user, WTRU, and TEC as shown as separate, these may be considered the same entity in at least one case based on this example.

[0183] Generally, for the selection of shared WTRUs / TECs, there may be a selected WTRU / TEC, a user, a TES, an AF, and / or an NF. Initially, there may be trigger for selecting WTRUs / TECs shared by a user / WTRU (e.g., as described herein). The TES may send a subscription data request to the NF (e.g., which may include WTRU-DUID, WTRU-ID, and / or the like as described herein). The NF may send a subscription data response. The TES may determine TEC(s) / WTRU(s) from the user. The TES may send a notification to the user. The TES may send a notification to each selected WTRU / TEC.

[0184] A WTRU / TEC selection procedure may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0185] In a more specific example (e.g., where numbers indicate an example order), at 1101 a TES may be triggered to select WTRUs / TECs which the same user (e.g., as denoted by WTRU-DUID) may use to access services from a service provider. For example, when the user registers its WTRU-DUID with the TES, the user may actively request the TES to select a list of WTRUs / TECs (e.g., Shared-WTRU-ID-List and / or Shared-TEC- I D-List). An AF or NF (e.g., SEAF / AUSF / AMF) may also trigger the TES to perform such WTRU / TEC selection, if the AF / NF knows the identifier of the user (e.g., WTRU-DUID).

[0186] At 1102, the TES may send a subscription data request to an NF (e.g., UDM) to retrieve the subscription data of the user (WTRU-DUID) and / or the subscription data about a WTRU (WTRU-ID) that the user currently uses. This request may contain WTRU-DUID and / or WTRU-ID.

[0187] At 1103, the NF may process the request from 1102, finds the requested subscription data, and sends it to the TES in a response. The subscription data may contain a list of WTRUs / TECs (e.g., Shared- WTRU-ID-List and / or Shared-TEC-ID-List), which the user has subscribed to and is allowed to use.

[0188] At 1104, the TES may determine or select the shared WTRUs / TECs for the user according to the subscription data received from 1103. It may remove some TECs / WTRUs from the list of WTRUs / TECs received from 1103.

[0189] At 1105, the TES may send a notification to the user, which may contain the list of determined or selected WTRUs / TECs from 1104.

[0190] At 1106, the TES may send a notification for each WTRU / TEC as selected at 1104. The notification may contain the identifier of the user (e.g., WTRU-DUID) and other WTRUs / TECs as determined at 1104.

[0191] FIG. 12 illustrates an example of a network-initiated DUID registration. As shown, there may be TEC (e.g., at a WTRU) 1291 , a TES 1292, a DR1 1293, and a NFy 1294.

[0192] In one case, there may be network-initiated DUID registration where a DUID Registration Initiator (DRI) (e.g., AF or NF such as SEAF, NFx, etc.) may determine to trigger user-centric trust for a target WTRU (e.g., when a target WTRU moves to a different location). As a result, the TES may instruct the TEC of the target WTRU to register its DUID to the network. As example, the TEC may be hosted in a WTRU and has been registered to the TES, while the TES may be an NF in edge or core network. DRI may be a 3GPP NF / AF such as SEAF and NFy may be DLS or another 3GPP NF such as UDR / UDM.

[0193] Generally, for a network-initiated DUID registration, there may be a TEC (e.g., at a WTRU), a TES, a DRI, and / or a NFy. Initially, there may be trigger for user-centric trust for a target WTRU (e.g., at DRI). The DRI may send a DUID registration notification to the TES, which may include a WTRU ID. The TES may determine the TEC. The TES may send a DUID registration notification to the TEC, which may include TES ID and / or TEC ID. The TEC may send back a DUID registration request, which may include WTRU-DUID and / or TEC-ID. The TES may then verify the WTRU-DUID. The TES may add the WTRU-DUID to a registered WTRU- DUID list. The TES may send the WTRU-DUID record to be stored to NFy, which in turn may confirm the storage of the record (e.g., and an ID of the record). The TES may send a DUID registration response to the TEC (e.g., responding to the registration request), which may include a DUID configuration information. The TEC may store the registration response. The TEC may continue to interact with the TES.

[0194] A WTRU / TEC selection procedure may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be takeninto consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0195] In a more specific example (e.g., where numbers indicate an example order), at 1201, a DRI may determine to trigger User-Centric T rust (UCT) function / feature for a target WTRU, which has registered its TEC but has not registered any DUID yet. There may be multiple scenarios for such a case, which may be considered individually or in combination with each other (e.g., in whole or in part).

[0196] For example, one scenario may be where a DRI is an SEAF and the primary authentication with the target WTRU did not pass through. The DRI may decide to trigger and use UCT for the target WTRU, which first needs to register its DUID.

[0197] For example, one scenario may be where a DRI is an SEAF and the primary authentication with the target WTRU has been successful. The WTRU may move to a new location (e.g., an unusual location region that the WTRU did not used to stay). The DRI may receive a location notification from NWDAF and / or LMF. For example, this may be risky in a situation where in this location, there are a lot of malicious security events that have happened, therefore, it is better for the WTRU to use UCT in order to have a higher level of trust. Finally, the DRI may decide to trigger and use UCT for the target WTRU, which first needs to register its DUID.

[0198] For example, one scenario may be where a DRI is the original TES that the target WTRU has registered DUID to. During the DUID registration, the original TES may select one or more new TESs (e.g., the TES of FIG. 12), which the target WTRU needs to register its DUID with.

[0199] For example, one scenario may be where a DRI may leverage the TES to manage users at a WTRU.For example, the DRI may request a user of the WTRU to register their DUID.

[0200] DRI may be an AF that may leverage the TES to manage users at a WTRU. For example, the AF may send a DUID registration notification to the TES to trigger the WTRU to initiate DUID registration; the DUID registration notification may contain the identifier of the AF, the identifier of the WTRU, the identifier of one or multiple users using the WTRU (e.g., DUIDs); the TES may receive the DUID registration notification and may authenticate the AF (e.g., based on one or more policies or the WTRU’s subscription data that may specify if the AF can send the DUID registration notification to the WTRU); the TES may forward the DUID registration notification to the WTRU; the WTRU / user may trigger its TEC to perform DUID registration (e.g., to execute 5 and other actions / events).

[0201] At 1202, the DRI may send a DUID registration notification to the TES. The DRI may find TES from NRF. This notification may include one or more of the following parameters: WTRU-ID, which is the identifier of the target WTRU, and where this parameter may comprise a list of target WTRUs (e.g., their identifier) (e.g., in this case, 1203-1213 may be repeated for each target WTRU); DRI -ID, which is the identifier of the DRI (e.g., an AF / NF identifier); WTRU-DUID, which is the list of DUIDs that the target WTRU has registered with another TES and still valid (e.g., this parameter may be optional).

[0202] At 1203, the TES receives the notification from 1202. The TES may use WTRU-ID to find the target TEC from the TEC registration records. Then, the TES may check if the target TEC is allowed to register more DUIDs. The TES may also leverage the WTRU’s subscription data (e.g., which may be retrieved from UDM) and / or trust-related policies (e.g., which may be retrieved from PCF) to authenticate or approve if DRI (e.g., an AF or an NF) is allowed to trigger DUID registration at the WTRU; if it is not allowed, the TES may send a rejection response to DRI and other steps may be skipped. If it is allowed, the TES may also generate a new DUID for the target WTRU.

[0203] At 1204, the TES may send a DUID registration notification to the TEC. This notification may include one or more of the following parameters: DRI-ID, which is the identifier of the DRI (e.g., an AF identifier, a NF identifier, etc.) as received at 1202; TES-ID, which is the identifier of the TES that the TEC needs to send the DUID registration request (e.g., at 1205) to; TEC-ID, which is the identifier of the TEC; DUID-Config (e.g., similar or the same as DUID-Config as discussed at 1009 of FIG. 10), where this parameter may be needed only when WTRU-DUID is contained at this point; WTRU-DUID, which is the same DUIDs as received at 1202 or generated at 1203 (e.g., this parameter may be optional). In one instance, each WTRU-DUID contained in the WTRU-DUID parameter may have already been registered and may still be valid; as a result, to inform the TEC of these registered WTRU-DUIDs, the TEC may not need to re-registered them again. In another instance, each WTRU-DUID contained in this parameter may still need to be registered to the TES.

[0204] As an alternative approach to 1202-1204, DRI may send the same DUID registration notification (at 1204) to the WTRU directly (e.g., using 3GPP NAS signaling, data plane, or SBI-based messaging); then, the WTRU / user may inform its TEC to execute 1205 and other actions / events.

[0205] At 1205, after receiving the registration notification at 1204, the TEC may authenticate if DRI has the right to trigger DUID registration; if it is not allowed, the TEC may send a rejection response to DRI and / or the TES; as a result, other steps may be skipped. In another example, the TEC may pop up or send the received DUID registration notification to the corresponding user (e.g., as indicated by UE-DUID at 1204) for their approval; the user may approve the registration notification and send an approve message to the TEC. Then, the TEC at the target WTRU may send a DUID registration request to the TES. If the user does approve the registration notification, the TEC may send a rejection response to DRI and / or the TES; as a result, other steps may be skipped. If the notification received at 1204 contained WTRU-DUID, the TEC may store WTRU-DUID; thus, this registration request may serve as a registration confirmation to the TES indicating that the TEC accepts WTRU-DUID being sent from the TES at 1204; for this case, 1206 and 1210 may be skipped. If the notification received at 1204 did not contain any WTRU-DUID, the TEC may generate a new DUID or request the user of the target WTRU to provide a new DUID; then, the TEC may send the DUID registration request to the TES, which may include one or more of the following parameters: WTRU-DUID, which is the DUID generated at 1205 for the target WTRU and / or its users or DUIDs provided by the target WTRU and / or its users; DUID-Type, which is the type of the new DUID generated at 1205 (e.g., this parameter may be optional); TEC- ID, which is the identifier of the TEC; DRI-ID, which is the identifier of the DRI (e.g., an AF identifier, a NFidentifier, etc.) which may be needed if DRI sent the DUID registration notification to the WTRU directly; and / or, WTRU-DUID-Sign, which is the signature of WTRU-DUID. It may be assumed that a WTRU-DUID has been generated based on a private key. The owner of the private key (e.g., the target WTRU and / or its users) may use the private key to generate a signature of WTRU-DUID.

[0206] At 1206, if 1205 contained a new WTRU-DUID, the TES may verify the WTRU-DUID (e.g., similar or the same as at 1005 of FIG. 10 and / or related description herein).

[0207] At 1207, a similar or a same process may apply as at 1006 of FIG. 10 (e.g., and related description herein). The TES may send a DUID registration confirmation to DRI as a response to DUID registration notification at 1202; the DUID registration confirmation may contain a list of registered DUIDs or the new DUID record (e.g., similar to the new DUID record created at 1006 of FIG. 10).

[0208] At 1208, a similar or a same process may apply as at 1007 of FIG. 10 (e.g., and related description herein).

[0209] At 1209, a similar or a same process may apply as at 1008 of FIG. 10 (e.g., and related description herein).

[0210] At 1210, a similar or a same process may apply as at 1009 of FIG. 10 (e.g., and related description herein).

[0211] At 1211, a similar or a same process may apply as at 1010 of FIG. 10 (e.g., and related description herein).

[0212] At 1212, a similar or a same process may apply as at 1011 of FIG. 10 (e.g., and related description herein).

[0213] FIG. 13 illustrates an example of a DUID registration for multiple TECs. As shown, there may be TEC1 1391 (e.g., at a WTRU1), TES 1392, TEC2 1393 (e.g., at a WTRU2), and NFy 1394.

[0214] In one case, there may be DUID registration for multiple TECs / WTRUs. As an example, TEC1 may be hosted at WTRU1 while TEC2 is hosted at WTRU2. A TES may be located in edge or core network, which may reach or be reached by both TEC1 and TEC2. TEC1 may first register one or multiple DUIDs to the TES. Then, the registered DUIDs may be applied to TEC2 (e.g., as requested by TEC1); in other words, TEC2 may need to know and accept the registered DUIDs; also, the TES may record that the registered DUIDs are for both TEC1 and TEC2. In this scenario, the DUIDs registered by TEC1 may be shared with TEC2 so that both TEC1 and TEC2 may use the same set of DUIDs. Such registered DUIDs for multiple TECs / WTRUs may be regarded as common or master DUID (e.g., a parent DUID for a family plan of several phones). Each of such common DUIDs may interact with the same TES via TEC1 / WTRU1 or via TEC2 / WTRU2; in other words, this feature may enable the same user (with the same DUID) to use multiple WTRUs with one-time DUID registration from any of these multiple WTRUs.

[0215] Generally, there may be a plurality of TECs (e.g., each one at a respective WTRU, or more than one at a single WTRU), a TES, and / or an NFy. Initially, there may be a WTRU1 initiated DUID registration (e.g., asdescribed herein) message exchange between a TEC1 (e.g., at WTRU1) and a TES. The TES may determine TEC2, and send DUID registration notification to TEC2, which may include a TES-ID, TEC2-ID, WTRU1-ID, and / or a registered-DUID). The TEC2 may respond with a DUID registration confirmation, which may include a TEC2-ID and / or a confirmed-DUID. The TES may add confirmed DUID to the registered DUID list. The TES may send the confirmed DUID record to be stored at NFy, which in turn may confirm the storage (e.g., with a record ID). The TES may send a DUID registration response to the TEC1 (e.g., in response to the registration request as part of the registration message exchange), which may include WTRU2-ID, TEC2-ID, and / or DUID- config. The TES may send a DUID registration acknowledgement to TEC2, which may include DUID-config. The TEC1 may store the registration response, and continue to interact with the TES. The TEC2 may store the registration response, and continue to interact with the TES.

[0216] A DUID registration for multiple WTRU / TEC procedure may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0217] In a more specific example (e.g., where numbers indicate an example order), at 1301 , TEC1 may follow the operations as described herein (e.g., FIG. 10) to register one or multiple DUIDs with the TES. TEC1 may also indicate to the TES: WTRU2’s identifier, a list of WTRU identifiers, or a group identifier that may map to multiple WTRU identifiers. Note, for registering one or multiple DUIDs as it relates to multiple TEC / WTRUs, one or more modifications to techniques described herein may be made, such as: 1006-1008 of FIG. 10 may be skipped; 1009 of FIG. 10 may be skipped and replaced with 1308 of FIG. 13; 1010 of FIG. 10 may be skipped and replaced with 1309 of FIG. 13; and / or, 1011 of FIG. 10 may be skipped and replaced with 1310 of FIG. 13.

[0218] At 1302, the TES may determine TEC2 / WTRU2 (e.g., and other TECs / WTRUs if 1301 indicated multiple WTRU identifiers). For example, TEC1 may send WTRU2’s 3GPP identifier (WTRU2-ID) to the TES at 1301 ; then, the TES may find TEC2 using WTRU2-ID, assuming TEC2 has been previously registered with the TES. In another example, both WTRU1 and WTRU2 may belong to a group. The TES may retrieve group members (e.g., WTRU2-ID) from WTRUTs subscription data (e.g., using a group identifier); then it may find TEC2 according to WTRU2-ID. Also, at 1302, the TES may verify WTRU2, similar to 1003-1004 of FIG. 10 (e.g., as described herein).

[0219] At 1303, the TES may send a DUID registration notification to TEC2, which may include one or more of the following parameters: TES-ID, which is the identifier of the TES which may be a DUID; TEC2-ID, which is the identifier of TEC2; WTRU1-ID, which is the identifier of WTRU1 ; TEC1 -ID, which is the identifier of TEC- 1; Registered-DUID, which is the WTRU-DUIDs that have been successfully registered at 1; and / or, DUID- Config, where TES may also determine DUID-Config for TEC2, which may be the same for TEC1.

[0220] At 1304, TEC2 may receive the notification from 1303. It may confirm to accept one or multiple registered DUID and store them locally. It may send a DUID registration confirmation to the TES, which may include one or more of the following parameters: TEC2-ID, which is the identifier of TEC2; and / or, Confirmed- DUID, which is a subset of Registered-DUID (received at 1303) that TEC2 accepted and stored locally.

[0221] At 1305, the TES may add confirmed DUID to a list (e.g., which may be the similar or the same to 1006 of FIG. 10). For example, the TES may add a new DUID record to Reg-DUID-List, which may include one or more of: Confirmed-DUID as received at 1304; TES-ID, which is the identifier of the TES; DUID-Status, which is the status of Confirmed-DUID (e.g., “registered”); Reg-Time, which is the Confirmed-DUID registration time that may be set to the time when this new DUID record is created; Expiration-Time, which is the time when this registered Confirmed-DUID becomes expired; and / or, multiple associated TECs / WTRUs (e.g., TEC1-ID, TEC2-ID, WTRU1-ID, and / or WTRU2-ID).

[0222] At 1306, the TES may send the new DUID record as created at 1305 to NFy. The NFy may store the new DUID record. This may be similar to 1007 of FIG. 10 and related description.

[0223] At 1307, there may be a response (e.g., similar to 1008 of FIG. 10 and related description).

[0224] At 1308, the TES may send a DUID registration response (e.g., similar to 1009 of FIG. 10). In addition to DUID-Config, this registration response may also contain WTRU2-ID and / or TEC2-ID.

[0225] At 1309, TEC1 may store the registration response (e.g., similar to 1010 of FIG. 10 and related description).

[0226] At 1310, TEC1 may continue to interact with the TES (e.g., similar to 1011 of FIG. 10 and related description).

[0227] At 1311 , the TES may send a DUID registration acknowledgement to TEC-2, which may contain DUID-Config.

[0228] At 1312, TEC2 may store registration response (similar to 1309 for TEC 1).

[0229] At 1313, TEC2 may continue to interact with TES (similar to 1310 for TEC1).

[0230] In some cases, there may be Distributed Verifiable User Credential (DVUC) generation. A new DVUC may include a list of information, such as one or more of the following: the type of the DVUC. A DVUC may be a Service-Aware User Credential (SAUC); the purpose of the DVUC, where a DVUC may be for a service consumer or for a service provider; the DUID of the DVUC owner; the DUID of the party (e.g., the CMF) that issued the DVUC; the identifier of one or multiple existing DVUCs that this new DVUC will deprecate; the identifier of one or more existing DVUCs that this new DVUC may use together with; claim statements about the DVUC owner that may indicate some attributes / properties / abilities of the owner; the signature of the party that issued the DVUC; and / or, the public key of the party that issued the DVUC.

[0231] FIG. 14 illustrates an example of a process for WTRU initiated DVUC generation. As shown, there may be a TEC 1491 (e.g., at the WTRU), a CMF 1492, a NFy 1493, a NFx 1494, and a DLS 1495.

[0232] In one case, a CMF (even a special TES) may coordinate the generation of DVUC for a target WTRU and / or its users, as requested by a TEC at the target WTRU. In an example, the TEC may be hosted by the target WTRU. The CMF may be located at edge or core network or cloud. NFx may be a NF that may provide the CMF credential (e.g., the private key of the CMF, signature generation scheme for the CMF), while NFy may be a NF (e.g., UDM) that the target WTRU’s subscription data can be retrieved from. DLS is distributed ledger system which may provide immutable storage for DVUC generation records.

[0233] Generally, for such a procedure there may be TEC (e.g., at a WTRU), a CMF, a NFy, NFx, and / or a DLS. Initially, a DVUC generation event may be triggered (e.g., at the TEC). The TEC may send a DVUC generation request to the CMF, which may include WTRU-DUID, DVUC-Type, DVUC-Support-Info, TEC-ID, and / or a WTRU-ID. The CMF may send a message to NFy to retrieve subscriptions data (e.g., such as the WTRU-ID, DVUC flag, etc.). The NFy may respond with subscription date for the WTRU. The CMF may send a message to NFx for retrieving CMF credentials (e.g., CMF-ID), and the NFx may respond in turn (e.g., with CMF credentials). The CMF may authenticate the DVUC generation request. The CMF may generate a DVUC. The CMF may create a DVUC generation record, which may be sent to the DLS. The CMF may send the DVUC generation response to the TEC. The TEC may continue to interact with other entities.

[0234] A DVUC generation procedure may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0235] In a more specific example (e.g., where numbers indicate an example order), at 1401 , the TEC may be triggered to request DVUC generation. The triggers may include one or more of the following: a user or an application on the target WTRU that triggers the TEC to generate DVUC; the TEC has an expired DVUC and a new DVUC is needed; the TEC has an DVUC, but it cannot be verified and a new DVUC is needed; and / or, as a result of DUID registration, the TEC is informed that it needs to have certain types of DVUC.

[0236] At 1402, the TEC may send a DVUC generation request to the CMF. The TEC may be configured with this CMF when it was registered to the TES. This request may include on or more of the following parameters: TEC-ID, which is the identifier of the TEC; WTRU-ID, which is the 3GPP identifier of the target WTRU; WTRU-DUID, which is the identifier of the user / WTRU / application that DVUC is requested to generate for; DVUC-Type, which is the type of DVUC to be generated, where this parameter may indicate the type of services (e.g., either supported by the target WTRU or requested by the target WTRU) that DVUC being generated may be used for trust authentication for (e.g., a DVUC may be a Service-Aware User Credential (SAUC)); DVUC-Support-Info, where this parameter may include one or more pieces of information that may be needed by the CMF to authenticate this request at 1402 and to generate the requested DVUC. For example, for DVUC-Support-Info, this parameter may include one or more of the following: Requested-Services, whichis a list of services that the target WTRU may request from other WTRUs or network entities, where in this case, the purpose of the DVUC being generated is for the target WTRU as a service consumer; Supported- Local-Services, which is a list of local services the target WTRU may provide to other WTRUs or network entities, where in this case, the purpose of the DVUC being generated is for the target WTRU as a service provider; and / or, Credential-for-DVUC-Generation, which is the credential and / or claims (e.g., attributes and properties about the user / WTRU) that the TEC may use to request DVUC generation from the TES. Note, at 1407, the CMF may verify Credential-for-DVUC-Generation, where if it is invalid or cannot be verified, the CMF may reject DVUC generation request. For example, the user is an active member of Organization-X (e.g., a company providing video streaming service) that hosts a CMF, and the user may use the procedure as described herein (e.g., FIG. 14 and / or other related description) to request a membership-type DVUC from the CMF. “Credential-for-DVUC-Generation” in this case may be user’s account info and answers to some challenge questions.

[0237] At 1403, the CMF may send a request to NFy (e.g., UDM) to retrieve the target WTRU’s subscription data, which may include some policies or constraints on DVUC generation for the target WTRU and a list of network functions and services that the target WTRU / user may have subscribed to access. A policy may indicate that the target WTRU may not obtain DVUCs for the purposes of being a service provider. Another policy may specify the expiration time of DVUCs to be generated for the target WTRU. This request may include one or more of the following parameters: WTRU-ID, which is the 3GPP identifier of the target WTRU; and / or, DVUC-Flag, which may indicate that only DVUC-related subscription data is needed

[0238] At 1404 the NFy may send a response to the CMF. This response may include the target WTRU’s DVUC-related subscription data, which may include or describe one or more of the following information: the list of network functions and services that the target WTRU / user has subscribed to access; and / or, the location- related or time-related network access policies that are applicable to the target WTRU / user.

[0239] At 1405, the CMF may send a request to NFx to retrieve the CMF’s credential, which may be used by the CMF to sign DVUC as at 1407. In one instance, 1405 and / or 1406 may be optional if the CMF has known its credential.

[0240] At 1406, the NFx may send a response to the CMF. This response may include the CMF’s credential (CMF-Credential), which may comprise one or more of the following: Sign-Scheme, which is the hash scheme to be used by the CMF to sign DVUC at 1407; and / or Security-Key, which is the security key to be used by the CMF to sign DVUC at 1407. In one instance, the Security-Key may be optional if the CMF has already obtained it from NFx or other places, but Sign-Scheme may be changed at different times and / or for different TECs from different target WTRUs.

[0241] Note, 1405 and / or 1406 may not be needed if the CMF decides to contact a third party to generate DVUC-Doc (e.g., as described herein, at option 2 at 1408).

[0242] At 1407, the CMF may authenticate the DVUC generation request from 1402 using Credential-for- DVUC-Generation and other information received from 1404. For example, the CMF may first verify Credential- for-DVUC-Generation and may reject the DVUC generation request if it is invalid.

[0243] At 1408, the CMF may coordinate to generate DVUC as requested by the TEC. There may be two options. Option 1 is where the CMF may generate a new DVUC (e.g., a document as denoted by WTRU- DVUC-Doc) for each different WTRU-DUID as received at 1401 , which may include one or more of the following parameters: DVUC-ID, which is the identifier of this new DVUC being generated; DVUC-Type, as received at 1402; Deprecated-DVUC-ID, which is the identifier of one or multiple existing DVUCs that this new DVUC being generated will deprecate (e.g., this DVUC may update an existing DVUC and make it become invalid); DVUC- Purpose, which is the purpose of the new DVUC (e.g., a DVUC may be for a service consumer or for a service provider; a DVUC-Purpose may be indicated at 1402); DVUC-Owner, which is the DUID of the owner of the new DVUC (e.g., WTRU-DUID as received at 1402); DVUC-Generator, which is the DUID of the party generating the new DVUC (e.g., CMF-ID, the identifier of the CMF); DVUC-Support-Info, which is as received at 1402 but may excluding Credential-for-DVUC-Generation; DVUC-Creation-Time, which is the time when this new DVUC is created; DVUC-Expiration-Time, which is the expiration time of this new DVUC being generated; DVUC-Claims, which is one or multiple statements about the target WTRU / user that may indicate some attributes / properties / abil ities of the target WTRU / user, which has been authenticated by the CMF (e.g., DVUC- Claims may be derived from Credential-for-DVUC-Generation as received at 1402); DVUC-Owner-WTRU-ID, which is a WTRU-ID as received at 1402; DVUC-TEC-ID, which is TEC-ID as received at 1402; DVUC-Owner- WTRU-Sub-Data, which is DVUC-related subscription data of the target WTRU as received at 1404; DVUC- Sign, which is the signature for the new DVUC (e.g., the signature of the CMF which is generated according to CMF-Credential and all other parameters in WTRU-DVUC-Doc); Relevant-DVUC-ID; and / or Relevant-DVUC- Type.

[0244] Relevant-DVUC-ID is the identifier of one or more existing DVUCs that this DVUC may use together with. In other words, in one example, the user cannot use this DVUC separately but may need to present this DVUC togetherwith existing DVUCs to a service provider in orderto request services from the service provider; alternatively, the service provider may need to retrieve existing DVUCs as contained in Relevant-DVUC-ID. If the CMF does not know the exact identifiers of relevant DVUCs, this parameter may just contain the type of relevant DVUCs. Then, the TEC / user / WTRU may use the type of relevant DVUCs to identity (or prepare) corresponding DVUCs relevant to this new DVUC.

[0245] Relevant-DVUC-Type, is the type of one or more DVUCs that this DVUC may use together with. In other words, in one example, the user cannot use this DVUC separately but may need to present this DVUC together with a few other DVUCs to a service provider in order to request services from the service provider. If the user’s existing DVUCs do not match the type as specified by Relevant-DVUC-Type, the user may need to contact other CMFs (or the same CMF) again for creating such types of DVUCs. This parameter may not be needed if Relevant-DVUC-ID is contained.

[0246] Option 2: The CMF does not directly generate a DVUC document, but it may contact a third party to generate DVUC-Docwith the same format in Option 1 for the TEC. For option 2, 1405-1406 may not be needed; note that the CMF may know if it uses option 1 or option 2 for 1408 before executing 1405-1406. The word “doc” or “document” may be any type of file, message, etc. used to convey the information that is generated relevant to the process.

[0247] Each existing DVUC may have a corresponding DVUCGR stored in DLS. If Deprecated-DVUC-ID is contained in this new DVUC, the CMF may send a request to DLS to update the corresponding DVUCGR (e.g., to change DVUC-Expiration-Time to make this existing DVUC an invalid one). Redactable distributed ledgers may allow the modification to the information stored on DLS. Deprecated-DVUC-ID may provide an efficient way to track which DVUC has been updated by which DVUC (e.g., DVUC update history); otherwise (e.g., without using Deprecated-DVUC-ID), cumbersome analysis on the whole set of DVUCGRs may be needed to figure out the update history of a particular DVUC.

[0248] If the generated DVUC is a SAUC, it may include one or more of the following additional information: Target-Services, which is a list of target services (e.g., service types, service names, service identifiers) that this SAUC may be used to request (e.g., the CMF may obtain this information using 1403-1404); Service- Policies, which is service policies and / or rule for accessing target services (e.g., the CMF may obtain this information using 1403-1404); Target-Service-Providers, which is a list of service providers that may provide target services (e.g., a list of PLMN-IDs, a list of DUIDs of WTRUs); and / or, applicable-TESs, which is a list of TESs (e.g., their identifiers or DUIDS) that this SAUC DVUC can be presented to and / or can be authenticated, where this parameter may indicate a list of TESs (e.g., their identifiers or DUIDs) of each service provider.

[0249] At 1409, the CMF may create a DVUC Generation Record (DVUCGR) for each different WTRU- DUID as contained at 1401 , which may contain a subset of parameters contained in WTRU-DVUC-Doc such as: DVUC-ID, WTRU-DUID, CMF-ID, Deprecated-DVUC-ID, Relevant-DVUC-ID, DVUC-Claims, DVUC- Creation-Time, DVUC-Expiration-Time, etc.

[0250] At 1410, the CMF may send the created DVUCGR(s) to DLS. Thus, the DVUCGRs may be stored in a distributed ledger, which may be retrieved by any network entity.

[0251] At 1411, the CMF may send a DVUC generation response to the TEC. This response may include one or multiple WTRU-DVUC-Doc(s) generated at 1408. The DVUC generation response may also contain one or multiple WTRU-DUID.

[0252] At 1412, the TEC receives DVUC generation response and may pop up or send the contained WTRU-DVUC-Doc to the corresponding user. The user may store UE-DVUC-Doc privately. The TEC may continue to interact with other TESs. For example, when the target WTRU / user needs to access network services, the TEC may present WTRU-DVUC-Doc to the corresponding TES on behalf of the target WTRU / user, the TES may authenticate WTRU-DVUC-Doc.

[0253] FIG. 15 illustrates an example of a relevant DVUC-ID. The DVUC generation response may also contain one or multiple WTRU-DUID(s). The DVUC generation response may also contain one or multiple WTRU-DVUC-Doc(s) being generated as described herein (e.g., at 1408). As shown, there may be a service provider at 1591 and a user / WTRU at 1592. The WTRU may present one or more DVUCs (e.g., DVUC1 , DVUC2, DVUC3, etc.) to the service provider.

[0254] In one case, there may be a benefit of a Relevant-DVUC-ID. For purposes of this case, it may be assumed that the user already has obtained two DVUCs (e.g., DVUC1 and DVUC2) from the CMF. Then, the user requests a new DVUC (e.g., DVUC3) in order to access ServiceA. The CMF knows ServiceA also needs other DVUCs (e.g., DVUC1 and DVUC2). When the CMF generates DVUC3, it sets DVUC3’s Relevant-DVUC- ID to {DVUC1-ID, DVUC2-ID}. After the user receives DVUC3, it automatically knows that when it presents DVUC3 to access ServiceA, it also needs to present DVUC1 and DVUC2 simultaneously. Without using Relevant-DVUC-ID, the user may need to take an extra step to discover the list of DVUCs that ServiceA demands, before it can send a service request to the service provider. Using Relevant-DVUC-ID may help the service provider to automatically and efficiently detect only needed DVUCs and remove any unnecessary DVUCs, without analyzing the content of unnecessary DVUCs. Note, that if the user does not have DVUC1 and DVUC2, the CMF may indicate the type of them using Relevant-DVUC-Type as described herein (e.g., at 1408 of FIG. 14), which may be contained in DVUC3. Then, the user may contact other CMFs (or the same CMF) to generate DVUC1 and DVUC2 matching the types as specified in Relevant-DVUC-Type.

[0255] FIG. 16 illustrates an example of network-initiated DVUC generation. As shown, there may be a TEC 1691 (e.g., at the WTRU), a CMF 1692, a DG1 1694, a NFx 1695, and a DLS 1696.

[0256] A DVUC generation initiator (DGI) may initiate the generation DVUCs for a target WTRU. For example, when a target WTRU completes the primary authentication with the network, the network (e.g., SEAF) may trigger the generation of a DVUC for the target WTRU and its users, so that it may use the DVUC to access services provided by the network or other WTRUs. In an example, the TEC may be hosted by the target WTRU. The CMF may be located at edge or core network. DGI may be a NF / AF that may provide CMF credential (e.g., the private key of the CMF, signature generation scheme for the CMF), while NFy may be a NF (e.g., UDM) that the target WTRU’s subscription data may be retrieved from. DLS is a distributed ledger system that may provide immutable storage for DVUC generation records.

[0257] A DVUC generation procedure may comprise one or more of the events / actions described herein, in the order as presented or in a different order; meaning, it is intended that the actions / events listed generally with respect to a process may or may not be included in a given approach (e.g., an event / action could be skipped, and it naturally follows that if something were skipped, one or more skipped elements may be taken into consideration in a subsequent step if needed), and / or one event / action may be performed in a different arrangement than presented herein.

[0258] In a more specific example (e.g., where numbers indicate an example order), at 1601 , a DGI may trigger DVUC generation for a target WTRU / user.

[0259] One cause may be that the target WTRU may be selected for providing services for the network and / or to other WTRUs. The generated DVUC may be used by a service consumer to authenticate the target WTRU, when it requests services from the target WTRU. For example, the target WTRU may be selected by the network to be a relay WTRU for other remote WTRUs; then, the network may trigger to generate a DVUC for the target WTRU for providing relay service. After the DVUC is generated and sent to the target WTRU, it may present its DVUC to any service consumer for trust authentication, when it is requested by the service consumer.

[0260] Another cause may be that the target WTRU and / or its users may need to consume services later from the network and / or from other WTRUs. The generated DVUC may be used for authenticating the target WTRU and / or its users, when it requests services from the network and / or other WTRUs. For example, based on the target WTRU’s subscription data and / or its users’ subscription data, the network may trigger to generate a DVUC for the target WTRU and / or its users for accessing network services. After the DVUC is generated and sent to the target WTRU and / or its users, the target WTRU and / or its users may present its DVUC to any service provider for trust authentication when it needs to access services from the service provider.

[0261] DGI may be an AF that may leverage DVUC generation function / service provided by the TES to generate DVUCs for a target WTRU and / or its users. For example, the AF may be a management application, which manages the target WTRU and / or its users. The AF may also just manage DVUC for one or multiple users.

[0262] At 1602, the DGI may send a DVUC generation request to the CMF (or a special TES) assuming the DGI may have discovered the CMF, for instance, from NRF. This may be similar or the same as at 1402 of FIG. 14 (e.g., and related description herein). The generation request and may include one or more of the following parameters: WTRU-ID, which is the identifier of the target WTRU; WTRU-DUID, which is the identifier of the entity that the DVUC may be generated for, which may be the target WTRU, a user of the target WTRU, etc. (e.g., this parameter may contain separate DVUC support information for each WTRU DUID contain in this step); DVUC-Type, which is the same / similar as DVUC-Type at 1402 of FIG. 14; DVUC-Support-Info, which is the same / similar as DVUC-Support-Info at 1402 of FIG. 14 excluding Credential-for-DVUC-Generation (e.g., this parameter may contain separate DVUC support information for each WTRU-DUID contained in this step); CMF-Credential, which is the same / similar as CMF-Credential of 1404 of FIG. 14. DGI-ID, which is the identifier of DGI (e.g., an AF / NF identifier).

[0263] At 1603, subscription data may be retrieved (e.g., as described herein, such as at 1403 of FIG. 14).

[0264] At 1604, a response with the subscription data may be received (e.g., as described herein, such as at 1404 of FIG. 14).

[0265] At 1605, CMF may generate DVUC (e.g., as described herein, such as same / similar to 1408 of FIG. 14). Note, that the CMF may have maintained Credential-for-DVUC-Generation of a user / WTRU. If the CMF does not have Credential-for-DVUC-Generation of a user / WTRU, the CMF may send a separate request to theWTRU, which will forward the request to the embedded TEC; the TEC may receive the request and send the Credential-for-DVUC-Generation back to the CMF. Then, the CMF may continue with 1605. WTRU-DVUC- Doc may contain the identifier of DGI (e.g., DGI-ID).

[0266] At 1606, the CMF may create a DVUC generation record (e.g., as described herein, such as the same / similar as 1409 of FIG. 14). The created DVUCGR may contain the identifier of DGI (e.g., DGI-ID).

[0267] At 1607, the CMF may send a DVUC generation response to DGI. This response may contain DVUCGR as created at 1606.

[0268] At 1608, the CMF may send the record to the DLS (e.g., as described herein, such as the same / similar as 1410 of FIG. 14).

[0269] At 1609, the CMF may sent a notification regarding the generation of the DVUC (e.g., as described herein, such as same / similar as 1411 of FIG. 14).

[0270] At 1610, the TEC may authenticate if DGI has the right to trigger DVUC generation; if it is not allowed, the TEC may send a rejection response to the CMF and / or DGI; as a result, other steps may be skipped. In another example, the TEC may pop up or send the received DVUC generation notification to the corresponding user (e.g., as indicated by WTRU-DUID at 1609) for their approval; the user may approve the generated DVUC and send an approval message to the TEC. The TEC may send a DVUC generation confirmation to the CMF and / or DGI; alternatively, the CMF may forward the DVUC generation confirmation to DGI.

[0271] At 1611, TEC may continue to interact with other TES (e.g., same / similar as 1412 of FIG. 14).

[0272] As described herein, a higher layer may refer to one or more layers in a protocol stack, or a specific sublayer within the protocol stack. The protocol stack may comprise of one or more layers in a WTRU or a network node (e.g., eNB, gNB, other functional entity, etc.), where each layer may have one or more sublayers. Each layer / sublayer may be responsible for one or more functions. Each layer / sublayer may communicate with one or more of the other layers / sublayers, directly or indirectly. In some cases, these layers may be numbered, such as Layer 1, Layer 2, and Layer 3. For example, Layer 3 may comprise of one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 may comprise of one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Medium Access Control (MAC). For example, Layer 3 may comprise of physical (PHY) layer type operations. The greater the number of the layer, the higher it is relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the aforementioned examples may be called layers / sublayers themselves irrespective of layer number, and may be referred to as a higher layer as described herein. For example, from highest to lowest, a higher layer may refer to one or more of the following layers / sublayers: a NAS layer, a RRC layer, a PDCP layer, a RLC layer, a MAC layer, and / or a PHY layer. Any reference herein to a higher layer in conjunction with a process, device, or system will refer to a layer that is higher than the layer of the process, device, or system. In some cases, reference to a higher layer herein may refer to a function or operationperformed by one or more layers described herein. In some cases, reference to a high layer herein may refer to information that is sent or received by one or more layers described herein. In some cases, reference to a higher layer herein may refer to a configuration that is sent and / or received by one or more layers described herein.

[0273] In one example, a wireless transmit receive unit (WTRU) first obtains the address of a trust enabler server (TES) from a network function such as an access and mobility management function (AMF) or a network repository function (NRF). Once the WTRU receives a trigger from a first application to register a trust enabler client (TEC), it uses the previously received TES address to send a TEC registration request. This registration request may include information such as a WTRU identifier, a TEC identifier, or the TEC’s capability. In response, the TES returns a TEC registration response, which can provide details like the TES identifier, TES capability, or a TEC configuration. The WTRU stores this information for later use. Based on the content of the TEC registration response— such as the TES capabilities or any specific configuration parameters— the WTRU then sends a follow-up message to the TES, which may be a request to access particular functions or services offered by the TES. By following these steps, the WTRU ensures it is properly registered and authorized to use the trust-enabling features provided by the TES.

[0274] Although features and elements are described above in particular combinations (e.g., embodiments, methods, examples, etc.), one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. For example, as disclosed herein there may be a method described in association with a figure for illustrative purposes, and one of ordinary skill in the art will appreciate that one or more features or elements from this method may be used alone or in combination with one or more features from another method described elsewhere. A symbol ‘I’ (e.g., forward slash) may be used herein to represent ‘and / or’, where for example, ‘A / B’ may imply ‘A and / or B’. As used herein, ‘a’ and ‘an’ and similar phrases are to be interpreted as ‘one or more’ and ‘at least one’. Similarly, any term which ends with the suffix ‘(s)’ is to be interpreted as ‘one or more’ and ‘at least one’. The term ‘may’ is to be interpreted as ‘may, for example’ or indicate that something "does happen" or "can happen". In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random-access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0275] As disclosed herein, ‘a’ and ‘an’ and similar phrases are to be interpreted as ‘one or more’ and ‘at least one’. Similarly, any term which ends with the suffix ‘(s)’ is to be interpreted as ‘one or more’ and ‘at leastone’. The term ‘may’ is to be interpreted as ‘may, for example’. A symbol ‘I’ (e.g., forward slash) as used herein, unless otherwise indicated, represents ‘and / or', where for example, ‘A / B’ may imply ‘A and / or B'.

Claims

CLAIMSWhat is Claimed:

1. A method for use by a wireless transmit receive unit (WTRU), the method comprising: receiving an address of a trust enabler server (TES) from a first network function; receiving a trigger for registering a trust enabler client (TEC) from a first application running on the WTRU; sending a TEC registration request to the address of the TES, wherein the TEC registration request includes a TEC capability; receiving a TEC registration response from the TES, wherein the TEC registration response includes a TES capability and TEC configuration information; and sending a message to the TES based on the TES capability and TEC configuration information included in the TEC registration response.

2. The method of claim 1 , wherein the TEC registration request further includes one or more of a WTRU identifier, or a TEC identifier.

3. The method of claim 1 or 2, wherein the TEC registration response further includes a TES identifier.

4. The method of claim 1 , 2, or 3, wherein the TEC capability is related to a capability capabilities for generating a distributed user identifier (DUID) that is for verifying a distributed verifiable user credential (DVUC).

5. The method of claim 1 , 2, 3, or 4, wherein the message to the TES includes a request to access one or more functions indicated by the TES capabilities.

6. The method of claim 1 , 2, 3, 4, or 5, wherein the TES capability is related to supported User-Centric Trust (UCT) function, types of DUID, and DVUC type.

7. The method of claim 1 , 2, 3, 4, 5, or 6, wherein the first network function is an access and mobility management function (AMF) or a network repository function (N F).

8. A wireless transmit receive unit (WTRU), the WTRU comprising: means for receiving an address of a trust enabler server (TES) from a first network function; means for receiving a trigger for registering a trust enabler client (TEC) from a first application running on the WTRU; means for sending a TEC registration request to the address of the TES, wherein the TEC registration request includes a TEC capability; means for receiving a TEC registration response from the TES, wherein the TEC registration response includes a TES capability and TEC configuration information; andmeans for sending a message to the TES based on the TES capability and TEC configuration information included in the TEC registration response.

9. The WTRU of claim 8, wherein the TEC registration request further includes one or more of a WTRU identifier, or a TEC identifier.

10. The WTRU of claim 8 or 9, wherein the TEC registration response further includes a TES identifier.

11. The WTRU of claim 8, 9, or 10, wherein the TEC capability is related to a capability for generating a distributed user identifier (DUID) that is for verifying a distributed verifiable user credential (DVUC).

12. The WTRU of claim 8, 9, 10, or 11 , wherein the message to the TES includes a request to access one or more functions indicated by the TES capabilities.

13. The WTRU of claim 8, 9, 10, 11 , or 12, wherein the TES capability is related to supported User-Centric Trust (UCT) function, types of DUID, and DVUC type.

14. The WTRU of claim 8, 9, 10, 11 , 12, or 13, wherein the first network function is an access and mobility management function (AMF) or a network repository function (NRF).

Images