User equpiment decentralized public key infrastructure authentication

Abstract

Various aspects of the present disclosure relate to user equipment (UE) decentralized public key infrastructure (DPKI) authentication. A network entity composes decentralized identifier (DID) information in a DID document for a digital identity of the network entity. The DID information includes an entity type of the network entity, one or more entity association identifiers of respective one or more secondary entities associated with the network entity, and / or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

Description

USER EQUPIMENT DECENTRALIZED PUBLIC KEY INFRASTRUCTURE AUTHENTICATIONTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to decentralized public key infrastructure (DPKI) -based authentication.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, which may be otherwise known as network equipment (NE) , supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like) ) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G) ) .SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a, ” “at least one, ” “one or more, ” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” or “one or both of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. ” Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] A network entity (e.g., a UE or a NE) for wireless communication is described. The network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the network entity may be configured to, capable of, or operable to compose decentralized identifier (DID) information in a DID document for a digital identity of the network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

[0005] A processor (e.g., a standalone processor chipset, or a component of a network entity) for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may be configured to, capable of, or operable to compose DID information in a DID document for a digital identity of a network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

[0006] A method performed or performable by a network entity for wireless communication is described. The method may include composing DID information in a DID document for a digital identity of the network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

[0007] In some implementations of the network entity, the processor, and the method described herein, the network entity is at least one of a UE or a network equipment (NE) . In some implementations of the network entity, the processor, and the method described herein, the entity type of the UE is configured to support digital identities of the one or more secondary entities associated with the UE. In some implementations of the network entity, the processor, and the method described herein, the entity type of the NE is at least one of an operator network, end-user equipment, or a network device, and the entity type of the NE is configured to support a digital identity of a secondary entity associated with the NE. In some implementations of the network entity, the processor, and the method described herein, the entity type of the NE is a third-party entity configured to interface with one or more network entities, and the entity type of the NE is configured to support digital identities of the one or more secondary entities associated with the NE. In some implementations of the network entity, the processor, and the method described herein, the DID information includes a verifiable credential (VC) proof of the entity type. In some implementations of the network entity, the processor, and the method described herein, a public key use of the one or more public key uses includes the public key usable as at least one of an authentication key, a recovery key, a message encryption key, or and integrity protection key.

[0008] In some implementations of the network entity, the processor, and the method described herein, the network entity is a UE and the network entity, the processor, and the method may further be configured to, capable of, or operable to transmit, to a blockchain maintainer, a DID registration request for at least one of the UE or an individual user, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0009] In some implementations of the network entity, the processor, and the method described herein, the network entity is a network equipment (NE) and the network entity, the processor, and the method may further be configured to, capable of, or operable to transmit, to a blockchain maintainer, a DID registration request for at least one of an operator network, a network device, or a third-party entity, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0010] In some implementations of the network entity, the processor, and the method described herein, the network entity, the processor, and the method may further be configured to, capable of, or operable to transmit, to a blockchain maintainer, a DID update request that includes an updated DID document, the blockchain maintainer configured to use a recovery key in the DID document to verify the updated DID document. In some implementations of the network entity, the processor, and the method described herein, the network entity, the processor, and the method may further be configured to, capable of, or operable to transmit, to a blockchain maintainer, a DID revocation request, the blockchain maintainer configured to use a recovery key in the DID document to verify the DID revocation request.

[0011] A UE for wireless communication is described. The UE may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the UE may be configured to, capable of, or operable to transmit an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receive an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0012] A processor (e.g., a standalone processor chipset, or a component of a UE) for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may be configured to, capable of, or operable to transmit an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receive an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0013] A method performed or performable by a UE for wireless communication is described. The method may include transmitting an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receiving an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0014] In some implementations of the UE, the processor, and the method described herein, the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. In some implementations of the UE, the processor, and the method described herein, the authentication request includes a verifiable presentation (VP) of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0015] In some implementations of the UE, the processor, and the method described herein, the UE, the processor, and the method may further be configured to, capable of, or operable to receive, from the authentication function, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document; and transmit, to the authentication function, a challenge response that verifies the UE ownership of the DID document of the UE.

[0016] An NE (e.g., a verifier, authentication function) for wireless communication is described. The NE may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the NE may be configured to, capable of, or operable to receive, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmit, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0017] A processor (e.g., a standalone processor chipset, or a component of a NE) for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may be configured to, capable of, or operable to receive, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmit, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0018] A method performed or performable by an NE for wireless communication is described. The method may include receiving, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmitting, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0019] In some implementations of the NE, the processor, and the method described herein, the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. In some implementations of the NE, the processor, and the method described herein, the authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0020] In some implementations of the NE, the processor, and the method described herein, the NE, the processor, and the method may further be configured to, capable of, or operable to transmit, to the UE, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document; and receive, from the UE, a challenge response that verifies the UE ownership of the DID document of the UE.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0022] Figure 2 illustrates an example DID architecture, in accordance with aspects of the present disclosure.

[0023] Figure 3 illustrates an example of DID network (TDIDN) functions and processes, in accordance with aspects of the present disclosure.

[0024] Figure 4 illustrates an example of the European self-sovereign identity framework (ESSIF) framework and process, in accordance with aspects of the present disclosure.

[0025] Figure 5 illustrates an example of an enhanced DID document, in accordance with aspects of the present disclosure.

[0026] Figure 6 illustrates an example of a DID registration procedure, in accordance with aspects of the present disclosure.

[0027] Figure 7 illustrates an example of a DID registration procedure, in accordance with aspects of the present disclosure.

[0028] Figure 8 illustrates an example of a DID update procedure, in accordance with aspects of the present disclosure.

[0029] Figure 9 illustrates an example of a DID revocation procedure, in accordance with aspects of the present disclosure.

[0030] Figure 10 illustrates an example of a VC registration procedure, in accordance with aspects of the present disclosure.

[0031] Figure 11 illustrates an example of a VC update procedure, in accordance with aspects of the present disclosure.

[0032] Figure 12 illustrates an example of a VC revocation procedure, in accordance with aspects of the present disclosure.

[0033] Figure 13 illustrates an example of a DID verification-based authentication procedure, in accordance with aspects of the present disclosure.

[0034] Figure 14 illustrates an example of a VC verification procedure, in accordance with aspects of the present disclosure.

[0035] Figure 15 illustrates an example of a UE in accordance with aspects of the present disclosure.

[0036] Figure 16 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0037] Figure 17 illustrates an example of a NE in accordance with aspects of the present disclosure.

[0038] Figure 18 illustrates an example of a network entity in accordance with aspects of the present disclosure.

[0039] Figure 19 illustrates a flowchart of a method performed by a UE in accordance with aspects of the present disclosure.

[0040] Figure 20 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

[0041] Figure 21 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

[0042] Figure 22 illustrates a flowchart of a method performed by a network entity in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0043] In a wireless communications system, a UE and an NE (e.g., a base station, gNB, network infrastructure device) may support wireless communication (e.g., reception and / or transmission of wireless communication) using time-frequency resources. For example, devices (e.g., the UE and the NE) in the wireless communications system may support transmitting and / or receiving signals. Reference is made herein to communicating data or information, such as signaling communication resources and / or communications that are transmitted or received between devices. It is to be appreciated that other terms may be used interchangeably with communicating, such as signaling, transmitting, receiving, outputting, forwarding, retrieving, obtaining, and so forth.

[0044] Current UE authentication processes rely on a universal subscriber identity module (USIM) card or e-SIM profile of a single operator, which may limit flexibility in the evolving telecommunications landscape, where inter-network integration and user autonomy and / or user controlled privacy are aspects for future 5G-Advanced (5GA) and / or 6G evolution. Although some DID schemes offer potential solutions, they face limitations, such as inadequate field extensibility, particularly in telecom-related areas, as well as ambiguity between individual (i.e., end-user or subject) and issuer identities, and inefficiencies in multi-VC authentication. Additionally, these DID schemes lack specialized management of payment credentials, as well as integrating social attributes with telecom identifiers, leading to inefficiencies and high security risks.

[0045] Aspects of the present disclosure are directed to an enhanced DID document for telecommunication scenarios. In particular, one or more aspects depicted herein provide for authentication VCs with data and claims specific to telecom network and / or service access scenarios, as well as a DID-based authentication challenge exchange for mutual authentication between an end device (e.g., a UE) and the network. Aspects of this disclosure can be implemented to define specific information for telecom use cases, where a wireless communications device may add information elements (IEs) to enhance a DID document that a network operator can use to verify the authentication of a subscriber, and subsequently provide secure mobile operator services, as well as protect wireless communications between the subscriber and the operator network. Additionally, aspects depicted herein may be implemented to provide the mobile operator services in a secured manner. Additionally, aspects of this disclosure are directed to VC lifecycle management, as related to VC registration, update, and revocation.

[0046] In implementations of the describe techniques, an enhanced DID document addresses the issue of having a lack of a specially designed DID document for telecommunications scenarios and has several advantages. By adding entity type field, a DID document contains information relevant to a device. Such information may indicate the type of DID owner or holder, and whether the DID holder is qualified to issue VCs. This can be particularly useful in scenarios where specific types of entities possess certain credentials or permissions. The introduction of the entity type field also provides a clear and distinct categorization between individuals and issuers. The entity type field can also facilitate the verification process by indicating the nature of the entity associated with the DID, reducing the ambiguity that can lead to verification difficulties. In addition, different types of entities may have different identity verification requirements and procedures which can be standardized by the new entity type field. The enhanced DID document anchors trust in the user's identity, allowing for secure and efficient authentication across multiple devices. With the identity as the core element, the DID system can implement continuous authentication processes that verify a user's identity in real-time, even as the user switches between devices. Linking the DID to the user's identity enhances security by ensuring that only authenticated users can access services, which reduces the risk of unauthorized access and potential data breaches.

[0047] Aspects of the present disclosure are also directed to VC lifecycle management, with enhanced VC types specific to telecommunication scenarios. To enhance the clarity and functionality of different types of VCs, they are distinguished based on their specific roles within the telecommunication system. This differentiation enables the development of targeted management aspects for each VC type. Furthermore, during a certification issue process, various VCs are aggregated into verifiable presentations (VPs) , which can be utilized to achieve a more robust and secure telecommunications authentication framework. In order to achieve more efficient and flexible identity authentication in telecommunication scenarios, three types of VC are described in aspects of this disclosure. In particular, the three types of VCs include a user attribute VC, a payment VC, and an authentication VC.

[0048] Implementations of these new types of VCs provide several advantages in conjunction with management, efficiency, privacy, and flexibility. With reference to management, separating payment VCs from authentication VCs ensures that, while payment VCs confirm ongoing contractual relationships, authentication VCs can be revoked for issues like payment delinquency, simplifying management. With reference to efficiency, authentication VCs are optimized for a quick, lightweight verification, reducing the number of VCs needed, and streamlining system processes. With reference to privacy, with authentication VCs containing no sensitive user data and relying on a public key for identity representation, user privacy is strongly protected. With reference to flexibility, the design provides for multiple devices to access the network with a single authentication VC, and payment VCs can be easily transferred between operators, facilitating quick reissuance of authentication VCs during operator switching, thereby enhancing the convenience of roaming.

[0049] Aspects of the present disclosure are described in the context of a wireless communications system.

[0050] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

[0051] The one or more NEs 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NEs 102 described herein may be or include or may be referred to as a network node, a base station, an access point (AP) , a network element, a network function, a network entity, a radio access network (RAN) , a NodeB, an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0052] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN) . In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0053] The one or more UEs 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (IoT) device, an Internet-of-Everything (IoE) device, or machine-type communication (MTC) device, among other examples.

[0054] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0055] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., S1, N2, N6, or other network interface) . In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other indirectly (e.g., via the CN 106) . In some implementations, one or more NEs 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0056] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an access and mobility management functions (AMF) ) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a packet data network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more NEs 102 associated with the CN 106.

[0057] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an S1, N2, N6, or other network interface) . The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106) .

[0058] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) ) to perform various operations (e.g., wireless communications) . In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0059] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0060] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0061] Additionally, or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols) . In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0062] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data) . In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0063] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g., μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g., μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., μ=3) , which includes 120 kHz subcarrier spacing.

[0064] Some wireless communications systems may support an enhanced DID document for telecommunication scenarios. In particular, one or more aspects depicted herein provide for authentication VCs with data and claims specific to telecom network and / or service access scenarios, as well as a DID-based authentication challenge exchange for mutual authentication between a UE and the network (e.g., a NE, network infrastructure device) . Aspects of this disclosure define specific information for telecom use cases, where a wireless communications device may add information elements (IEs) to enhance a DID document that a network operator can use to verify the authentication of a subscriber, and subsequently provide secure mobile operator services, as well as protect wireless communications between the UE and the operator network. Additionally, aspects depicted herein may be implemented to provide the mobile operator services in a secured manner. Additionally, the wireless communications system may support VC lifecycle management, as related to VC registration, update, and revocation.

[0065] An enhanced DID document addresses the issue of having a lack of a specially designed DID document for telecommunications scenarios and has several advantages. By adding entity type field, a DID document contains information relevant to a device. Such information may indicate the type of DID owner or holder, and whether the DID holder is qualified to issue VCs. This can be particularly useful in scenarios where specific types of entities possess certain credentials or permissions. The introduction of the entity type field also provides a clear and distinct categorization between individuals and issuers. The entity type field can also facilitate the verification process by indicating the nature of the entity associated with the DID, reducing the ambiguity that can lead to verification difficulties. In addition, different types of entities may have different identity verification requirements and procedures which can be standardized by the new entity type field. The enhanced DID document anchors trust in the user's identity, allowing for secure and efficient authentication across multiple devices. With the identity as the core element, the DID system can implement continuous authentication processes that verify a user's identity in real-time, even as the user switches between devices. Linking the DID to the user's identity enhances security by ensuring that only authenticated users can access services, which reduces the risk of unauthorized access and potential data breaches.

[0066] Additionally, aspects of VC lifecycle management, with enhanced VC types specific to telecommunication scenarios, provides clarity and functionality of different types of VCs, and they are distinguished based on their specific roles within the telecommunication system. This differentiation enables the development of targeted management aspects for each VC type. Furthermore, during a certification issue process, various VCs are aggregated into VPs, which can be utilized to achieve a more robust and secure telecommunications authentication framework. In order to achieve more efficient and flexible identity authentication in telecommunication scenarios, three types of VC are described in aspects of this disclosure. In particular, the three types of VCs include a user attribute VC, a payment VC, and an authentication VC.

[0067] With reference to conventional world wide web consortium (W3C) decentralized identifiers, the DIDs allow individuals or entities to establish unique, verifiable identities on the network without relying on a third-party. The W3C provides a generic model for the structure of a DID, which is standardized and follows a specific uniform resource identifier (URI) scheme of components in a DID architecture.

[0068] Figure 2 illustrates an example DID architecture 200 in accordance with aspects of the present disclosure. The example DID architecture 200 includes a DID subject 202 that refers to any object or individual, such as a device, terminal, user, organization, or institution. A DID uniform resource locator (URL) 204 extends the syntax of a basic DID to incorporate other standard uniform resource identifier (URI) components. A simple example of a DID is represented as “scheme: DID method: DID method-specific identifier. ” A DID document 206 contains basic information about the DID and data, such as public keys, used for identity verification and interaction. A DID resolver 208 is used to resolve the DID document 206, and retrieve specific information about the DID. A DID method defines how to create, read, update, and delete DIDs on a specific underlying system. A DID controller 210 has the authority to modify DID documents, and the controller can be the subject itself or another entity that controls the DID associated to the subject.

[0069] However, the existing DID scheme of W3C is a general solution and cannot be directly applied to specific scenarios, such as for telecommunications and / or network access scenarios. In particular, there are several issues with telecommunications access scenarios. For example, the specific field design of traditional DIDs is not clear enough and does not provide relevant information of a mobile network, which can include a universally unique identifier (UUID) , a hypertext transfer protocol (HTTP) , and / or a URI or third-generation partnership project (3GPP) identifiers. Accordingly, the existing DID scheme is enhanced to add, delete, or modify some fields for implementation in the telecommunications scenarios.

[0070] Traditional DIDs lack a clear distinction between individuals and issuers. This ambiguity can lead to a range of issues, such as difficulties in verifying the identity of parties involved in transactions, challenges in establishing trust between entities, and potential security risks due to the inability to accurately identify the users and issuers. Besides, due to the different roles that individuals and institutions have in the system, there is a difference between trust levels and different verification methods are needed. In the traditional model, issuers typically use the same device to perform the issuance tasks. However, if they switch to another device for login, it is necessary to reconsider the identity verification. The enhanced and newly designed DID system described herein enables implementation of a quick link between new devices and issuers’ identity to facilitate effective authentication.

[0071] With reference to conventional W3C verifiable credentials, a VC is a trustworthy digital credential that can be cryptographically verified. The holder of a VC can present the VC to verify and prove that they possess specific attributes, characteristics, or information, as claimed. The W3C provides the specification for the VC data model, which offers a secure, privacy-preserving, and verifiable method for expressing various types of credentials. According to the W3C, the core components of a VC include a set of tamper-evident and resistant claims, and metadata that cryptographically proves the identity of the issuer. The VC specification can foster digital trust among diverse network participants, laying the foundation for a decentralized identity ecosystem.

[0072] The basic components of a VC include credential metadata, claim (s) , and proof (s) . However, the current VC mechanisms still have some issues, including unclear access control for different types of VCs, redundant identity authentication processes, and a lack of specialized management for payment credentials. These challenges hinder the efficiency and business expansion for telecom services. For example, the existing identity and access management systems are based on the general W3C framework and have not explicitly classified and defined different types of verifiable credentials for telecom scenarios, such as identity verification credentials, attribute credentials, and payment credentials. Ambiguous classification makes it more complex to implement effective access control across different services, potentially impacting the security and efficiency of the services.

[0073] In many cases, users are required to present multiple VCs for identity authentication. This not only increases the burden on the user but also results in information redundancy. Additionally, the identity authentication mechanisms between different services may be inconsistent. This redundant authentication process increases the system's complexity, thereby reducing service timeliness. For real-time telecom services, such as real-time identity verification, requiring multiple VCs can slow down the authentication process. In such cases, the system needs to quickly verify the user's identity while ensuring security. Therefore, reducing the number of required VCs or optimizing the verification process becomes a pressing issue to be addressed. Further, payment credentials typically involve higher security and privacy protection requirements, necessitating specific management and handling methods. In the current solutions, operators typically manage their service bills and tariffs separately, which means users may need to register and make payments with multiple operators, increasing complexity.

[0074] With reference to a telecom DID network, the TDIDN integrates DIDs with telecom services, aiming to improve the identity management in the telecom industry. It is built on Hyperledger Indy and Hyperledger Aries, two open-source blockchain frameworks specifically designed to create secure and decentralized identity systems.

[0075] Figure 3 illustrates an example 300 of TDIDN functions and processes in accordance with aspects of the present disclosure. The example 300 of TDIDN functions and processes include managing international mobile equipment identity (IMEI) numbers, managing subscriber identity module (SIM) cards, and handling call detailed record (CDR) . With reference to managing IMEI numbers, a user creates a secure wallet to store personal data and requests IMEI numbers from authorized sources. These numbers, along with blacklist status and owner DID information, are stored via smart contracts, allowing verifiers to easily check and confirm device ownership, enhancing both security and transparency. With reference to managing SIM cards, a user can obtain a SIM card by providing a DID and a government credential. The telecom authority issues a SIM card and a digital credential with details, like a phone number and operator. A user can prove ownership without revealing their phone number, ensuring privacy. With reference to handling CDR, a CDR captures all relevant data for each phone call, identified by a DID. To calculate a customer’s bill, the smart contract uses DID to retrieve all associated CDRs and then computes the charges for each call according to the terms and conditions. The smart contract for the related operator can be configured to pay for the bill as required.

[0076] The TDIDN delivers a comprehensive architecture for implementing DIDs, offering secure identity verification application programming interfaces (APIs) to third-party service providers. Transitioning from a siloed and centralized model to a collaborative and decentralized framework empowers users to manage their digital identities securely while enhancing privacy. However, there are some limitations for the future telecom networks. For example, the device IMEI is bound to its corresponding user DID. When verifying the identity of a device, it is essential to verify both the user and the device itself. However, the blacklist that records a device's status and the DID information are stored on two different distributed ledgers. This setup requires the verifier to request information from two separate positions to obtain the authentication results, which reduces the efficiency of the process.

[0077] Additionally, the user presents a credential issued by the operators to prove control of their phone number. This credential is likely to remain unchanged unless the user switches operators, meaning it could be used for a long period of time. However, since this credential may be frequently presented when accessing telecom services, it could be exposed in insecure environments. This repeated exposure increases the risk of malicious users initiating forgery or impersonation attacks. The TDIDN binds DIDs to telecom service-related identifiers, such as phone numbers. However, the design does not explicitly support the association of real-world social attributes with the DID. This results in a disconnect between the identifier and the user's attributes, making it difficult to achieve broad recognition and authentication of the user's identity.

[0078] With reference to European self-sovereign identity framework, the ESSIF is part of the European blockchain service infrastructure. ESSIF aims to implement a generic self-sovereign identity (SSI) capability, providing trusted, secure, and decentralized digital identities across borders for all Europeans without relying on centralized authorities. However, this type of identity service is not easily extended to telecom network infrastructures due to fundamental differences in operational requirements, such as control of identities by the identity holder. In contrast, telecom networks have a complex, layered infrastructure, and operators are responsible for verifying and monitoring the identity data. For example, in a telecom network, a an identity holder provides identifying information to for network controlled authentication and service level access. Additionally, a network entity controls access to network services for an identity holder, user devices, and secondary devices that may be associated with the identity holder.

[0079] Figure 4 illustrates an example 400 of the ESSIF framework and process in accordance with aspects of the present disclosure. In this example 400, the ESSIF is a generic and interoperable SSI framework. This framework would define the necessary specifications and provide the supporting services and capabilities that allow citizens to create, control, and use their own digital identity without having to rely on a single, centralized authority. The ESSIF is part of a wider ecosystem of decentralized identity and will interact with other systems and platforms of public and private organizations. ESSIF is specifically aimed at alignment with European legislation, including the electronic identification and trust services (eIDAS) and general data protection regulation (GDPR) . The identity service provided by the European blockchain services infrastructure (EBSI) is based on W3C specifications for DIDs and the verifiable credentials data model.

[0080] The basic process of issuing and using an ESSIF identity involves two key steps, as shown in the example 400, including issuing a verifiable ID 402. A citizen 404 logs in using an eID card 406 to authenticate their identity. Upon successful verification, the government 408 issues the verifiable ID 402 containing the citizen's authenticated identity data. Using the verifiable ID 402, the citizen then uses this verifiable ID to authenticate themselves, such as during the onboarding process at a demo bank 410. However, the identity service instantiated in ESSIF cannot be easily extended to telecom network infrastructures due to fundamental differences in architecture and operational requirements. The ESSIF is a cloud-based solution that operates data and services across multiple nodes in a fully decentralized manner, allowing for greater control by the identity holder. In contrast, telecom networks have a complex, layered infrastructure, where operators play a crucial role, and these operators are responsible for verifying and monitoring the identity data.

[0081] Various aspects of this disclosure are an enhanced DID document for telecommunication scenarios. In particular, one or more aspects depicted herein provide for authentication VCs with data and claims specific to telecom network and / or service access scenarios, as well as a DID-based authentication challenge exchange for mutual authentication between an end device (e.g., a UE) and the network. Aspects of this disclosure can be implemented to define specific information for telecom use cases, where a wireless communications device may add information elements (IEs) to enhance a DID document that the network operator can use to verify the authentication of a subscriber, and subsequently provide secure mobile operator services, as well as protect wireless communications between the subscriber and the operator network. Additionally, aspects depicted herein may be implemented to provide the mobile operator services in a secured manner. Additionally, aspects of this disclosure are directed to VC lifecycle management, as related to VC registration, update, and revocation.

[0082] With reference to DID lifecycle management, aspects of the present disclosure include an enhanced DID-based identity system based on blockchain (or a decentralized permissioned distributed ledger) , to manage and use decentralized digital identities and related authentication, as well as authorization credentials for end-users and / or devices and organizations. Specific to the telecom scenario, the DID document is enhanced to include new fields, such as entityType (or alternatively termed as subjectType) , device (or alternatively termed as deviceCapability) , entityAssociationIdentifiers, and recoveryKey, in addition to the existing fields such as DID controller, verification information (e.g., public keys of the DID subject for authentication, authorization, and other purposes) , service information, proof, and other information.

[0083] The controller of a DID is the entity (e.g., person, organization, or autonomous software) that has the capability to make changes to a DID document. This capability is typically asserted by the control of a set of cryptographic keys used by software or other mechanisms acting on behalf of the DID subject or DID holder. Note that a DID might have more than one controller, and the DID subject can be the DID controller, or one of them.

[0084] Figure 5 illustrates an example of an enhanced DID document 500 in accordance with aspects of the present disclosure. In this example structure of the DID document 500, the DID document 500 includes an entity type (entityType, or alternatively termed as subjectType) , and in various implementations, the entity type may be indicated as a first entity type 502 individual user or subscriber; as a second entity type 504 operator network or network device; or as a third entity type 506 third-party service provider, organization, or trust institution. The entityType (or alternatively termed as subjectType) states a DID holder’s entity type (e.g., as an individual user, a subscriber, an operator network, a network device, a network function, a relay node, a third-party service provider, an organization, and / or a trust institution (e.g., a trust service provider) ) .

[0085] The DID document 500 includes a device field (or alternatively termed as deviceCapability) and the device field varies based on the entity Type and a related device’s capability or function. For the first entity type 502 as an individual user, then the device field may indicate a UE, an IoT device, a wearable device, medical equipment, an unmanned aerial vehicle, a vehicle, a relay node, etc. based on the type of the device involved that performs a specific function. The device field refers to the equipment that users use for service access (i.e., the devices which are bound to the user and / or UE subscription with the mobile network operator) . This supports scenarios where an individual may use multiple devices simultaneously.

[0086] For the second entity type 504 as an operator network or a network device, then the device field may indicate any type of a relay node, a radio access network (RAN) node, a RAN function, a satellite access function, a core network function, an application function, and / or infrastructure function or device. The device field indicates critical infrastructure nodes and functions necessary for delivering and managing network services. This ensures that these components can be referenced, enabling mutual authentication between network elements. For the third entity type 506 as a third-party service provider, an organization, or a trust institution (e.g., an entity that communicates as part of the operator network, but is not located within the network) , then the device field may indicate any of an application function or an application server. The device field indicates the applications that these entities use to provide services or manage interactions with users or networks.

[0087] The DID document 500 also includes entity association identifiers (indicated as entityAssociationIdentifiers) . For the first entity type 502 as an individual user, then the entity association identifiers field indicates one or more usernames, user equipment identifier (s) , IoT device (s) , an unmanned aerial vehicle, a vehicle, relay node identifiers, and / or DIDs of the associated users or device (s) . This facilitates one or more end users to be authenticated using DID while accessing a service using different UEs, IoT devices, an unmanned aerial vehicle, vehicles, or operating UEs as relay nodes, respectively. When an individual user shares services with others (e.g., family members or collaborators) , this entity association identifiers field can indicate additional identifiers of other users and devices associated with the primary user.

[0088] For example, one primary user can be a subscriber of the mobile network operator and certain associated devices of the primary user (e.g., all devices and wearables belonging to the primary user) or certain associated devices related to the primary user (e.g., family members of the primary user or his or her household devices) can be considered as the secondary user to be authorized and allowed to use the services under the subscription of the primary user. For example, the primary user’s subscription is also used to provide services to the dependent secondary users, such as when the entity association identifiers includes the list of all secondary user identifiers (DIDs) , as authorized by the primary users and the mobile network operator based on the primary user’s subscription.

[0089] For the second entity type 504 as an operator network or a network device, or for the third entity type 506 as a third-party service provider, an organization, or a trust institution, then these entities usually issue VC (s) to other users. The entity association identifiers field lists the materials (e.g., authorization to operate or function as a VC issuer) that users need to submit when applying for VC from these organizations. Alternatively, for the entity type 502 for an individual user, a VC proof (VCproof) can indicate authorization credentials and / or proof, or subscription credentials and / or proof to obtain the authorization verification or approval VC from the mobile operator network for the DID to facilitate the required authorization verification for use at a later time for the service and / or access as-needed for the DID subject respective to the entity type. Alternatively, the VC proof (VCproof) can indicate the type of VC proof that is available for the DID to facilitate the required authorization verification for the service and / or access requested by the DID subject respective to the entity type. For example, for the entity type 502 for an individual user, then the VC proof may indicate the information related to authentication credentials or subscription credentials.

[0090] The DID document 500 includes a section for public key list 508 (publicKeyList) . This section lists the public keys used by the DID holder, and each key is defined by its identifier, encryption algorithm, and public key value. These public keys are applied in various scenarios, while the corresponding private keys are securely held and kept confidential by the DID holder. A section public key usage 510 (publicKeyUsage) specifies the purpose of the public keys in different contexts, with all of the public keys originating from the public key list. Several alternative usage scenarios are included. For example, an authentication key (authenticationKey) indicates the public key that can be used in everyday authentication scenarios, such as during registration, a registration update, service access, packet data unit (PDU) session establishment, PDU session modification, third-party service access, for specific network slice access, etc. If an entity can prove possession of the private key corresponding to this public key, it verifies the entity as the DID holder.

[0091] A recovery key (recovery key) includes the public key used to perform various aspects, such as to update and / or revoke DID, and / or update and / or revoke the authentication Key. The primary key, such as the authentication Key, is frequently used for general network access, such as for daily operations, making it more susceptible to various potential risks. For operations that require higher security, such as updating or revoking the DID document and / or updating or revoking the authentication Key, a backup key with better confidentiality is used. Additionally, the backup key ensures safe key updates or revocations if the primary key is compromised or fails, maintaining the overall security. With a message encryption key (MessageEncryptionKey) , a message sender can use this public key to encrypt confidential information and send it to the DID holder, ensuring that only the DID holder can decrypt and receive the intended message. With an integrity protect key (IntegrityProtectKey) , a message sender can use the private key to sign the hash value of the message. The receiver uses the public key (IntegrityProtectKey) to verify the signing, ensuring that it has not been tampered with during transmission or storage. Alternatively, the public key used for the message encryption and integrity protection can either be two different keys or can be the same public key used for the two purposes, respectively.

[0092] The DID document 500 includes a service field 512. This provides for communicating or interacting with the DID subject or associated entities via service endpoints (e.g., URIs) . Examples include resolution services, social networking services, file storage services, network services, third party services, application services, etc. For an institution, it can be VC issue service, and serviceEndpoint points to a location where the user can query the list of materials needed for VC application. In the case of telecom, it can also include one or more of network access service information or third party service or network slice service information (e.g., enhanced Mobile Broadband (eMBB) , vehicle-to-everything (V2X) service, ultra-low latency (URLLC) service, unmanned aerial vehicle (UAV) service, satellite access service, 3GPP access, non-3GPP or wi-fi access, IP multimedia subsystem (IMS) , voice over IP (VOIP) , etc. ) . The DID document 500 also include a proof field 514, which can be used to demonstrate control over a DID or a DID document. Cryptographic digital signatures enable DID documents to be verifiable. A proof can include a cryptographic digital signature or hash of the DID document information.

[0093] In aspects of the disclosure, the enhanced DID document 500 addresses the issue of having a lack of a specially designed DID document for telecommunications scenarios and has several advantages. By adding the field entity type (entityType) , the DID document contains relevant information of the device, indicating the type of the DID owner or holder, and whether the DID holder is qualified to issue VCs. This can be particularly useful in scenarios where specific types of entities are required to possess certain credentials or permissions. The introduction of the entity type field can provide a clear and distinct categorization between individuals and issuers. It can facilitate the verification process by indicating the nature of the entity associated with the DID, reducing the ambiguity that can lead to verification difficulties. In addition, different types of entities have different identity verification requirements and methods which can be standardized by the new field. The enhanced DID document anchors trust in the user's identity, allowing for secure and efficient authentication across multiple devices. With the identity as the core element, the DID system can implement continuous authentication processes that verify the user's identity in real-time, even as the user switches between devices. Linking the DID to the user's identity enhances security by ensuring that only authenticated users can access services. This reduces the risk of unauthorized access and potential data breaches.

[0094] Figure 6 illustrates an example of a DID registration procedure 600 in accordance with aspects of the present disclosure. In this example, the DID registration procedure 600 is for an individual user 602, to register with a blockchain maintainer 604 that utilizes a blockchain application 606. The registration processes for individual users and institutions (e.g., service providers, mobile network operators, network vendors, or telecom related organizations) on the blockchain are different. For individual users, there are no specific restrictions on DID registration. Their DIDs do not need to be linked to actual identities in the physical world and can maintain anonymity, as long as the registered DIDs are compliant with the standards. However, for institutions, there are generally stricter scrutiny mechanisms during the initial registration process. Institutions typically play a role in issuing VCs, which are trusted network credentials that require high levels of security, trust, and authority from their issuers. Therefore, in addition to meeting the basic requirements for DID registration, institutions also need to provide documentation that demonstrates their authoritative identity in the physical world and to gain broad recognition from multiple parties.

[0095] For individual users to register their DID and upload a DID document on the blockchain, the DID registration procedure 600 includes the individual user and / or UE preparing the relevant information (e.g., access devices, associated identity identifiers, public key lists, and public key usage methods) , and including it in the registration information, thereby initializing the information for DID registration (at 608) . The user 602 (at 610) communicates a registration request to the blockchain maintainer (a function in the network e.g., can be any function which is responsible to authenticate or to initiate authentication for the UE and / or user) , which includes the DID, the information for DID registration (i.e., enhanced information for DID registration as shown and described with reference to Figure 5) , and a timestamp. The timestamp is used to prevent replay attacks, along with a digital signature. The user signs the registration request with the private key corresponding to the authentication Key in the registration information. Alternatively, the user and / or UE sends the DID document itself with the registration request.

[0096] The blockchain maintainer 604 receives the registration request (at 612) and first verifies the signature of the request using the public key contained in the authentication Key field, ensuring the integrity and correctness of the message, and checks that the timestamp has not been reused (and / or verifies if the received timestamp is not exceeding the current allowed time period) . At this point, the maintainer constructs the DID document from the information provided for DID registration. Alternatively, if the user and / or UE sends the DID document itself with the registration request, then blockchain maintainer 604 uses the received DID document after the successful verification of the signature and the timestamp (being the fresh one) . The blockchain maintainer 604 constructs a transaction to call the smart contract on the blockchain application 606 that is specifically designed for validating and managing DIDs (at 614) (assuming this contract has already been deployed) . The transaction includes the DID to be registered, the DID document, and relevant data (e.g., operation type and transaction initiator, such as a maintainer identifier) .

[0097] At the blockchain application 606, the contract automatically executes validations (at 616) , including a uniqueness check, a format validation, and a signature verification. For the uniqueness check, the blockchain application queries the list of already stored DIDs on the blockchain to check if the DID to be registered already exists. If it does, it returns a failure status indicating that the DID has already been registered. For the format validation, the blockchain application checks the structure of the DID document against predefined format standards and ensures that it contains the necessary fields. For the signature verification, the blockchain application uses the public key included in the DID document to verify the document's signature, ensuring that the document has not been tampered with during transmission and that it was in fact generated by the DID holder.

[0098] If all of the validations are successful, the contract continues with the storage logic (at 618) , saving the DID and document on the blockchain using a mapping data structure. Each DID serves as a key, with the corresponding DID document as its value. After successful storage, the contract generates a transaction receipt confirming the registration (at 620) , which includes relevant information about the DID registration, such as the DID, the block height (i.e., acts as a block address for a quick search of evidence query when needed) , and registration time and result for future queries. If any validation fails, the contract generates a transaction receipt detailing the failure reason, or cause code and / or error code. The blockchain maintainer 604 receives the blockchain transaction receipt (at 620) , confirming either the successful registration or the reason for validation failure. The blockchain maintainer 604 then provides feedback (at 622) as the registration result to the user 602 and encrypts this message using the public key contained in the message encryption key field, ensuring that only the user can decrypt and access the information.

[0099] Figure 7 illustrates an example of a DID registration procedure 700 in accordance with aspects of the present disclosure. In this example, the DID registration procedure 700 is for institutions 702, to register with a blockchain maintainer 704 that utilizes a blockchain application 706. For non-individual users, such as operators, service providers, and trusted institutions, the process of registering their DID and uploading the DID document on the blockchain includes the institution prepares (at 708) relevant information (e.g., entity related to application functions, network functions, nodes, application servers used for interaction, a list of materials required for users to apply for VCs, public key lists, public key usage methods, etc. ) and includes it in the enhanced information for DID registration, thereby initializing the registration process.

[0100] The institution 702 sends a registration request (at 710) to the blockchain maintainer 704 (a function in the network, such as any function which is responsible to authenticate or to initiate authentication) . The institution undergoes stricter identity verification than users during the initial approval process. In addition to the basic DID, the information for DID registration, and a timestamp, the request also includes credential information that proves its actual identity (e.g., business licenses or certificates as authorization information to let the entity operate and / or function as a VC issuer) . The institution 702 signs the request using the private key corresponding to the authentication Key field. Upon receiving the request, the blockchain maintainer 704 first verifies (at 712) the signature of the request to ensure the integrity and correctness of the message, and checks the timestamp validity. The blockchain maintainer can then help to generate the DID document based on the provided information.

[0101] The blockchain maintainer 704 constructs a transaction (at 714) to call the smart contract on the blockchain application 706 that is specifically designed for managing institutional DIDs, passing in the DID to be registered, the DID document, and relevant data. The contract automatically executes the validation of the institutional DID and document (at 716) , including checking the global uniqueness of the DID, ensuring format compliance, and validating the signature. If the validation is successful, the contract generates a transaction receipt (at 718) containing relevant information about the successful DID validation, including the DID, validation time and result, and block height where it is stored for future queries. If the validation fails, the contract generates a transaction receipt based on the reason for the failure.

[0102] The blockchain application 706 returns the transaction receipt of DID check to the blockchain maintainer 704 (at 718) . If the verification result is a successful validation, the blockchain maintainer 704 broadcasts the receipt (at 720) along with the institution's credential information proving its actual identity to other maintainers. The other maintainers then vote on whether to accept the institution into the consortium and grant it the qualification to issue VCs, using a voting consensus mechanism (e.g., practical byzantine fault tolerance (PBFT) , proof of authority (POA) , etc. ) . If more than two-thirds of the total number of consortium chain nodes agree, the institution 702 is deemed qualified for registration on the blockchain (proceeding to the next steps) . If validation fails, the blockchain maintainer 704 will provide feedback on the failure reason to the institution 702 (and skip the next steps) .

[0103] The blockchain maintainer 704 constructs a new transaction (at 722) to call the contract used for managing institutional DIDs, which stores the DID and document on the blockchain. After the completion of the storage, the blockchain maintainer 704 receives a new transaction receipt (at 724) containing relevant information about the successful DID registration, including the DID, storage time and result, and block height (i.e., a block address) . The blockchain maintainer 704 provides feedback (at 726) on the registration result to the institution 702 and encrypts this message using the public key contained in the message encryption key field, and additionally the blockchain maintainer may send the public key of the blockchain maintainer in clear text. Further the blockchain maintainer 704 can sign the entire registration result message along with the clear text public key, ensuring that the messages can be transmitted confidentially and securely as it is now both confidentiality protected by message encryption key of the institution and integrity protected by the private key of the blockchain maintainer.

[0104] Figure 8 illustrates an example of a DID update procedure 800 in accordance with aspects of the present disclosure. In this example, the DID update procedure 800 is similar to registration, but involves an entity 802 signing the new DID document with the recovery key from the previous version before submitting the update request to a blockchain maintainer 804 that utilizes a blockchain application 806. The entity 802 prepares the updated information and generates a new DID document (at 808) , signing the DID document with the private key corresponding to the public key in the recovery key field of the original DID document. The entity 802 initiates an update request (at 810) , which is signed using the private key corresponding to the recovery key. For individual users (e.g., as the entity 802) , the request includes the DID, the DID document, and a timestamp. For institutions (e.g., as the entity 802) , the request also includes the institution's license and / or certificate (e.g., any VC authorization information which authorizes the entity to operate or function as a VC issuer) in addition to the basic DID update information.

[0105] The blockchain maintainer 804 requests the corresponding original DID document (at 812) from the blockchain application 806 based on the received DID. The blockchain application 806 resolves the DID (at 814) . If the DID is valid, the blockchain application 806 returns the corresponding DID document; if the DID is invalid or revoked, an error or revocation notice is returned, respectively. The blockchain application 806 then communicates the parsed result to the blockchain maintainer (at 816) . The blockchain maintainer 804 verifies the validity of the request signature (at 818) using the public key corresponding to the recovery key field in the original document. The blockchain maintainer 804 may send a response message with acknowledgement as a success indication to the entity 802 encrypted with the public key of the entity in the recovery key and along with the public key of the maintainer in clear text. Further the blockchain maintainer can sign the entire acknowledgement message along with the clear text public key, ensuring that the response message can be transmitted confidentially and securely as it is now both confidentiality protected by recovery key of the institution and integrity protected by the private key of the blockchain maintainer. The subsequent steps are similar to those in the registration phase. Specifically (at 820) , for individual users, proceed to perform steps 614-622 in Figure 6 in the DID registration procedure (individual users) . For institutions, proceed to perform steps 714-726 in Figure 7 in the DID registration procedure (institutions) .

[0106] Figure 9 illustrates an example of a DID revocation procedure 900 in accordance with aspects of the present disclosure. In this example, the DID revocation procedure 900 includes an entity 902 signing a DID revocation request with the recovery key (from the previous version) while sending the DID or DID document revocation request to a blockchain maintainer 904 that utilizes a blockchain application 906. The entity 902 communicates a revocation request to the blockchain maintainer 904 (at 908) , and the request includes the DID to be revoked, timestamp, and signature created using the private key of the recovery key associated with the DID. The blockchain maintainer 904 requests the corresponding original DID document (at 910) from the blockchain application 906 based on the received DID. The blockchain application 906 resolves the DID (at 912) and returns the corresponding DID document to the blockchain maintainer. If the DID is invalid or revoked, an error or revocation notice is returned, respectively.

[0107] The blockchain maintainer 904 verifies the validity of the request signature (at 914) using the public key corresponding to the recovery Key field in the original document. The blockchain maintainer 904 constructs a transaction (at 916) to call the smart contract used for managing entity DID, which marks and / or records the DID as revoked on the blockchain. After the completion of the mark and / or revocation recording, the blockchain maintainer 904 receives a new transaction receipt (at 918) containing relevant information about the successful DID revocation, including the DID, revocation time and result, and block height. The blockchain maintainer 904 then provides (at 920) feedback on the revocation result to the entity 902 and encrypts this message using the public key contained in the message encryption key field. Additionally, the blockchain maintainer 904 communicates the public key of the blockchain maintainer in clear text. Further the blockchain maintainer can sign the revocation result message along with the clear text public key, ensuring that the response message can be transmitted confidentially and securely as it is now both confidentiality protected by message encryption key of the institution and integrity protected by the private key of the blockchain maintainer.

[0108] With reference to VC lifecycle management, aspects of the present disclosure include enhanced VC types specific to the telecommunication scenario. To enhance the clarity and functionality of different types of VCs, they are distinguished based on their specific roles within the telecommunication scenarios. This differentiation enables the development of targeted management aspects for each VC type. Furthermore, during the certification issue process, various VCs are aggregated into VPs, which are then utilized to achieve a more robust and secure telecommunications authentication framework. In order to achieve more efficient and flexible identity authentication in telecommunication scenarios, three types of VC are described in aspects of this disclosure, to include a user attribute VC, a payment VC, and an authentication VC.

[0109] A user attribute VC provides proof of a user's basic information signed by authorities. For example, the age, gender, a residence (signed by government) , bills, a deposit (signed by financial department) , and so on. It is generally used when a user first registers or updates the authentication VC with the operator. The management of user attribute VCs follows standard VC management protocols. When authorities detect a mismatch in the user's identity, or if the user has a credit or trustworthiness issue (such as being blacklisted or having a poor credit score) , they have the right to revoke the issued user attribute VC.

[0110] A payment VC acts as a payment credential or use credential that anyone can apply for and purchase. This contract can include a variety of services, including the right to use a private network, a public mobile operator network, third-party services related operator network access, the right to use some businesses, etc. It can be used across different operators, allowing users to apply for services with valid payment VC among different operators. Payment VCs are designed to be non-revocable under most circumstances to protect the user’s payment rights and service entitlements. Once issued, a payment VC acts as a permanent credential, even if the user changes operators or if the service terms evolve. Management strategies should prioritize immutability, meaning that the credential should remain valid for its entire term unless fraudulent activity is detected. Only in exceptional cases of legal or contract breaches should revocation be considered. Additionally, payment VCs need to be easily verifiable across multiple operators, ensuring that services and entitlements are accessible regardless of the user's network or location. This permanence and interoperability are key to maintaining the integrity and usability of payment VCs across diverse ecosystems.

[0111] An authentication VC is a short-term proof of a user’s access to certain network resources. After the first authentication using the user attribute VC and the payment VC, a short-term VC can be issued for direct authentication without providing additional attributes according to the permission and security policies. The authentication VCs are short-lived and are designed for temporary access to network resources or services of one or more operator network’s and / or service access. Due to their nature, their issuance and expiration cycle needs to be highly dynamic. The strategy should enforce frequent renewal of these VCs based on the user’s ongoing access and service needs. Furthermore, the security policies of service providers should dictate stringent monitoring of user behavior. The revocation process should be swift and strict, minimizing the potential for ongoing misuse. The management framework must support automatic reissuance or renewal under proper conditions, ensuring smooth user access while adhering to security protocols.

[0112] Implementations of these new, three types of VCs, a user attribute VC, a payment VC, and an authentication VC, provide several advantages in conjunction with management, efficiency, privacy, and flexibility. With reference to management, separating payment VCs from authentication VCs ensures that, while payment VCs confirm ongoing contractual relationships, authentication VCs can be revoked for issues like payment delinquency, simplifying management. With reference to efficiency, authentication VCs are optimized for quick, lightweight verification, reducing the number of VCs needed and streamlining system processes. With reference to privacy, with authentication VCs containing no sensitive user data and relying on a public key for identity representation, user privacy is strongly protected. With reference to flexibility, the design provides for multiple devices to access the network with a single authentication VC, and payment VCs can be easily transferred between operators, facilitating quick reissuance of authentication VCs during operator switching, thereby enhancing the convenience of roaming. Due to the functional differences of VCs, different VCs have different lifecycle management strategies, which are reflected in the differences in registration, update, and revoke processes.

[0113] Figure 10 illustrates an example of a VC registration procedure 1000 in accordance with aspects of the present disclosure. In this example, the VC registration procedure 1000 facilitates a user 1002 applying for a VC from an issuer 1004 that utilizes a blockchain application 1006. The user 1002 applies for certain types of VC (at 1008) with relevant proof materials, along with its DID. The user 1002 encrypts the proof material using its private key skuser (sk corresponding to the message encryption key) which is designated in the user’s DID document, and sends it together with its DID in plain text. If the user 1002 applies for the user attribute VC, the proof materials may include personal identification, age information, place of birth or residence, sim card registration documents, a subscription proof, mobile network subscription records, a telecom service agreement, mobile number ownership verification, identity documents used for telecom registration, additional supporting documents, etc. If the user 1002 applies for the payment VC, the proof materials may include financial account information, a proof of payment authorization, tax records, other supporting documents, etc. If the user 1002 applies for the authentication VC, the proof materials may include a required user attribute VC, a required payment VC, other supporting documents, etc.

[0114] The issuer 1004 queries the blockchain application 1006 (at 1010) for the DID document of the user 1002 who initiated the request using the accepted DID. The blockchain application 1006 parses and returns the DID document of the user to the issuer 1004 (at 1012) . The issuer 1004 then verifies (at 1014) the legality of the DID document, and then queries the decryption public key pkuser (message encryption key) specified in the DID document. The issuer then uses this public key to decrypt the proof material. The issuer 1004 verifies the proof material (at 1016) , and then formats VCuser containing the corresponding claim, which the user 1002 requires. The issuer 1004 signs the VCuser after the VCuser is created.

[0115] In implementations, a user attribute VC includes one or more information, such as Issued to: DID; Issued by: authorities (relevant telecom operators, government institutions, educational institutions, professional associations, healthcare providers, financial institutions, third-party service providers, vertical service providers) ; Issued based on: materials provided and records in the authority (institutions) ; Claims: user identity, user attributes, etc.; Status: validity period of the user attribute VC; Proof: a hash and / or sign of the user attribute VC data.

[0116] In implementations, a payment VC includes one or more information, such as Issued to:DID; Issued by: service provider (telecom operators, third-party service provider) ; Issued based on: payment record (financial account information, proof of payment authorization, tax records, other supporting documents, etc. ) ; Claims: the total amount of payment, service paid, authorized / subscribed services, duration of the paid service, etc.; Status: validity period of the payment VC; Proof: a hash and / or sign of the payment VC data.

[0117] In implementations, an authentication VC includes one or more information, such as Issued to: DID; Issued by: MNO ID (home PLMN ID e.g., MCC, MNC  / VPLMN ID  / NPN ID) ; Issued based on: User Attribute VC and Payment VC; Claims: subscribed services, allowed access types (3GPP, non-3GPP, satellite access, wireline access) , allowed network slice service information for MNO service access, allowed network slice service information for third-party service access, third-party service specific additional authentication is needed or not; a roaming service is allowed or not) , allowed VPLMN IDs, and / or NPN IDs for roaming services.; Status: validity period of the authentication VC; Proof: a hash and / or sign of the authentication VC data.

[0118] The hash of the signed VCuser, hash (VCuser) is uploaded by the issuer 1004 to the blockchain application 1006 as an unchangeable record (at 1018) . The signed VCuser is securely delivered (at 1020) by the issuer 1004 to the user 1002 by encrypting it with the user's public key pkuser. The user 1002 decrypts (at 1022) the pkuser (VCuser) using their private key skuser to access the VCuser.

[0119] Figure 11 illustrates an example of a VC update procedure 1100 in accordance with aspects of the present disclosure. In this example, the VC update procedure 1100 facilitates a user 1102 applying for an update from an issuer 1104 that utilizes a blockchain application 1106. For example, when an issued VC is outdated, the user 1102 can apply for an update (at 1108) . If the original proof materials have expired, the user 1102 provides updated materials, encrypting them using their private key skuser (sk corresponding to message encryption key) as specified in their DID document, and communicating the encrypted materials along with their DID and the hash of the original VC in plain text. For example, a UE can transmit, to the issuer 1104, an update VC request that includes a DID, the DID document, and / or updated proof information, as well as a cryptographic hash of the user VC (i.e., transmit the DID to assist in retrieving the linked or related DID document stored in any repository or PDL) .

[0120] The issuer 1104 queries (at 1110) the blockchain application 1106 for the DID document of the user who initiated the request using the accepted DID. Additionally, the issuer 1104 queries on the blockchain for the hash of the original VC in order to find if this VC is valid and unchanged. The blockchain application 1106 parses and returns the DID document (at 1112) back to the issuer 1104, and includes an indication as to whether the hash is stored on the blockchain. If the hash of the VC is stored on the blockchain, the issuer 1104 queries (at 1114) the decryption public key pkuser (message encryption key) specified in the DID document. Then the issuer 1104 uses this public key to decrypt the proof material. The issuer 1104 verifies the proof material (at 1116) . If the material is valid, the issuer 1104 updates the expiration date of the VC. The issuer then encrypts the VC using the user’s public key pkuser. The hash of the updated VC, hash (VC’user) , is uploaded by the issuer 1104 (at 1118) to the blockchain application 1106 as an unchangeable record. The hash of the original VC, hash (VCuser) , is marked as invalid on the blockchain. The signed VC’user is securely delivered by the issuer 1104 to the user 1102 (at 1120) by encrypting it with the user's public key pkuser. The user 1102 decrypts the pkuser (VC’user) (at 1122) using their private key skuser to access the VC’user.

[0121] Figure 12 illustrates an example of a VC revocation procedure 1200 in accordance with aspects of the present disclosure. In this example, the VC revocation procedure 1200 facilitates a user 1202 being notified that a VC is revoked by an issuer 1204 that utilizes a blockchain application 1206. For example, when a signed VC needs to be revoked for any reason, the issuer 1204 can start the revocation process (at 1208) . However, revoking a payment VC is not recommended. Even if the payment is incomplete, the payment VC remains valid as it only confirms that the user has made a payment. Instead, if the user engages in illegal activity, the issuer should revoke the authentication VC to stop providing services to the user. In this procedure, the issuer 1204 calculates the hash of the VC being revoked (at 1210) , and informs the blockchain application 1206 that this VC is revoked.

[0122] The revocation reason should also be recorded on the blockchain for a record for other service providers to query if the user being revoked applies for other services. For the issuer 1204 revoking a user attribute VC, the reason can be for incorrect or outdated user information, fraudulent or misrepresented identity claims, and / or violations of terms and conditions associated with the attributes. For the issuer 1204 revoking a payment VC, the reason can be for a user’s payment reversal, or involvement in illegal financial activities. For the issuer 1204 revoking an authentication VC, the reason can be for illegal activities, violation of service policies, compromised credentials, and / or a breach of trust in authentication practices.

[0123] The issuer 1204 forms a notification for the user 1202 (at 1212) , including the revoked VC and the revocation reason, and signs the notification using the user’s public key pkuser. (message encryption key) . The notification is securely delivered to the user 1202 (at 1214) . The user 1202 then decrypts the notification using their private key skuser (sk corresponding to message encryption key) to access it.

[0124] With reference to DID and VC verification procedures for authentication, aspects of the present disclosure consider that after obtaining a valid DID or VC, the holder needs to present the certificate or DID to a verifier (i.e., an authentication function at the network) for recognition, such as to perform authentication to allow requested services and access to the network. In this context, an effective and secure verification scheme provides for reliable interactions between network entities. It is to be noted that DID verification and VC verification may be performed separately or in one common procedure.

[0125] Figure 13 illustrates an example of a DID verification-based authentication procedure 1300 in accordance with aspects of the present disclosure. In this example of the DID verification-based authentication procedure 1300, an entity 1302 (e.g., a user) seeks to prove ownership with a verifier 1304 that utilizes a blockchain application 1306. In implementations, the verifier 1304 can be an authentication function in the network, and resides either in the RAN or core network domain in the operator network. In this example, the entity 1302 initiates an identity authentication request (at 1308) by sending a message containing its DID and identifier of the UE to the network verifier 1304. Alternatively, the identity of a UE can be encrypted and signed along with the DID plain text by the private key that is associated to the authentication Key associated to the DID to ensure confidentiality and integrity of the UE identifier, and to ensure integrity protection for the DID.

[0126] The verifier 1304 requests (at 1310) the blockchain application 1306 to parse the DID, ensuring that the DID is registered on the chain. The blockchain application 1306 returns the parsed result to the verifier (at 1312) . If the DID is valid, the blockchain application returns the corresponding DID document. However, if the DID is invalid or does not exist on blockchain, the blockchain application returns a revocation or an error. The verifier 1304 checks (at 1314) as to whether the entity association identifiers field in the DID document of the entity includes an identifier of a UE to ensure the entity uses a valid device to access service. Additionally, if the verifier 1304 receives a protected user equipment identifier, the verifier uses the public key (i.e., the authentication Key associated to the DID) to verify the signed UE identifier, and if the signature verification is successful, the verifier 1304 checks as to whether the entity association identifiers field in the DID document of the entity includes the identifier of UE to ensure that the entity uses the valid device to access service.

[0127] The verifier 1304 selects an integrity algorithm that is listed in both the DID document of the verifier and the DID document of the entity, and similarly selects a ciphering algorithm supported by both documents. The verifier 1304 then sends a challenge request to the entity 1302 (at 1316) . The challenge request message contains the selected integrity algorithm, the selected ciphering algorithm, and a random nonce encrypted with the pkentity specified by the ciphering algorithm. This challenge request message is integrity-protected by the signature, which is generated by encrypting a hash value of the message. Specifically, the verifier 1304 signs the message with skverifier indicated by the selected integrity algorithm. This signature not only ensures the integrity of the message, but also authenticates the verifier’s identity.

[0128] The DID document lists the set of integrity and confidentiality protection algorithms supported by both the entity and the verifier. The verifier 1304 selects and indicates one ciphering protection algorithm and one integrity protection algorithm that are mutually supported by both the DID document of the entity and the DID document of the verifier. These algorithms are used for message and / or challenge-response verifications during mutual authentication. The entity 1302 requests the blockchain application 1306 (at 1318) to parse the DID, ensuring that the DID is registered on the blockchain. The blockchain application 1306 returns the parsed result (at 1320) .

[0129] The entity 1302 retrieves (at 1322) the integrity protection algorithm selected by the verifier 1304, and then uses the corresponding pkverifier to verify the correctness of the signature. The signature is decrypted to obtain the hash value of the message. The entity 1302 compares this decrypted hash value with the hash value it has computed to ensure that the data has not been tampered with during transmission. Then, the entity 1302 uses the skentity. corresponding to the encryption algorithm selected by the verifier 1304 to decrypt the random nonce. The entity 1302 communicates the response message (at 1324) to the verifier 1304 ciphered and integrity protected. Similarly, the response message includes the selected integrity algorithm, the selected ciphering algorithm, and a random nonce encrypted with the pkverifier specified by ciphering algorithm. The verifier 1304 verifies the signature (at 1326) and checks the integrity of the response message. The verifier 1304 then compares the nonce sent to the entity 1302 with the one received, and if they match, it confirms that the entity is the legitimate owner of the DID. If all of the authentication steps are successfully completed, the verifier 1304 communicates an authentication success response (at 1328) to the entity 1302. Otherwise, the verifier 1304 communicates an authentication failure response.

[0130] The challenge-response mechanism enhances security by ensuring that the entity can only authenticate if it correctly responds to a specific challenge issued by the network. The interaction between the entity and the network verifier is streamlined and direct, making the process of identity authentication more efficient. As the number of users increases, the simplicity and efficiency of the challenge-response process means that it can handle a larger number of authentication requests without significantly increasing the load on the network.

[0131] With reference to a VC verification procedure, aspects of the present disclosure provide that data derived from one or more VCs, issued by one or more issuers, can be shared with a specific verifier. Typically, these VCs are combined into a VP for the verifier. A VP expresses data from one or more VCs and is packaged in such a way that the authorship of the data can be trusted after undergoing cryptographic verification. For example, a user requests to access a telecom network service by sending the VP generated from the authentication VC with the identifier of its DID to a verifier. The network checks whether or not the user satisfies the requirements to access the network by verifying the provided credentials, which can be considered as an authorization verification as well. Certain types of VPs may enable selective disclosure, where only the necessary fields of the original VC are revealed in plaintext, while the rest of the information remains encrypted (e.g., a hash value) . The registration procedure of a VC that supports selective disclosure requires an additional step. When the issuer generates the VC, each field in the claim is computed to generate a hash value. The hash values of each field in the claim are concatenated to form a string, claim_hash, which is then filled into the VC.

[0132] Figure 14 illustrates an example of a VC verification procedure 1400 in accordance with aspects of the present disclosure. In this example of the VC verification procedure 1400, an entity 1402 verifies one or more VCs with a verifier 1404 that utilizes a blockchain application 1406. In this example, the entity 1402 generates the VP (at 1408) . The entity has the flexibility to choose which information from the underlying VCs to include in the VP, with this information reflected in the claim field. The properties in claims refer to one or more VCs, which are embedded in the VC data. Similar to VCs, the VP also contains proofs, and the proof is signed with cryptographic keys. The main distinction between them is that the VP is signed with the holder's cryptographic keys (e.g., private key related to the authentication key that is included in the DID document) to prove ownership, and the VC is signed with the issuer’s private key.

[0133] In implementations, a VP can include one or more information, such as Hold by: DID; Claims: user identity, user attributes, allowed access types, allowed network slice service information for MNO service access, allowed network slice service information for third-party service access, third-party service specific additional authentication is needed or not, roaming service (allowed or not) , allowed VPLMN IDs and / or NPN IDs for roaming service, etc.; VC data: aggregation of VCs used to prove the claimed data along with the respective VC issuer’s DID for each VC; Status: a validity period of the VP; Proof: a hash and / or sign of the VP data. Optionally, the entity 1402 uses selective disclosure and selects the set of fields to be disclosed (it can be one or several fields) . The fields to be disclosed provide the original text, and the other fields provide the hash value.

[0134] The entity 1402 communicates (at 1410) the VP authentication request containing VPentity and DIDentity to the verifier 1404. The verifier 1404 obtains the DIDissuer of the issuer of VCs contained in the VPentity, and then (at 1412) requests the blockchain application 1406 to resolve the DIDentity and DIDissuer. The blockchain application 1406 returns (at 1414) the matched DID_Documententity and DID_Documentissuer. The verifier 1404 searches the proof field of VPentity for which algorithm is used for signature. The verifier then uses the public key pkentity corresponding to the signed algorithm to verify the proof, and the pkentity is specified in the DID_Documententity. The verifier 1404 examines the proof field of VCs contained in the VPentity to determine the signature algorithms used for each VC. Then, the verifier 1404 uses the public key pkissuer corresponding to the sign algorithm to verify the proof. The pkissuer is specified in the DID_Documentissuer. The verifier 1404 checks (at 1416) whether the claim aligns with the content of VC. In cases where the VP is selectively disclosed, the verifier shall check the claim’s hash. The verifier 1404 extracts the disclosed claim fields from the VC. Next, the verifier computes the hash for each disclosed field and concatenates these hash values with those of the undisclosed fields to form a composite string claim_hash’. The validity of the claim is verified by comparing the hash recorded in the VC with the computed claim_hash’.

[0135] The verifier 1404 requests (at 1418) the blockchain application 1406 to check as to whether if the VC has been revoked. The online certificate status protocol (OCSP) server, integrated on the blockchain, queries the current status of the VC, and returns the Statusvc to the verifier (at 1420) . In this process, the OCSP service is integrated as a blockchain component with access to a list of VC revocations stored on the blockchain to retrieve details of each VC. The issuer maintains control over the VC revocation list, which is securely stored on the blockchain. By maintaining the OCSP service on-chain, the verifier can efficiently determine whether a certificate is still valid. The OCSP operates using a real-time response mechanism, ensuring that the verifier receives the most up-to-date and accurate information. The verifier 1404 then sends an authentication response (at 1422) to the entity 1402. If the authentication is success, the entity will be able to access the service.

[0136] Figure 15 illustrates an example of a UE 1500 in accordance with aspects of the present disclosure. The UE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0137] The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0138] The processor 1502 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 1502 may be configured to operate the memory 1504. In some other implementations, the memory 1504 may be integrated into the processor 1502. The processor 1502 may be configured to execute computer-readable instructions stored in the memory 1504 to cause the UE 1500 to perform various functions of the present disclosure.

[0139] The memory 1504 may include volatile or non-volatile memory. The memory 1504 may store computer-readable, computer-executable code including instructions when executed by the processor 1502 cause the UE 1500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 1504 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0140] In some implementations, the processor 1502 and the memory 1504 coupled with the processor 1502 may be configured to or operable to cause the UE 1500 to perform one or more of the functions described herein (e.g., executing, by the processor 1502, instructions stored in the memory 1504) . For example, the processor 1502 may support wireless communication at the UE 1500 in accordance with examples as disclosed herein. The UE 1500 may be configured to or operable to support a means for transmitting an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receiving an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0141] Additionally, the UE 1500 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The method including receiving, from the authentication function, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and transmitting, to the authentication function, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0142] Additionally, or alternatively, the UE 1500 may support at least one memory (e.g., the memory 1504) and at least one processor (e.g., the processor 1502) coupled with the at least one memory and configured to or operable to cause the UE to transmit an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receive an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0143] Additionally, the UE 1500 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The at least one processor is operable to cause the UE to receive, from the authentication function, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and transmit, to the authentication function, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0144] The controller 1506 may manage input and output signals for the UE 1500. The controller 1506 may also manage peripherals not integrated into the UE 1500. In some implementations, the controller 1506 may utilize an operating system such as  or other operating systems. In some implementations, the controller 1506 may be implemented as part of the processor 1502.

[0145] In some implementations, the UE 1500 may include at least one transceiver 1508. In some other implementations, the UE 1500 may have more than one transceiver 1508. The transceiver 1508 may represent a wireless transceiver. The transceiver 1508 may include one or more receiver chains 1510, one or more transmitter chains 1512, or a combination thereof.

[0146] A receiver chain 1510 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1510 may include one or more antennas to receive a signal over the air or wireless medium. The receiver chain 1510 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 1510 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1510 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0147] A transmitter chain 1512 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 1512 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 1512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0148] Figure 16 illustrates an example of a processor 1600 in accordance with aspects of the present disclosure. The processor 1600 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1600 may include a controller 1602 configured to perform various operations in accordance with examples as described herein. The processor 1600 may optionally include at least one memory 1604, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1600 may optionally include one or more arithmetic-logic units (ALUs) 1606. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses) .

[0149] The processor 1600 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1600) or other memory (e.g., random access memory (RAM) , read-only memory (ROM) , dynamic RAM (DRAM) , synchronous dynamic RAM (SDRAM) , static RAM (SRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , flash memory, phase change memory (PCM) , and others) .

[0150] The controller 1602 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1600 to cause the processor 1600 to support various operations in accordance with examples as described herein. For example, the controller 1602 may operate as a control unit of the processor 1600, generating control signals that manage the operation of various components of the processor 1600. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0151] The controller 1602 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1604 and determine subsequent instruction (s) to be executed to cause the processor 1600 to support various operations in accordance with examples as described herein. The controller 1602 may be configured to track memory addresses of instructions associated with the memory 1604. The controller 1602 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1602 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1600 to cause the processor 1600 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1602 may be configured to manage flow of data within the processor 1600. The controller 1602 may be configured to control transfer of data between registers, ALUs 1606, and other functional units of the processor 1600.

[0152] The memory 1604 may include one or more caches (e.g., memory local to or included in the processor 1600 or other memory, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1604 may reside within or on a processor chipset (e.g., local to the processor 1600) . In some other implementations, the memory 1604 may reside external to the processor chipset (e.g., remote to the processor 1600) .

[0153] The memory 1604 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1600, cause the processor 1600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1602 and / or the processor 1600 may be configured to execute computer-readable instructions stored in the memory 1604 to cause the processor 1600 to perform various functions. For example, the processor 1600 and / or the controller 1602 may be coupled with or to the memory 1604, the processor 1600, and the controller 1602, and may be configured to perform various functions described herein. In some examples, the processor 1600 may include multiple processors and the memory 1604 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0154] The one or more ALUs 1606 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1606 may reside within or on a processor chipset (e.g., the processor 1600) . In some other implementations, the one or more ALUs 1606 may reside external to the processor chipset (e.g., the processor 1600) . One or more ALUs 1606 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1606 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1606 may be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1606 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 1606 to handle conditional operations, comparisons, and bitwise operations.

[0155] The processor 1600 may support wireless communication in accordance with examples as disclosed herein. The processor 1600 may be configured to or operable to support at least one controller (e.g., the controller 1602) coupled with at least one memory (e.g., the memory 1604) and configured to or operable to cause the processor to transmit an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; and receive an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0156] Additionally, the processor 1600 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The at least one controller is operable to cause the processor to receive, from the authentication function, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and transmit, to the authentication function, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0157] The processor 1600 may support wireless communication in accordance with examples as disclosed herein. The processor 1600 may be configured to or operable to support at least one controller (e.g., the controller 1602) coupled with at least one memory (e.g., the memory 1604) and configured to or operable to cause the processor to receive, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmit, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0158] Additionally, the processor 1600 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The at least one controller is operable to cause the processor to transmit, to the UE, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and receive, from the UE, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0159] The processor 1600 may support wireless communication in accordance with examples as disclosed herein. The processor 1600 may be configured to or operable to support at least one controller (e.g., the controller 1602) coupled with at least one memory (e.g., the memory 1604) and configured to or operable to cause the processor to receive, from a network entity, a DID registration request that includes a DID document of DID information, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document; and transmit, to the network entity, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0160] Additionally, the processor 1600 may be configured to or operable to support any one or combination of the entity type of the network entity is a UE, and the DID registration request is for the UE or an individual user of the UE. The at least one controller is operable to cause the processor to request blockchain verification and storage of the DID document; and receive a success response based on the blockchain verification and the storage of the DID document. The entity type of the network entity is at least one of an operator network, a network device, or a third-party entity configured to interface with one or more network entities. The at least one controller is operable to cause the processor to request a blockchain verification of the DID document; receive a success response based on the blockchain verification; request a blockchain storage of the DID document; and receive a storage receipt based on the storage of the DID document. The at least one controller is operable to cause the processor to receive, from the network entity, a DID update request that includes an updated DID document; and use a recovery key in the DID document to verify the updated DID document. The at least one controller is operable to cause the processor to receive, from the network entity, a DID revocation request; and use a recovery key in the DID document to verify the DID revocation request.

[0161] The processor 1600 may support wireless communication in accordance with examples as disclosed herein. The processor 1600 may be configured to or operable to support at least one controller (e.g., the controller 1602) coupled with at least one memory (e.g., the memory 1604) and configured to or operable to cause the processor to compose DID information in a DID document for a digital identity of a network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

[0162] Additionally, the processor 1600 may be configured to or operable to support any one or combination of the network entity is at least one of a UE or a NE. The entity type of the UE is configured to support digital identities of the one or more secondary entities associated with the UE. The entity type of the NE is at least one of an operator network, end-user equipment, or a network device, and the entity type of the NE is configured to support a digital identity of a secondary entity associated with the NE. The entity type of the NE is a third-party entity configured to interface with one or more network entities, and the entity type of the NE is configured to support digital identities of the one or more secondary entities associated with the NE. The DID information includes a VC proof of the entity type. A public key use of the one or more public key uses includes the public key usable as at least one of an authentication key, a recovery key, a message encryption key, or and integrity protection key. The network entity is a UE and the at least one controller is operable to cause the processor to transmit, to a blockchain maintainer, a DID registration request for at least one of the UE or an individual user, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The network entity is a NE and the at least one controller is operable to cause the processor to transmit, to a blockchain maintainer, a DID registration request for at least one of an operator network, a network device, or a third-party entity, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The at least one controller is operable to cause the processor to transmit, to a blockchain maintainer, a DID update request that includes an updated DID document, the blockchain maintainer configured to use a recovery key in the DID document to verify the updated DID document. The at least one controller is operable to cause the processor to transmit, to a blockchain maintainer, a DID revocation request, the blockchain maintainer configured to use a recovery key in the DID document to verify the DID revocation request.

[0163] Figure 17 illustrates an example of a NE 1700 in accordance with aspects of the present disclosure. The NE 1700 may include a processor 1702, a memory 1704, a controller 1706, and a transceiver 1708. The processor 1702, the memory 1704, the controller 1706, or the transceiver 1708, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0164] The processor 1702, the memory 1704, the controller 1706, or the transceiver 1708, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0165] The processor 1702 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 1702 may be configured to operate the memory 1704. In some other implementations, the memory 1704 may be integrated into the processor 1702. The processor 1702 may be configured to execute computer-readable instructions stored in the memory 1704 to cause the NE 1700 to perform various functions of the present disclosure.

[0166] The memory 1704 may include volatile or non-volatile memory. The memory 1704 may store computer-readable, computer-executable code including instructions when executed by the processor 1702 cause the NE 1700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 1704 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0167] In some implementations, the processor 1702 and the memory 1704 coupled with the processor 1702 may be configured to or operable to cause the NE 1700 to perform one or more of the functions described herein (e.g., executing, by the processor 1702, instructions stored in the memory 1704) . For example, the processor 1702 may support wireless communication at the NE 1700 in accordance with examples as disclosed herein. The NE 1700 may be configured to or operable to support a means for receiving, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmitting, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0168] Additionally, the NE 1700 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The method including transmitting, to the UE, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and receiving, from the UE, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0169] Additionally, or alternatively, the NE 1700 may support at least one memory (e.g., the memory 1704) and at least one processor (e.g., the processor 1702) coupled with the at least one memory and configured to or operable to cause the NE to receive, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid; and transmit, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC.

[0170] Additionally, the NE 1700 may be configured to or operable to support any one or combination of the authentication request includes the DID document and an identity of the UE, where the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document. The at least one processor is operable to cause the NE to transmit, to the UE, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document (i.e., of the network or the authentication function) ; and receive, from the UE, a challenge response that verifies the UE ownership of the DID document of the UE. The authentication request includes a VP of one or more VCs, where the VP is encrypted and signed with a private key that is associated to an authentication key.

[0171] In some implementations, the processor 1702 and the memory 1704 coupled with the processor 1702 may be configured to or operable to cause the NE 1700 to perform one or more of the functions described herein (e.g., executing, by the processor 1702, instructions stored in the memory 1704) . For example, the processor 1702 may support wireless communication at the NE 1700 in accordance with examples as disclosed herein. The NE 1700 may be configured to or operable to support a means for receiving, from a network entity, a DID registration request that includes a DID document of DID information, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document; and transmitting, to the network entity, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0172] Additionally, the NE 1700 may be configured to or operable to support any one or combination of the entity type of the network entity is a UE, and the DID registration request is for the UE or an individual user of the UE. The method including requesting blockchain verification and storage of the DID document; and receiving a success response based on the blockchain verification and the storage of the DID document. The entity type of the network entity is at least one of an operator network, a network device, or a third-party entity configured to interface with one or more network entities. The method including requesting a blockchain verification of the DID document; receiving a success response based on the blockchain verification; requesting a blockchain storage of the DID document; and receiving a storage receipt based on the storage of the DID document. The method including receiving, from the network entity, a DID update request that includes an updated DID document; and using a recovery key in the DID document to verify the updated DID document. The method including receiving, from the network entity, a DID revocation request; and using a recovery key in the DID document to verify the DID revocation request.

[0173] Additionally, or alternatively, the NE 1700 may support at least one memory (e.g., the memory 1704) and at least one processor (e.g., the processor 1702) coupled with the at least one memory and configured to or operable to cause the NE to receive, from a network entity, a DID registration request that includes a DID document of DID information, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document; and transmit, to the network entity, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0174] Additionally, the NE 1700 may be configured to or operable to support any one or combination of the entity type of the network entity is a UE, and the DID registration request is for the UE or an individual user of the UE. The at least one processor is operable to cause the NE to request blockchain verification and storage of the DID document; and receive a success response based on the blockchain verification and the storage of the DID document. The entity type of the network entity is at least one of an operator network, a network device, or a third-party entity configured to interface with one or more network entities. The at least one processor is operable to cause the NE to request a blockchain verification of the DID document; receive a success response based on the blockchain verification; request a blockchain storage of the DID document; and receive a storage receipt based on the storage of the DID document. The at least one processor is operable to cause the NE to receive, from the network entity, a DID update request that includes an updated DID document; and use a recovery key in the DID document to verify the updated DID document. The at least one processor is operable to cause the NE to receive, from the network entity, a DID revocation request; and use a recovery key in the DID document to verify the DID revocation request.

[0175] The controller 1706 may manage input and output signals for the NE 1700. The controller 1706 may also manage peripherals not integrated into the NE 1700. In some implementations, the controller 1706 may utilize an operating system such as  or other operating systems. In some implementations, the controller 1706 may be implemented as part of the processor 1702.

[0176] In some implementations, the NE 1700 may include at least one transceiver 1708. In some other implementations, the NE 1700 may have more than one transceiver 1708. The transceiver 1708 may represent a wireless transceiver. The transceiver 1708 may include one or more receiver chains 1710, one or more transmitter chains 1712, or a combination thereof.

[0177] A receiver chain 1710 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1710 may include one or more antennas to receive a signal over the air or wireless medium. The receiver chain 1710 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 1710 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1710 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0178] A transmitter chain 1712 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 1712 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 1712 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1712 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0179] Figure 18 illustrates an example of a network entity 1800 in accordance with aspects of the present disclosure. In one or more implementations, the network entity 1800 may include a UE or an NE, such as an operator network, network device, network infrastructure device, third-party service provider, or organization. The network entity 1800 may include a processor 1802, a memory 1804, a controller 1806, and a transceiver 1808. The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0180] The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0181] The processor 1802 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 1802 may be configured to operate the memory 1804. In some other implementations, the memory 1804 may be integrated into the processor 1802. The processor 1802 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the network entity 1800 to perform various functions of the present disclosure.

[0182] The memory 1804 may include volatile or non-volatile memory. The memory 1804 may store computer-readable, computer-executable code including instructions when executed by the processor 1802 cause the network entity 1800 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 1804 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0183] In some implementations, the processor 1802 and the memory 1804 coupled with the processor 1802 may be configured to or operable to cause the network entity 1800 to perform one or more of the functions described herein (e.g., executing, by the processor 1802, instructions stored in the memory 1804) . For example, the processor 1802 may support wireless communication at the network entity 1800 in accordance with examples as disclosed herein. The network entity 1800 may be configured to or operable to support a means for composing DID information in a DID document for a digital identity of the network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document; transmitting, to a blockchain maintainer, a DID registration request that includes the DID document; and receiving, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.

[0184] Additionally, the network entity 1800 may be configured to or operable to support any one or combination of the network entity is at least one of a UE or a NE. The entity type of the UE is configured to support digital identities of the one or more secondary entities associated with the UE. The entity type of the NE is at least one of an operator network, end-user equipment, or a network device, and the entity type of the NE is configured to support a digital identity of a secondary entity associated with the NE. The entity type of the NE is a third-party entity configured to interface with one or more network entities, and the entity type of the NE is configured to support digital identities of the one or more secondary entities associated with the NE. The DID information includes a VC proof of the entity type. A public key use of the one or more public key uses includes the public key usable as at least one of an authentication key, a recovery key, a message encryption key, or and integrity protection key. The network entity is a UE and the method including transmitting, to a blockchain maintainer, a DID registration request for at least one of the UE or an individual user, where the DID registration request includes the DID document; and receiving, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The network entity is a NE and the method including transmitting, to a blockchain maintainer, a DID registration request for at least one of an operator network, a network device, or a third-party entity, where the DID registration request includes the DID document; and receiving, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The method including transmitting, to a blockchain maintainer, a DID update request that includes an updated DID document, the blockchain maintainer configured to use a recovery key in the DID document to verify the updated DID document. The method including transmitting, to a blockchain maintainer, a DID revocation request, the blockchain maintainer configured to use a recovery key in the DID document to verify the DID revocation request.

[0185] Additionally, or alternatively, the network entity 1800 may support at least one memory (e.g., the memory 1804) and at least one processor (e.g., the processor 1802) coupled with the at least one memory and configured to or operable to cause the network entity to compose DID information in a DID document for a digital identity of the network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document.

[0186] Additionally, the network entity 1800 may be configured to or operable to support any one or combination of the network entity is at least one of a UE or a NE. The entity type of the UE is configured to support digital identities of the one or more secondary entities associated with the UE. The entity type of the NE is at least one of an operator network, end-user equipment, or a network device, and the entity type of the NE is configured to support a digital identity of a secondary entity associated with the NE. The entity type of the NE is a third-party entity configured to interface with one or more network entities, and the entity type of the NE is configured to support digital identities of the one or more secondary entities associated with the NE. The DID information includes a VC proof of the entity type. A public key use of the one or more public key uses includes the public key usable as at least one of an authentication key, a recovery key, a message encryption key, or and integrity protection key. The network entity is a UE and the at least one processor is operable to cause the UE to transmit, to a blockchain maintainer, a DID registration request for at least one of the UE or an individual user, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The network entity is a NE and the at least one processor is operable to cause the NE to transmit, to a blockchain maintainer, a DID registration request for at least one of an operator network, a network device, or a third-party entity, where the DID registration request includes the DID document; and receive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The at least one processor is configured to cause the network entity to transmit, to a blockchain maintainer, a DID update request that includes an updated DID document, the blockchain maintainer configured to use a recovery key in the DID document to verify the updated DID document. The at least one processor is configured to cause the network entity to transmit, to a blockchain maintainer, a DID revocation request, the blockchain maintainer configured to use a recovery key in the DID document to verify the DID revocation request.

[0187] The controller 1806 may manage input and output signals for the network entity 1800. The controller 1806 may also manage peripherals not integrated into the network entity 1800. In some implementations, the controller 1806 may utilize an operating system such as  or other operating systems. In some implementations, the controller 1806 may be implemented as part of the processor 1802.

[0188] In some implementations, the network entity 1800 may include at least one transceiver 1808. In some other implementations, the network entity 1800 may have more than one transceiver 1808. The transceiver 1808 may represent a wireless transceiver. The transceiver 1808 may include one or more receiver chains 1810, one or more transmitter chains 1812, or a combination thereof.

[0189] A receiver chain 1810 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1810 may include one or more antennas to receive a signal over the air or wireless medium. The receiver chain 1810 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 1810 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1810 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0190] A transmitter chain 1812 may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmitter chain 1812 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 1812 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1812 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0191] Figure 19 illustrates a flowchart of a method 1900 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0192] At 1902, the method may include transmitting an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid. The operations of 1902 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1902 may be performed by a UE as described with reference to Figure 15.

[0193] At 1904, the method may include receiving an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC. The operations of 1904 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1904 may be performed by a UE as described with reference to Figure 15.

[0194] Figure 20 illustrates a flowchart of a method 2000 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0195] At 2002, the method may include receiving, from a UE, an authentication request for blockchain verification, the authentication request including at least one of a DID document or a VC usable to verify at least one of UE ownership of the DID document or that the VC is valid. The operations of 2002 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2002 may be performed by a NE as described with reference to Figure 17.

[0196] At 2004, the method may include transmitting, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based on at least one of the DID document or the VC. The operations of 2004 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2004 may be performed by a NE as described with reference to Figure 17.

[0197] Figure 21 illustrates a flowchart of a method 2100 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0198] At 2102, the method may include receiving, from a network entity, a DID registration request that includes a DID document of DID information, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document. The operations of 2102 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2102 may be performed by a NE as described with reference to Figure 17.

[0199] At 2104, the method may include transmitting, to the network entity, an encrypted registration response that is encrypted using a public key of the one or more public keys. The operations of 2104 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2104 may be performed by a NE as described with reference to Figure 17.

[0200] Figure 22 illustrates a flowchart of a method 2200 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a network entity as described herein. In some implementations, the network entity may execute a set of instructions to control the function elements of the network entity to perform the described functions. It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0201] At 2202, the method may include composing DID information in a DID document for a digital identity of the network entity, the DID information including one or more of an entity type of the network entity; one or more entity association identifiers of respective one or more secondary entities associated with the network entity; or one or more public key uses of respective one or more public keys indicated in a public key list in the DID document. The operations of 2202 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2202 may be performed by a network entity as described with reference to Figure 18.

[0202] At 2204, the method may include transmitting, to a blockchain maintainer, a DID registration request that includes the DID document. The operations of 2204 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2204 may be performed by a network entity as described with reference to Figure 18.

[0203] At 2206, the method may include receiving, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys. The operations of 2206 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2206 may be performed a network entity as described with reference to Figure 18.

[0204] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1.A network entity for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and operable to cause the network entity to:compose decentralized identifier (DID) information in a DID document for a digital identity of the network entity, the DID information including one or more of:an entity type of the network entity;one or more entity association identifiers of respective one or more secondary entities associated with the network entity; orone or more public key uses of respective one or more public keys indicated in a public key list in the DID document.2.The network entity of claim 1, wherein the network entity is at least one of a user equipment (UE) or a network equipment (NE) .3.The network entity of claim 2, wherein the entity type of the UE is configured to support digital identities of the one or more secondary entities associated with the UE.4.The network entity of claim 2, wherein the entity type of the NE is at least one of an operator network, end-user equipment, or a network device, and the entity type of the NE is configured to support a digital identity of a secondary entity associated with the NE.5.The network entity of claim 2, wherein the entity type of the NE is a third-party entity configured to interface with one or more network entities, and the entity type of the NE is configured to support digital identities of the one or more secondary entities associated with the NE.6.The network entity of claim 2, wherein the DID information includes a verifiable credential (VC) proof of the entity type.7.The network entity of claim 1, wherein a public key use of the one or more public key uses includes the public key usable as at least one of an authentication key, a recovery key, a message encryption key, or and integrity protection key.8.The network entity of claim 1, wherein the network entity is a user equipment (UE) and the at least one processor is operable to cause the UE to:transmit, to a blockchain maintainer, a DID registration request for at least one of the UE or an individual user, wherein the DID registration request includes the DID document; andreceive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.9.The network entity of claim 1, wherein the network entity is a network equipment (NE) and the at least one processor is operable to cause the NE to:transmit, to a blockchain maintainer, a DID registration request for at least one of an operator network, a network device, or a third-party entity, wherein the DID registration request includes the DID document; andreceive, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.10.The network entity of claim 1, wherein the at least one processor is configured to cause the network entity to transmit, to a blockchain maintainer, a DID update request that includes an updated DID document, the blockchain maintainer configured to use a recovery key in the DID document to verify the updated DID document.11.The network entity of claim 1, wherein the at least one processor is configured to cause the network entity to transmit, to a blockchain maintainer, a DID revocation request, the blockchain maintainer configured to use a recovery key in the DID document to verify the DID revocation request.12.A method performed by a network entity, the method comprising:composing decentralized identifier (DID) information in a DID document for a digital identity of the network entity, the DID information including one or more of:an entity type of the network entity;one or more entity association identifiers of respective one or more secondary entities associated with the network entity; orone or more public key uses of respective one or more public keys indicated in a public key list in the DID document;transmitting, to a blockchain maintainer, a DID registration request that includes the DID document; andreceiving, from the blockchain maintainer, an encrypted registration response that is encrypted using a public key of the one or more public keys.13.A user equipment (UE) for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and operable to cause the UE to:transmit an authentication request for blockchain verification, the authentication request including at least one of a decentralized identifier (DID) document or a verifiable credential (VC) usable by an authentication function to verify at least one of UE ownership of the DID document or that the VC is valid; andreceive an authentication response that indicates at least one of authentication success or authentication failure based at least in part on at least one of the DID document or the VC.14.The UE of claim 13, wherein the authentication request includes the DID document and an identity of the UE, wherein the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document.15.The UE of claim 13, wherein the at least one processor is operable to cause the UE to:receive, from the authentication function, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document; andtransmit, to the authentication function, a challenge response that verifies the UE ownership of the DID document of the UE.16.The UE of claim 13, wherein the authentication request includes a verifiable presentation (VP) of one or more VCs, wherein the VP is encrypted and signed with a private key that is associated to an authentication key.17.A network equipment (NE) for wireless communication, comprising:at least one memory; andat least one processor coupled with the at least one memory and operable to cause the NE to:receive, from a user equipment (UE) , an authentication request for blockchain verification, the authentication request including at least one of a decentralized identifier (DID) document or a verifiable credential (VC) usable to verify at least one of UE ownership of the DID document or that the VC is valid; andtransmit, to the UE, an authentication response that indicates at least one of authentication success or authentication failure based at least in part on at least one of the DID document or the VC.18.The NE of claim 17, wherein the authentication request includes the DID document and an identity of the UE, wherein the identity is encrypted and signed with a private key that is associated to an authentication key included in the DID document.19.The NE of claim 17, wherein the at least one processor is operable to cause the NE to:transmit, to the UE, a challenge request that includes a random nonce encrypted with a public key of the UE, and includes a ciphering protection algorithm and an integrity protection algorithm that are supported by the DID document; andreceive, from the UE, a challenge response that verifies the UE ownership of the DID document of the UE.20.The NE of claim 17, wherein the authentication request includes a verifiable presentation (VP) of one or more VCs, wherein the VP is encrypted and signed with a private key that is associated to an authentication key.

Images