Digital identity management

Abstract

Aspects of the disclosure relate to methods, apparatuses, and systems for supporting digital identity management. For example, implementations provide for license distributed ledger (PDL) services and associated message exchanges and operations. For example, a decentralized identifier (DID) document registry service is provided to enable management of a DID, such as for actions including creation / storage, update, deletion / revocation, etc. for the DID. Furthermore, a verifiable credential (VC) data registry service is provided to enable management of the VC, such as for actions including creation / storage, update, deletion / revocation, etc. for the VC.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application Serial No. 63 / 408,627, filed on September 21, 2022, entitled “DIGITAL IDENTITY MANAGEMENT,” the disclosure of which is incorporated herein by reference in its entirety. This application also claims priority to U.S. Provisional Application Serial No. 63 / 408,639, filed on September 21, 2022, entitled “REGISTRATION HANDLING OF LEDGER-BASED IDENTITY,” the disclosure of which is incorporated herein by reference in its entirety. This application also claims priority to U.S. Provisional Application Serial No. 63 / 408,645, filed on September 21, 2022, entitled “DECENTRALIZED IDENTITY AUTHENTICATION AND AUTHORIZATION,” the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to wireless communications and, more particularly, to identity management. Background Art

[0004] A wireless communication system may include one or more network communication devices (such as base stations), which may also be referred to as eNodeB (eNB), next generation NodeB (gNB) or other suitable terms. Each network communication device (such as a base station) may support wireless communication for one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. A wireless communication system may support wireless communication with one or more user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers). In addition, a wireless communication system may support wireless communication across various radio access technologies, including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, and other suitable radio access technologies other than 5G (e.g., sixth generation (6G)).

[0005] Some wireless communication systems provide means for managing identities, such as for authentication and authorization purposes. However, such systems exhibit a number of disadvantages, such as those associated with supporting digital identities (eg, decentralized identities) and trust management processes. Summary of the invention

[0006] The present disclosure relates to methods, devices and systems for supporting digital identity management. For example, implementations provide permissioned distributed ledger (PDL) services and associated message exchanges and operations. For example, decentralized identifier (DID) document registry services are provided to enable management of DIDs, such as for actions including creation / storage, update, deletion / revocation, etc. for DIDs. In addition, verifiable credential (VC) data registry services are provided to enable management of VCs, such as for actions including creation / storage, update, deletion / revocation, etc. for VCs.

[0007] By utilizing the described techniques, the security of digital transactions (eg, web-based transactions) is improved, and system resources utilized to manage digital identities and digital transactions are conserved.

[0008] Some implementations of the methods and apparatus described herein may further include receiving a storage request comprising a storage object and one or more of the following: a source identifier, a registration identifier, service type information, an access role, authorization information, a decentralized identifier, or a request type; sending an authorization verification request for the storage request; receiving an authorization verification response based at least in part on the authorization verification request; sending a registry notification based at least in part on the authorization verification response, the registry notification comprising a storage object and one or more of the following: registry service information, a request type, a source identifier, a service type information, a registration identifier, or authorization information; receiving a confirmation message based at least in part on the registry notification; and sending a storage response comprising an indication of the result of the storage request.

[0009] Some implementations of the methods and apparatus described herein may also include: wherein the storage object includes one or more of the following: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the method is implemented as part of a ledger registry management service, and also includes: receiving a storage request from one or more endpoint devices or applications; sending an authorization verification request to a registry service, and receiving an authorization verification response from the registry service; sending a registry notification to one or more of a permissioned distributed ledger node or a permissioned distributed ledger network; receiving a confirmation message from the registry service; and sending a storage response to one or more endpoint devices or applications; the registry notification also includes one or more of the following: an identifier for the ledger registry management service, an authorized access role for the storage request, or a lifetime for the storage object; the registry service includes a decentralized identifier operation participant registry service.

[0010] Some implementations of the methods and apparatus described herein may further include: sending a registry notification transaction to a permissioned distributed ledger node, wherein the registry notification transaction includes one or more of the following items: a registry service type, a registry service identifier, a ledger registration management service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for a storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information; the lifetime includes a lifetime for at least one of one or more decentralized identifier documents or one or more verifiable credentials; the storage request is associated with one or more of the decentralized identifier or the decentralized identifier documents, and the storage response also includes one or more of the following items: a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address; the request type includes one or more of the following items: a create indication, an update indication, or a delete indication; the authorization verification request includes one or more of the following items: a registration identifier, a source identifier, an access role for a storage request, or authorization information.

[0011] Some implementations of the methods and apparatus described herein may further include: wherein the authorization information includes one or more of a code or a token; the authorization verification response includes one or more of the following: a registration identifier, a source identifier, or an indication of a result for an authorization verification request; message-to-transaction adaptation is performed to transform a registry notification into a registry notification transaction; the registry notification is associated with one or more of a decentralized identifier document or a verifiable credential; the access role indicates whether the storage request is initiated by one or more of the following: an identity holder, an identity controller, a decentralized identifier holder, a decentralized identifier controller, or a verifiable credential issuer; the indication of the result of the storage request includes an indication of the success of the storage request; the indication of the result of the storage request includes an indication of the failure of the storage request.

[0012] Some implementations of the methods and apparatus described herein may also include: receiving an authorization verification request for a storage request for a storage object, the authorization verification request including one or more of the following: a registration identifier, a source identifier, an access role associated with the storage request, or an authorization code; processing the authorization verification request to determine whether the authorization verification request is valid; and sending an authorization verification response, the authorization verification response including an indication of a result of the authorization verification request, and one or more of the following: a registration identifier or a source identifier.

[0013] Some implementations of the methods and apparatus described herein may further include: wherein the storage object includes one or more of the following items: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the method is executed as part of a registry service, and further includes: receiving an authorization verification request from a ledger registration management service; and sending an authorization verification response to the ledger registration management service; the indication of the result of the authorization verification request includes an indication of the success of the authorization verification request or an indication of the failure of the authorization verification request.

[0014] Some implementations of the methods and apparatus described herein may further include receiving a registry notification transaction, wherein the registry notification transaction includes a storage object, and one or more of the following items: a registry service type, a registry service identifier, a ledger registry management service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for the storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information; recording the registry notification transaction; and sending a confirmation message, the confirmation message including an indication of the result of the registry notification transaction, and one or more of the following items: a registry service type, a registry service identifier, a storage object registry address, a storage object resolver identifier, or a storage object resolver address.

[0015] Some implementations of the methods and apparatus described herein may also include: wherein the storage object includes one or more of the following items: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the method is performed as part of a storage object registry service, and also includes: receiving a registry notification transaction from a permissioned distributed ledger node; and sending a confirmation message to the ledger registration management service; the indication of the result of the registry notification transaction includes an indication of the success of the registry notification transaction or an indication of the failure of the registry notification transaction.

[0016] Some implementations of the methods and apparatus described herein may further include sending a decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a request type, a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address; and receiving a confirmation message including a result of the decentralized identifier resolver transaction notification, and one or more of the following: a ledger registry service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address.

[0017] Some implementations of the methods and apparatus described herein may also include where a result of a decentralized identifier resolver transaction notification includes one of an indication of a success of the decentralized identifier resolver transaction notification or an indication of a failure of the decentralized identifier resolver transaction notification.

[0018] Some implementations of the methods and apparatus described herein may further include receiving a decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address; storing at least some of the information included in the decentralized identifier resolver transaction notification; and sending a confirmation message including one, and one or more of the following: a ledger registration management service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address.

[0019] Some implementations of the methods and apparatus described herein may also include where a result of a decentralized identifier resolver transaction notification includes one of an indication of a success of the decentralized identifier resolver transaction notification or an indication of a failure of the decentralized identifier resolver transaction notification. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 An example of a wireless communication system supporting digital identity management according to aspects of the present disclosure is illustrated.

[0021] Figure 2 An example of the generation and use of verifiable claim(s) is illustrated.

[0022] Figure 3 Examples of DID registries on distributed ledgers and blockchains, such as those related to registration processes for ledger-based identities, are illustrated in accordance with aspects of the present disclosure.

[0023] Figure 4 Illustrated is a system presenting an example architecture for identity management and authentication from a self-sovereign identity (SSI) perspective.

[0024] Figure 5 A PDL platform supporting digital identity management according to aspects of the present disclosure is illustrated.

[0025] Figure 6 Portions of a system supporting digital identity management according to aspects of the present disclosure are illustrated.

[0026] Figure 7Portions of a system supporting digital identity management according to aspects of the present disclosure are illustrated.

[0027] Figure 8 A system supporting digital identity management according to aspects of the present disclosure is illustrated.

[0028] Fig. 9 An example of a block diagram of a device supporting digital identity management according to aspects of the present disclosure is illustrated.

[0029] Figures 10 to 14 A flow chart of a method of supporting digital identity management according to aspects of the present disclosure is illustrated. DETAILED DESCRIPTION

[0030] In some identity systems, digital identity management related to DID and SSI involves various processes, such as storage, management, processing, verification of identities and related documents (e.g., VC, password-related information, etc.), and selective data disclosure in a distributed platform (e.g., PDL) to enable authentication and authorization based on digital identities. In addition, such processes may involve multiple actors, such as identity holders (e.g., DID holders), DID controllers, VC issuers, relying parties (e.g., verifiers), etc. However, some existing platforms do not provide services to support digital identity-specific identity and trust management processes, which involve storage, management, processing, verification and management (e.g., access control and authorization) of multiple actors, selective data disclosure to relying parties, etc.

[0031] Therefore, the present disclosure provides technologies to support digital identity management. For example, implementations provide methods, devices, and systems to support digital identity management. For example, implementations provide permissioned distributed ledger (PDL) services and associated message exchanges and operations. For example, a DID document registry service is provided to enable management of DIDs, such as for actions including creation / storage, update, deletion / revocation, etc. for DIDs. In addition, a verifiable credential (VC) data registry service is provided to enable management of VCs, such as for actions including creation / storage, update, deletion / revocation, etc. for VCs.

[0032] For example, the implementation described in this article provides for the storage and management of DID documents and verifiable credentials associated with DIDs in a ledger, including:

[0033] Storage of DIDs and DID documents (e.g., upon request from the DID holder and / or DID controller)

[0034] Updates to DIDs and DID documents (e.g., upon request from the DID holder and / or DID controller)

[0035] Deletion / revocation of DIDs and DID documents (e.g., upon request from DID holders, DID controllers, and / or the Ledger Registry Management Service (L-RMS) in the PDL platform)

[0036] Storage of VCs (e.g., upon request from a DID holder, DID controller, and / or VC issuer)

[0037] Update of VC (e.g., upon request from DID holder, DID controller, and / or VC issuer)

[0038] Deletion / revocation of a VC (e.g., upon request from a DID holder, DID controller, and / or VC issuer)

[0039] Thus, by utilizing the described techniques, the security of digital transactions (eg, network-based transactions) is improved, and system resources utilized to manage digital identities and digital transactions are conserved.

[0040] Aspects of the present disclosure are described in the context of a wireless communication system. Aspects of the present disclosure are further illustrated and described with reference to device diagrams and flow charts.

[0041] Figure 1 An example of a wireless communication system 100 supporting digital identity management according to various aspects of the present disclosure is illustrated. The wireless communication system 100 may include one or more network entities 102, one or more UEs 104, a core network 106, and a packet data network 108. The wireless communication system 100 may support various radio access technologies. In some implementations, the wireless communication system 100 may be a 4G network, such as an LTE network or an advanced LTE (LTE-A) network. In some other implementations, the wireless communication system 100 may be a 5G network, such as an NR network. In other implementations, the wireless communication system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technologies, including the Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G. In addition, the wireless communication system 100 may support technologies such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA).

[0042] One or more network entities 102 may be dispersed throughout a geographic region to form a wireless communication system 100. One or more of the network entities 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a radio access network (RAN), a base transceiver station, an access point, a NodeB, an eNodeB (eNB), a next generation NodeB (gNB), or other suitable terms. The network entity 102 and the UE 104 may communicate via a communication link 110, which may be a wireless or wired connection. For example, the network entity 102 and the UE 104 may perform wireless communication (e.g., receive signaling, send signaling) via a Uu interface.

[0043] The network entity 102 may provide a geographic coverage area 112 for which the network entity 102 supports services (e.g., voice, video, packet data, messaging, broadcast, etc.) for one or more UEs 104 within the geographic coverage area 112. For example, the network entity 102 and the UE 104 may support wireless communications of signals associated with services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or more radio access technologies. In some implementations, the network entity 102 may be mobile, for example, a satellite associated with a non-terrestrial network. In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but different geographic coverage areas 112 may be associated with different network entities 102. The information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0044] One or more UEs 104 may be dispersed throughout the geographic region of the wireless communication system 100. UE 104 may include or may be referred to as a mobile device, a wireless device, a remote device, a remote unit, a handheld device, or a subscriber device, or some other suitable term. In some implementations, UE 104 may be referred to as other examples such as a unit, a station, a terminal, or a client. Additionally or alternatively, UE 104 may be referred to as other examples such as an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a Machine Type Communication (MTC) device. In some implementations, UE 104 may be stationary in the wireless communication system 100. In some other implementations, UE 104 may be mobile in the wireless communication system 100.

[0045] One or more UEs 104 may be devices of different forms or with different capabilities. Figure 1Some examples of UE 104 are illustrated in FIG. UE 104 may be able to communicate with various types of devices, such as network entity 102, other UE 104, or network equipment (e.g., core network 106, packet data network 108, relay device, integrated access and backhaul (IAB) node, or another network device), such as Figure 1 Additionally or alternatively, UE 104 can support communications with other network entities 102 or UE 104, which can act as relays in wireless communication system 100.

[0046] The UE 104 may also be capable of supporting wireless communications directly with other UEs 104 via a communication link 114. For example, the UE 104 may support wireless communications directly with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, V2X deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a side link. For example, the UE 104 may support wireless communications directly with another UE 104 via a PC5 interface.

[0047] The network entity 102 may support communication with the core network 106, or with another network entity 102, or with both. For example, the network entity 102 may interface with the core network 106 via one or more backhaul links 116 (e.g., via S1, N2, N2, or another network interface). The network entities 102 may communicate with each other via the backhaul links 116 (e.g., via X2, Xn, or another network interface). In some implementations, the network entities 102 may communicate directly with each other (e.g., between the network entities 102). In some other implementations, the network entities 102 may communicate with each other or indirectly (e.g., via the core network 106). In some implementations, one or more network entities 102 may include subcomponents, such as access network entities, which may be examples of access node controllers (ANCs). The ANC may communicate with one or more UEs 104 via one or more other access network transmission entities (which may be referred to as radio heads, smart radio heads, or transmission reception points (TRPs)).

[0048] In some implementations, the network entity 102 may be configured in a disaggregated architecture that may be configured to utilize a protocol stack that is physically or logically distributed between two or more network entities 102, such as an integrated access backhaul (IAB) network, an open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance), or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN)). For example, the network entity 102 may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a RAN intelligent controller (RIC) (e.g., a near real-time RIC (near real-time (RT) RIC), a non-real-time RIC (non-RT RIC)), a service management and orchestration (SMO) system, or any combination thereof.

[0049] The RU may also be referred to as a radio head, a smart radio head, a remote radio head (RRH), a remote radio unit (RRU), or a transmission reception point (TRP). In a disaggregated RAN architecture, one or more components of the network entity 102 may be co-located, or one or more components of the network entity 102 may be located in distributed locations (e.g., separate physical locations). In some implementations, one or more network entities 102 of the disaggregated RAN architecture may be implemented as virtual units (e.g., virtual CU (VCU), virtual DU (VDU), virtual RU (VRU)).

[0050] The functional split between CU, DU and RU can be flexible, and different functions can be supported depending on the functions (e.g., network layer functions, protocol layer functions, baseband functions, radio frequency functions, and any combination thereof) executed at the CU, DU or RU. For example, a functional split of a protocol stack can be adopted between the CU and the DU so that the CU can support one or more layers of the protocol stack and the DU can support one or more different layers of the protocol stack. In some implementations, the CU can host upper protocol layer (e.g., Layer 3 (L3), Layer 2 (L2)) functions and signaling (e.g., Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP)). The CU can be connected to one or more DUs or RUs, and the one or more DUs or RUs can host lower protocol layers, such as Layer 1 (L1) (e.g., physical (PHY) layer) or L2 (e.g., radio link control (RLC) layer, media access control (MAC) layer) functions and signaling, and can each be at least partially controlled by the CU.

[0051] Additionally or alternatively, a functional split of the protocol stack may be employed between the DU and the RU such that the DU may support one or more layers of the protocol stack and the RU may support one or more different layers of the protocol stack. The DU may support one or more different cells (e.g., via one or more RUs). In some implementations, the functional split between the CU and the DU or between the DU and the RU may be within the protocol layer (e.g., some functions of the protocol layer may be performed by one of the CU, DU, or RU, while other functions of the protocol layer may be performed by a different one of the CU, DU, or RU).

[0052] The CU may be further functionally split into CU control plane (CU-CP) functionality and CU user plane (CU-UP) functionality. The CU may be connected to one or more DUs via a medium-range communication link (e.g., F1, F1-c, F1-u), and the DU may be connected to one or more RUs via a fronthaul communication link (e.g., an open fronthaul (FH) interface). In some implementations, the medium-range communication link or the fronthaul communication link may be implemented based on interfaces (e.g., channels) between layers of a protocol stack supported by a corresponding network entity 102 communicating via such a communication link.

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

[0054] The core network 106 may communicate with the packet data network 108 via one or more backhaul links 116 (e.g., via S1, N2, N2, or another network interface). The packet data network 108 may include an application server 118. In some implementations, one or more UEs 104 may communicate with the application server 118. The UE 104 may establish a session (e.g., a PDU session, etc.) with the core network 106 via the network entity 102. The core network 106 may use the established session (e.g., the established PDU session) to route traffic (e.g., control information, data, etc.) between the UE 104 and the application server 118. The PDU session may be an example of a logical connection between the UE 104 and the core network 106 (e.g., one or more network functions of the core network 106).

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

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

[0057] The time intervals of resources (e.g., communication resources) can be organized according to frames (also referred to as radio frames). Each frame can have a duration, for example, a duration of 10 milliseconds (ms). In some implementations, each frame can include multiple subframes. For example, each frame can include 10 subframes, and each subframe can have a duration, for example, a duration of 1 ms. In some implementations, each frame can have the same duration. In some implementations, each subframe of a frame can have the same duration.

[0058] Additionally or alternatively, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may include a certain number (e.g., quantity) of time slots. Each time slot may include a certain number (e.g., quantity) of symbols (e.g., orthogonal frequency division multiplexing (OFDM) symbols). In some implementations, the number (e.g., quantity) of time slots used for a subframe may depend on the digital technology. For a normal cyclic prefix, a time slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable to a 60kHz subcarrier spacing), a time slot may include 12 symbols. For a normal cyclic prefix and an extended cyclic prefix, the relationship between the number of symbols per time slot, the number of time slots per subframe, and the number of time slots per frame may depend on the digital technology. It should be understood that references to a first digital technology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15kHz) may be used interchangeably between subframes and time slots.

[0059] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, frequency channels, etc. based on frequency or wavelength. By way of example, the wireless communication system 100 can support one or more operating frequency bands, such as frequency range names 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 network entity 102 and the UE 104 can perform wireless communications on one or more operating frequency bands. In some implementations, FR1 can be used by the network entity 102 and the UE 104, as well as other devices or apparatuses for cellular communication services (e.g., control information, data). In some implementations, FR2 may be used by the network entity 102 and the UE 104, as well as other equipment or devices for short-range, high data rate capabilities.

[0060] FR1 may be associated with one or more digital technologies (e.g., at least three digital technologies). For example, FR1 may be associated with a first digital technology (e.g., μ=0) including a 15kHz subcarrier spacing, a second digital technology (e.g., μ=1) including a 30kHz subcarrier spacing, and a third digital technology (e.g., μ=2) including a 60kHz subcarrier spacing. FR2 may be associated with one or more digital technologies (e.g., at least 2 digital technologies). For example, FR2 may be associated with a third digital technology (e.g., μ=2) including a 60kHz subcarrier spacing, and a fourth digital technology (e.g., μ=3) including a 120kHz subcarrier spacing.

[0061] Depending on the implementation for digital identity management, the network entity 102 may implement at least a portion of the PDL platform 120, and the UE 104 may represent an instance of an end-client 122, e.g., an endpoint client device and / or application. Example implementation details of the PDL platform 120 and the end-client 122 are discussed in detail below. Thus, the network entity 102 and the UE 104 may interact as part of a PDL interaction 124, such as as part of the management of various aspects of DIDs, DID documents, VCs, etc. As described in further detail below, for example, the PDL platform 120 may provide various services related to DIDs, DID documents, and VCs for the end-client 122.

[0062] In some network scenarios, identity management solutions based on decentralized identity and / or self-sovereign identity (SSI) are discussed in the context of trust frameworks. For example, a decentralized identifier (DID) is a type of identifier for a verifiable "self-sovereign" digital identity. A DID can be completely under the control of a DID subject and independent of a centralized registry, identity provider, or credential authority. A DID can be a URL that associates a DID subject with a trusted way to interact with the subject. A DID can be parsed into a DID document, for example, a simple document describing how to use the particular DID. Each DID document can contain at least three things: a proof purpose, a verification method, and a service endpoint. The proof purpose can be combined with a verification method to provide a mechanism for proving things. For example, a DID document can specify a specific verification method, such as an encrypted public key or a pseudonymous biometric protocol, which can be used to verify a proof created for authentication purposes. A service endpoint can enable trusted interaction with a DID controller.

[0063] Since a DID can be implemented as an identifier, the DID may not provide information about the subject itself. In practice, a DID is used in combination with a verifiable claim to support digital interactions in which information about the subject is shared with a third party, such as by proving to the third party that the DID subject has ownership of certain attestations or attributes. The proof can be based on a cryptographic link between a verifiable claim, a verifiable claim and its associated DID subject, and an issuer of the verifiable claim, which can be a DID subject (e.g., a self-asserted claim) or a trusted entity. Trust in the issuer can be established by trusting the issuer's DID (e.g., out-of-band, bilateral relationships, trusted lists) or by any other means. Then, a third party can use the presented cryptographically protected proof to verify the ownership and credibility of the statement about the subject. Since the presentation of the statement is managed by the user, the user can decide which specific pieces of information about themselves they want to share with third parties; with the help of this selective attribute disclosure, privacy and personal data protection are strengthened.

[0064] Figure 2 An example 200 of the generation and use of (multiple) verifiable claims is illustrated. For example, the example 200 is related to identity authentication and verification, such as related to the registration process of a ledger-based identity according to various aspects of the present disclosure. As shown in the example 200, the information flow of the generation and use of verifiable claims is derived from the W3C working draft of the Verifiable Credentials Data Model (1.0). In this data model, a credential is considered to be a collection of one or more claims made by an issuer 202, and may also include credential metadata and one or more proofs. In this example 200, the issuer 202 issues a credential to a holder 204 that obtains, stores, and presents the credential. The holder 204 sends the presentation to the verifier 206 for requesting and verifying. A verifiable data registry 208 receives input from the issuer 202, from the holder 204, and from the verifier 206, and the verifiable data register 208 maintains identifiers and schemes.

[0065] Figure 3An example 300 of a DID registry on a distributed ledger and blockchain, such as one related to a registration process for an identity based on a ledger, is illustrated according to various aspects of the present disclosure. To implement DIDs and VCs, organizations working on SSI rely on using distributed ledgers and / or blockchains to support a registry of identifiers. In particular, the Decentralized Identity Foundation (DIF) proposes the architecture shown in example 300, which includes multiple components. For example, a user agent 302 is a program, such as a browser, a mobile application, or other web-based client, that mediates communication between a holder (204), an issuer (202), and a verifier (206). A universal resolver 304 is a server that features a pluggable system of DID method drivers that enables resolution and discovery of DIDs across any decentralized system. A universal registrar 306 is a server that enables registration of DIDs across any decentralized system that produces compatible drivers. Additionally, identity hub 308 is a secure personal data repository that coordinates the storage of signed and / or encrypted data and relays messages to identity linking devices.

[0066] Figure 4 A system 400 is illustrated that presents an example architecture for identity management and authentication from the perspective of an SSI. For example, the system 400 includes the following architectural elements:

[0067] DID: A type of identifier that enables a verifiable decentralized digital identity. A DID can refer to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) determined by the controller of the DID. A DID can be considered a form of pseudonymity because the DID may not be directly linked to a formal identifier of a natural or legal person.

[0068] • DID Document 402: A DID document contains information associated with a DID. A DID document typically expresses an authentication method (such as an encrypted public key), and services related to interaction with the holder. A DID document may be signed by a DID controller.

[0069] DID Controller 404: A controller of a DID is an entity (e.g., a person, organization, autonomous software, etc.) that has the ability to make changes to the DID document, as defined by the DID method. The following security procedures for a DID controller may be utilized:

[0070] ○ Prove that the holder owns or controls their private key

[0071] ○Issues a unique DID to the holder

[0072] VC 406: A collection of one or more claims made by the issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified.

[0073] VC Issuer 408: A role that an entity may perform by asserting claims about one or more subjects, creating verifiable credentials from those claims, and sending the verifiable credentials to a holder 409. The following security procedures for a DID controller may be utilized:

[0074] ○ Authenticate the holder identified by their DID

[0075] ○ Prove that the claimed property belongs to the holder

[0076] ○ Revoke the owner's attributes

[0077] • Representation 410: Data derived from one or more verifiable credentials issued by one or more issuers, which is shared with a specific verifier 411. A verifiable representation is a tamper-proof representation that is encoded so that the authorship of the data can be trusted after a process of cryptographic verification.

[0078] • Repository 412: A program, such as a storage repository or personal verifiable credential wallet, that stores and protects access to the holder's verifiable credentials. Use of the repository may be restricted to the holder or other authorized parties.

[0079] Key wallet 414: An application used to generate, manage, store or use private and public keys. The key wallet may be protected by a specially protected "secure element" within the wallet. The use of the keys may be restricted to the holder.

[0080] Wallet: A wallet can be used to cover repositories of verifiable data (DID documents, verifiable credentials) as well as key wallets. A wallet can be considered a form of secure enclave (SA application). For example, this can be supported using a proxy service that is remotely accessed from a user's device and controlled by using multiple authentication factors.

[0081] DID registry 416: In order to be able to resolve DID documents, DIDs may be recorded on some underlying system or network. Regardless of the specific technology used, any such system that supports recording DIDs and returns the data required to generate DID documents may be used. This may be referred to as a DID document registry. The DID registry may be based on a distributed ledger (such as a blockchain).

[0082] VC Registry 418: A role that the system can perform by brokering the creation and verification of identifiers, keys, and other related data, such as a verifiable credential scheme, revocation registry, issuer public keys, etc., which can be specified to use verifiable credentials. Some configurations may use associated identifiers for principals. Some registries (such as registries for UUIDs and public keys) can act as namespaces for identifiers.

[0083] • Holder authentication: A protocol exchange used to gain authorized access to a resource.

[0084] In an example implementation, the European Telecommunications Standards Institute (ETSI) PDL reference architecture describes services such as registration services, identity services, and identity management services (among other services) as described below.

[0085] Registration: Listing of managed objects with an issuing authority or registry in accordance with clause 5.4.2.5 ETSI-ISG-PDL Registration Platform Service. The Registration Service may provide a means to list ETSI-ISG-PDL managed objects with local or international issuing authorities or registries. Such a registry allows such managed objects to be referenced for legal, commercial and operational purposes. Registration requirements may vary by geography, but not all registries are linked to the geography in which the registry is used. Certain managed objects (e.g., PDLs serving geographically different applications) operate in multiple geographies and may require multiple registrations. ETSI-ISG-PDL managed objects may be registered in one or more registries. Registered ETSI-ISG-PDL managed objects will be registered in accordance with the regulations and rules applicable to the geography in which they operate.

[0086] Application Registration: Registers and lists all applications operating on the platform. According to clause 5.4.3.21.6 Application Registration, Application Registration is the function of registering and listing all applications operating on the platform. The ETSI-ISG-PDL platform will maintain a list of all applications registered and operating on it.

[0087] Identity: Unambiguously identifies an instance of an entity from other instances of that object and other objects. According to clause 5.4.2.3 ETSI-ISG-PDL Identity Platform Services, the identity of an entity is a set of context-dependent numeric identifiers that unambiguously identifies an instance of that entity from all other instances of that object and other objects. An identity may use multiple attributes to uniquely identify that identity (e.g., two products with the same name have other different attributes, such as different serial numbers).

[0088] The ETSI-ISG-PDL identity will be constructed using one or more context-dependent digital identifiers that enable object instances to be unambiguously identified. A digital identifier is a unique security object within a specific namespace. It is recommended that each digital identifier be assigned a namespace. The ETSI-ISG-PDL digital identifier can be defined within a namespace to ensure its uniqueness. Entities can be used in different situations. Therefore, for each situation, the same entity can be identified using a different set of digital identifiers. This enables the semantics of using the entity in each situation to be taken into account.

[0089] An ETSI-ISG-PDL managed object may have multiple context-dependent numeric identifiers for establishing the identity of the managed object in different situations in which the ETSI-ISG-PDL managed object is used. The ETSI-ISG-PDL identity service provides a single identity token to each instance of an entity for all services, so that the instance is identified unambiguously and in the same way by all services. The ETSI-ISG-PDL identity service shall provide a single numeric identity token to each instance of an entity.

[0090] Identity Management: Access control based on the identity of an entity. According to clause 5.4.3.4.6, the ETSI-ISG-PDL Identity Management Platform Service Identity Management defines access control based on the identity of an entity that initiates a specific set of operations on a target according to a set of criteria. The ETSI-ISG-PDL Identity Management Platform Service depends on the ETSI-ISG-PDL Namespace Platform Service as well as the ETSI-ISG-PDL Identity Platform Service.

[0091] The Identity Management Platform Service will be implemented in all platforms that comply with ETSI-ISG-PDL. The Identity Management Platform Service and the Identity Platform Service can be two distinct and different services. The Identity Platform Service defines how identities are assigned, while the Identity Management Platform Service defines how access is managed based on the assigned identities.

[0092] Thus, implementations have been described with respect to registration, application registration, identity, and identity management. However, such implementations exhibit shortcomings in supporting decentralized identity management and related verification processes, as shown in the following limitations.

[0093] (i) The Registration Service and Application Registration Service do not support role-based access control and authorization settings as part of the registration, which is very important for handling different parties and operations for a decentralized identity and trust management framework.

[0094] (ii) Identity and identity management services do not enable an identity holder (e.g., an end device and / or application) to set an identifier for itself, or do not allow an identity holder (e.g., as an identity controller) to set an identifier for another device and / or object associated with it.

[0095] (iii) Existing PDL services do not support selective data sharing specific to managed identifier(s).

[0096] Therefore, solutions supporting digital identity management are provided in the present disclosure, such as PDL platform services to support identity (e.g., DID and SSI-based) and trust management solutions that utilize PDL and / or other ledger platforms. For example, the described solution provides DID document registry services (e.g., for creation / storage, update, delete / revoke, etc.) and VC data registry services, e.g., for creation / storage, update, delete / revoke, etc.

[0097] In an implementation, techniques for managing (e.g., storing, updating, deleting, and revoking) DIDs and DID documents, such as in a PDL platform, are described. For example, a DID resolves to a DID document, which represents a document that describes how to use a particular DID. Each DID document may contain at least three things: a proof purpose, a verification method, and a service endpoint. The proof purpose may be combined with a verification method to provide a mechanism for proving things. For example, a DID document may specify a specific verification method, such as an encrypted public key or a pseudonymous biometric protocol, that may be used to verify a proof created for authentication purposes. The service endpoint enables trusted interaction with a DID controller. In addition, the management of DIDs and related DID documents may involve operations such as the following:

[0098] 1. Storage of DIDs and DID documents, e.g., upon request from a DID holder or DID controller;

[0099] 2. Updates to DIDs and DID documents, e.g., upon request from a DID holder or DID controller;

[0100] 3. Deletion / revoke of DIDs and DID documents, e.g., upon request from the DID holder, DID controller, and / or L-RMS in the PDL platform.

[0101] Figure 5A PDL platform 500 supporting digital identity management according to various aspects of the present disclosure is illustrated. In the platform 500, an identity holder 502 (e.g., which may be referred to as a subject, such as an individual, organization, thing, data model, abstract entity, function, end user, device, etc.) may generate a digital identifier, such as a DID and / or SSI. For example, the identity holder 502 itself may generate the digital identifier and / or the digital identifier may be generated and supplied to the identity holder 502 by a service provider 504 or a DID controller 506 (e.g., another party that creates a digital identifier on behalf of the identity holder to identify and authenticate the identity holder). Some examples of the DID controller 506 include: (i) an organization that may be an identity controller for an employee, who is an identity holder, (ii) an individual that may be an identity controller for an IoT object, the IoT object being associated with the individual, where the IoT object may be an identity holder, and the like.

[0102] A verifiable credential / claim issuer 508 (VC issuer) can perform assertions about one or more subjects, create a verifiable credential (VC) based on these claims (e.g., a passport, driver's license, and birth certificate), and send the verifiable credential to the holder. For example, a VC includes a collection of one or more claims made by an issuer. For example, a VC represents a tamper-proof credential that has an author identity that can be cryptographically verified. An identity holder 502 presents data (e.g., for authentication and authorization) derived from one or more verifiable credentials issued by one or more issuers, which is shared with a specific verifier. A verifiable presentation is a tamper-proof presentation that is encoded in a manner such that the author identity of the data can be trusted after a cryptographic verification process.

[0103] To enable verifiers (such as service providers and / or third-party service providers) to verify DIDs and authenticate identity holders / subjects, the platform 500 includes PDL services 510 in addition to existing PDL services related to role-based registration, storage, and management of DIDs, DID documents, VCs, verification of DIDs, and selected exposure of data and / or claims (e.g., as utilized by services). In addition, the DID-based identity framework may also include governance-related services (e.g., governance platform services 512 may be a collection of rules and tools that control the behavior and functionality of the PDL platform to enable identity and trust management) and off-chain storage 513 (e.g., storing information in a digital, machine-readable medium that is not stored on the main chain) to enable scaling of data-intensive and / or data-sensitive blockchain-based applications (such as VCs). For example, the DID-based identity framework can be used to store non-transactional data that is too large to be efficiently stored in the blockchain and / or requires the ability to be changed or deleted. Off-chain data can be accessed by a subset of nodes participating in the chain.

[0104] A role-based registration management service 514, for example, utilizing operations involving registration, revocation, de-registration, etc.: The role-based registration management service 514 can take into account the following different roles, actors, and / or participants that will be involved in the identity and trust management framework, and can provide registration services (and authorization) specific to the corresponding roles of actors in the PDL platform.

[0105] Identity holder;

[0106] Identity controller;

[0107] VC issuer;

[0108] · Authenticator; and

[0109] Others (e.g. any participants / stakeholders who will be involved in the identity and trust management framework).

[0110] DID Operation Participant Registry Service 516 : The DID Operation Participant Registry Service 516 may record and track the identity and trust management framework participants registered and deregistered in the PDL platform 500 based on instructions from the role-based registration management service 514 .

[0111] DID registry / DID resolver service 518: The DID registry / DDI resolver service 518 can store and track DID(s) and their associated DID document location information (e.g., address) to enable authorized services and entities to perform DID document extraction and verification.

[0112] DID document registry service 520, whose operations may involve creation / storage, update, deletion / revocation, etc. for DID documents: The DID document registry service 520 may store and manage DID documents associated with a DID to facilitate DID verification. Each DID document may contain at least three things: a proof purpose, service-specific information for which the DID document can be used, a verification method, and a service endpoint. The proof purpose may be combined with a verification method to provide a mechanism for proving things. For example, a DID document may specify a specific verification method, such as an encrypted public key or a pseudonymous biometric protocol, that may be used to verify a proof created for authentication purposes. The service endpoint enables trusted interaction with a DID controller and authorized verifiers.

[0113] Verifiable Credentials (VC) data registry service 522, whose operations may involve creating / storing VCs, updating VCs, deleting / revoking VCs: The VC registry service 522 may store and manage VCs associated with DIDs to facilitate VC-based DID verification and verification related to service requests.

[0114] DID Verification Service 524: The DID Verification Service 524 can be a composite service that uses the DID registry service / DID resolver service 518, the DID document registry service 520, and the DID operation(s) participant registry service 516 to extract necessary data related to verification of the DID (e.g., authentication of the subject identified by the DID), and exposes selective data to the verifier to enable authorization verification of the subject to (multiple) corresponding services.

[0115] Figure 6 Portions of a system 600 supporting digital identity management according to aspects of the present disclosure are illustrated. For example, the system 600 can be implemented to store DIDs and DID documents in the PDL platform 500 introduced above. The system 600 includes an end client 602 (e.g., an endpoint device and / or application), a PDL platform L-RMS 604, a PDL node 608 (e.g., which belongs to a PDL network) 606, a PDL node (e.g., which belongs to a PDL network), a registry service DID operation participant registry (RS-DID OP) 610, a registry service DID document registry (RS-DID DR) 612, and a DID registry / resolver service (DID R / R service) 614.

[0116] In an example operation of the system 600 at 618, the end client 602 may send a DID document storage request 618 to the L-RMS 604, and the DID document storage request 618 may include various information, such as a source identity (e.g., a PDL user identifier (ID)), a registration ID, service type information (e.g., which may indicate a DID service), an access role (e.g., indicated as an ID / DID holder, which may be a principal and / or an end user), authorization information (e.g., a code or token received as authorization information during a successful registration), DID document(s), a request type (e.g., set to store / create), etc. The DID document(s) may include information such as: a DID, a DID controller ID, authentication method(s), an encrypted public key, a service type / information, other information, a verifiable claim, a uniform resource indicator (URI) associated with the claim, etc. In an implementation, if a secure connection exists, the end client 602 (e.g., an ID holder) may send the document storage request at 618. Otherwise, at 620 , the end-client 602 and the L-RMS 604 may perform mutual authentication and establish a secure connection before fulfilling the DID document storage request 618 .

[0117] In an alternative or additional implementation, the end client 602 may send a DID document storage request 618 with information other than the registration ID, access role, DID document, and authorization code to the L-RMS 604. Accordingly, at 620, the L-RMS 604 may send a request for this information by sending an authorization request message with the source ID to the end client 602. At 620, the end client 602 may then respond with an authorization response message with the registration ID, access role, DID document, and authorization information.

[0118] At 622, the L-RMS 604 sends an authorization verification request message 622 to the RS-DID OP 610 (e.g., associated with a DID operation (participant) and / or alternatively referred to as an identity and trust management framework / platform participant) and based on local configuration and policy, the authorization verification request message 622 may include a registration ID, a source ID, an access role, and authorization information (e.g., a code and / or token for authorization).

[0119] At 624, RS-DID OP 610 processes the authorization verification request message 622 to verify the authorization information (e.g., authorization code or token) associated with the registration ID and access role. For example, RS-DID OP 610 queries the corresponding ledger and / or chain (e.g., for related transaction history and / or records) and / or checks offline and / or local storage to check whether the authorization information and registration ID match the record associated with the participant being registered. RS-DID OP 610 can also check whether the participant's access role is correct based on the record.

[0120] At 626, if the verification of the registration ID, access role, and authorization information at RS-DID OP 610 is successful, RS-DID OP 610 sends an authorization verification response message 626 to L-RMS 604, which may include the registration ID, source ID, and a result of "success". Alternatively, if at 624, the verification of the registration ID, access role, and authorization information does not match the record, and / or if the registered access role is different from the access role received at 622, RS-DID OP 610 may send an authorization verification response message 626 to L-RMS 604, which may include the registration ID, source ID, and a result of "failure".

[0121] At 628, if L-RMS 604 determines that the authorization verification is successful based on authorization verification response message 626, L-RMS 604 performs registry transaction processing to generate DID document registry notification message 630, which may include information such as the following items: target registry service type and / or ID, creation indication*, L-RMS ID, source identity, service type information (DID service), registration ID, authorized access role, authorization code, lifetime, DID, and (multiple) DID documents. In addition, document registry notification message 630 can be transformed into a DID document transaction to store the DID document to the corresponding registry (e.g., DID document registry) indicated by the target registry service type / ID.

[0122] In an alternative implementation, the L-RMS 604 may directly generate a DID document transaction, which may include a DID document registry notification message (target registry service type / ID, request type (e.g., with store / create indication)*, L-RMS ID, source identity, service type information (DID service), registration ID, authorized access roles, authorization code, lifetime, DID, (multiple) DID documents, etc.

[0123] Alternatively, if a failure is indicated at 626 , the process may continue to 646 to indicate to the end client 602 that a failure occurred.

[0124] L-RMS 604 may send a document registry notification message 630 including a DID document transaction to configured PDL node 606. At 632, PDL node 606 propagates the DID document transaction received from document registry notification message 630 through system 600. At 634, PDL node 608 (e.g., PDL node-2) receives the DID document transaction from the target PDL network as a result of the transaction propagation at 632.

[0125] After the DID document transaction is validated and successfully stored in the ledger (e.g., as a result of a PDL consensus process in the ledger associated with the registry service associated with the DID document (transaction) based on the target registry service type information), at 636, the PDL node 608 forwards the DID document transaction to the RS-DID DR 612 based on the target registry service information. The RS-DID DR 612 may transform the transaction into a message to recover the message, for example, the DID document registry transaction as a DID document registry notification message. Alternatively, the PDL node 608 transforms the transaction into a message and sends the DID document transaction as a DID document registry notification message to the RS-DID DR 612. At 638, the RS-DID DR 612 may store the DID document transaction and / or information received as part of the DID document registry notification message at 636 (or vice versa) in local storage, off-chain storage, and / or as part of the ledger.

[0126] At 640a, RS-DID DR 612 may send a notification message 640a (e.g., a DID resolver notification message) to DID R / R service 614, which may include the DID, the request type (e.g., a create / store indication)*, and the DID document registry ID / address. Notification message 640a may alternatively be referred to as a "DID registry notification message." At 640b, DID R / R service 614 records and stores the DID and DID document registry ID / address, and sends a DID resolver acknowledgment (Ack) message 640b to RS-DID DR 612, which may include the DID and a success indication.

[0127] At 642, RS-DID DR 612 may send a confirmation message 642 to L-RMS 604, which may include the L-RMS ID (e.g., received as part of a transaction message related to the DID document registry notification at 636), source identity, registry service type, registry service ID, DID document registry address, result indication (e.g., success or failure), DID resolver registry service ID, DID resolver registry server address*, etc. In implementation, 640a, 640b, and 642 are part of Option 1 for storing DIDs and DID documents. The second option is described below. Figure 7 Described in.

[0128] At 644, L-RMS 604 may store the DID, resolved ID, and / or address locally and / or off-chain. At 646, L-RMS 604 sends a DID document storage response message 646 to end client 602, which may include a DID resolver ID, address, and a result indication. For example, the result indication indicates success or failure as part of DID storage request 618.

[0129] Figure 7 A portion of a system 600 supporting digital identity management according to aspects of the present disclosure is illustrated. For example, this implementation of the system 600 represents an implementation of the system 600 described above with reference to Figure 6 Alternative or additional implementations discussed, such as as an alternative to using 640a, 640b described above. For example, the actions at 618-638, 642 are performed as described above. In addition, without implementing 640a, 640b, a DID resolver ID and / or address may be provided.

[0130] Thus, at 648, L-RMS 604 creates a DID resolver transaction notification message 648, which may include the DID, the DID document registry address, the DID resolver registry service ID and / or address, etc. In addition, transaction notification message 648 may be transformed into a DID resolver transaction to store the DID and the DID document registry address to a corresponding registry (e.g., a DID resolver registry) indicated by the target DID resolver registry service ID and / or address. Alternatively, L-RMS 604 may directly generate a DID resolver transaction, which may include a DID resolver transaction notification message 648, e.g., the DID, the DID document registry address, the DID resolver registry service ID / address, etc.

[0131] At 650, L-RMS 604 sends a DID resolver transaction including a DID resolver transaction notification message to PDL node 606, and at 652, PDL node 606 propagates the received DID resolver transaction through system 600. At 654, PDL node 608 (e.g., PDL node-2) receives the DID resolver transaction from the target PDL network as a result of transaction propagation 652.

[0132] Thus, the DID resolver transaction is validated and successfully stored in the ledger, e.g., as a result of a PDL consensus process in the ledger associated with the registry service associated with the DID resolver (transaction) based on the target registry service type information. Additionally, at 656, the PDL node 608 forwards the DID resolver transaction to a registry service (e.g., DID R / R service 614) based on the target registry service information. The DID R / R service 614 transforms the transaction into a message to recover the message, e.g., the DID resolver registry transaction as a DID resolver transaction notification message. Alternatively, the PDL node 608 transforms the transaction into a message and sends the DID resolver transaction as a DID resolver transaction notification message to the DID R / R service 614.

[0133] At 658, the DID R / R service 614 may store the DID resolver transaction / information received as part of the DID resolver transaction notification message (or vice versa) in local storage, off-chain storage, and / or as part of the ledger. At 660, the DID R / R service 614 sends a confirmation message 660 to the L-RMS 604, which may include the L-RMS ID, the DID, the DID resolver ID / address, and an indication of the result, e.g., an indication of the success or failure of the DID document storage request 618. In addition, 644, 646 may be performed as previously described after the execution of 648-660, for example, 648-660 may be performed as an alternative to 640a, 640b.

[0134] The following describes some implementation details and / or alternative or additional implementations of the system 600. In an implementation, as part of requesting a service from a service provider, the end client 602 may provide a DID resolver ID and / or address to enable the service provider to request the DID resolver for corresponding authentication of the end device.

[0135] In implementation, for failure situations of references 626 and 628, L-RMS 604 may send a DID document storage response message to the end client 602, which may include a failure indication with a reason value, such as a violation code, authorization failure, and authentication failure.

[0136] In implementations, adaptations may be made to enable a DID controller to perform DID document storage for a DID holder and / or subject (e.g., end client 602). For example, the various actions discussed with reference to system 600 may be applied with additional adaptations, i.e., steps 1, 622-638, and 642 may also include a source identity corresponding to a DID holder (e.g., subject) whose DID is being controlled by the DID controller. In addition, access role information specific to the DID controller may be used in the storage process shown in system 600.

[0137] In an implementation, updates to DIDs and DID documents may be adapted, for example, based on requests to DID holders and / or DID controllers. For example, at 618, the end client 602 may send a DID document update request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., to indicate a DID service), an access role (e.g., indicated as an ID / DID holder, which may be a principal and / or an end user; for a DID controller, the access role may be indicated as a "DID controller"), authorization information (e.g., a code and / or token received as authorization information during a successful registration), (multiple) DID documents, etc.

[0138] As an alternative or additional implementation, the end client 602 may send a DID document storage request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., to indicate a DID service), an access role (e.g., indicated as an ID / DID holder, which may be a subject and / or an end user), authorization information (e.g., a code and / or token received as authorization information during a successful registration), (multiple) DID documents, and a request type set as an update indication of the (multiple) DID documents.

[0139] 620-626: Same as described above.

[0140] 628, 630: The DID document registry notification message (e.g., together with the related transaction) may include, in addition to other information elements, a request type set to "update indication of (multiple) DID documents" (e.g., instead of a create / store indication).

[0141] 632-638: Same as described above.

[0142] 640a: The DID registry may send a notification message (e.g., a DID resolver notification message) to the DID R / R service 614, which may include the DID, a request type set to "Update indication of (multiple) DID documents"*, and a DID document registry ID and / or address.

[0143] 640b: DID R / R service 614 may update the DID document registry ID and / or address associated with the DID. In addition, DID R / R service 614 may send a DID resolver acknowledgment (Ack) message to the DID document registry service, which may include the DID and a success indication.

[0144] Steps 648-656: Same as described above.

[0145] In implementations, adaptation can be made for the deletion / revocation of DIDs and DID documents, such as based on requests from DID holders, DID controllers, ledger registry management services in PDL platforms, etc. In such implementations:

[0146] At 618, the end client 602 may send a DID document deletion / revocation request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as an ID and / or DID holder, which may be a subject and / or an end user; in an implementation of a DID controller, it may be indicated as a "DID controller"), authorization information (e.g., a code or token received as authorization information during a successful registration), (multiple) DID documents, etc.

[0147] In an alternative or additional implementation, the end client 602 may send a DID document storage request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as an ID and / or DID holder, which may be a principal / end user), authorization information (e.g., a code or token received as authorization information during a successful registration), (multiple) DID documents, and a request type set to a deletion / revocation indication of the (multiple) DID documents.

[0148] 620-626: Same as described above.

[0149] 628, 630: The DID Document Registry Notification message (and related transactions) may include, in addition to other information elements, a request type set to "deletion / revocation indication of (multiple) DID documents" (e.g., instead of a creation / storage indication).

[0150] 632-638: Same as described above.

[0151] 640a: The DID registry may send a notification message (e.g., a DID resolver notification message) to the DID R / R service 614, which may include the DID, a request type set to "deletion / revocation indication of (multiple) DID documents"*, and the DID document registry ID / address.

[0152] 640b: DID R / R service 614 deletes and / or revokes the DID document registry ID / address associated with the DID. In addition, DID R / R service 614 sends a DID resolver acknowledgment (Ack) message to RS-DID DR 612, which may include the DID and a success indication.

[0153] 648-646: Same as described above.

[0154] In implementation, the smart contract may be used by the registry service described in the different implementations to track lifetime expiration and linkage of DID-related entries.

[0155] The implementation described herein provides a way to manage VCs (e.g., store, update, delete / revoke), such as in a PDL platform, where a VC can represent a collection of one or more statements made by an issuer. For example, a VC is a tamper-proof credential with an author identity that can be cryptographically verified. A VC issuer is a role that an entity can perform by asserting statements about one or more subjects, creating a verifiable credential based on these statements, and sending the verifiable credential to a holder (e.g., a DID holder). VCs can be stored in a ledger on the PDL platform, respectively, based on requests from a DID holder, a DID controller, and / or a VC issuer. Therefore, a security process is provided for a requester DID holder, a DID controller, and / or a VC issuer:

[0156] If the requester is a DID holder, the requester is authenticated as identified by the DID and registration ID of the requester; otherwise, if the requester is a DID controller, the requester is authenticated as identified by the DID, source ID (ID of the DID holder and ID of the DID controller) and registration ID (of the DID controller); otherwise, if the requester is a VC issuer, the requester is authenticated as identified by the DID (of the DID holder), source ID (of the VC issuer) and registration ID (of the VC issuer).

[0157] The issuer of the VC proves that the claimed attribute belongs to the holder.

[0158] The VC issuer revokes the holder's attributes.

[0159] In addition, the management of VCs may include operations such as:

[0160] 1. Storage of VC (e.g., upon request from DID holder, DID controller, and / or VC issuer)

[0161] 2. Update of VC (e.g., based on a request from a DID holder, DID controller, and / or VC issuer)

[0162] 3. Deletion / revocation of VC (e.g., upon request from DID holder, DID controller, and / or VC issuer)

[0163] Figure 8 A system 800 supporting digital identity management according to aspects of the present disclosure is illustrated. For example, the system 800 represents an implementation for VC storage management and utilizes various features of the system 600 described above. In this particular example, the system 800 includes a registry service DID Document / VC Registry (RS-DID Doc / VC Reg) 801, which can provide registry services for DID documents and VCs.

[0164] At 802, the end client 602 (e.g., associated with a VC issuer) may send a VC storage request 802 to the L-RMS 604, the VC storage request 802 may include a source identity (e.g., a PDL user ID for the VC issuer), a registration ID (of the VC issuer), service type information (e.g., indicating a DID service), an access role (e.g., indicated as a VC issuer, which may be a principal and / or an end user), authorization information (e.g., a code and / or token received as authorization information during a successful registration), a DID, a VC, and a request type (e.g., set to create / store). In an implementation, if a secure connection exists, the end client 602 may send 802 directly. Otherwise, the end client 602 and the L-RMS 604 may perform mutual authentication and establish a secure connection before sending the VC storage request 802.

[0165] Alternatively, the end client 602 (e.g., VC issuer) may send information other than the registration ID, access role, DID, VC, and authorization code to the L-RMS 604 at 802. The L-RMS 604 may then request the information at 804 by sending an authorization request message with the source ID, and the end client 602 may respond at 804 with an authorization response message with the registration ID, access role, DID, VC, and authorization information.

[0166] At 806, L-RMS 604 sends an authorization verification request message 806 to RS-DID OP 610 based on local configuration and policies (e.g., related to DID operation (s) participants and / or identity and trust management framework / platform participants). The authorization verification request message 806 may include a registration ID, a source ID, an access role, and authorization information (e.g., a code and / or token for authorization).

[0167] At 808, RS-DID OP 610 verifies the authorization information (e.g., authorization code and / or token) associated with the registration ID and access role by querying the corresponding ledger and / or chain (e.g., for related transaction history and / or records) and / or by checking offline and / or local storage to check whether the authorization information and registration ID match the records associated with the participant being registered. RS-DID OP 610 also checks whether the participant's access role is correct based on the records.

[0168] At 810, if the verification of the registration ID, access role and authorization information is successful, RS-DID OP 610 sends an authorization verification response message 810 to L-RMS 604, which may include the registration ID (e.g., the VC issuer's), source ID, and the result of the authorization verification request message 806 (e.g., success or failure).

[0169] If the verification of the registration ID, access role, and authorization information does not match the records, and / or if the registered access role is different from the access role received using 806, the RS-DID OP 610 may send an authorization verification request message 810 to the L-RMS 604, which may include the registration ID, source ID, and a result of "failure".

[0170] At 812, if the L-RMS 604 determines that the authorization verification is successful (e.g., based on 810), the L-RMS 604 generates a VC registry notification message 814, which may include a target registry service type and / or ID, a creation indication*, an L-RMS ID, a source identity, service type information (DID service), a registration ID, an authorized access role, an authorization code, a lifetime, a DID, (multiple) VCs, etc. In addition, the VC registry notification message 814 may be transformed into a VC transaction to store the VC together with the corresponding DID to a corresponding registry (e.g., a "VC registry") indicated by the target registry service type and / or ID.

[0171] In an alternative or additional implementation, the L-RMS 604 may directly generate a VC transaction, which may include a VC registry notification message 814, e.g., a target registry service type and / or ID, a request type set to create / store indication*, an L-RMS ID, a source identity, service type information (DID service), a registration ID, an authorized access role, an authorization code, a lifetime, a DID, and (multiple) DID documents. Alternatively, for a failure indicated at 810, the system 800 may proceed to 828, where a failure condition is indicated.

[0172] The L-RMS 604 then sends the VC transaction (which includes the VC registry notification message 814) to the PDL node 606. At 816, the PDL node 606 propagates the received VC transaction through the system 800. At 818, the PDL node 608 (e.g., any PDL node-2) receives the VC transaction from the target PDL network as a result of the transaction propagation.

[0173] After the VC transaction is validated, the VC transaction is stored in the ledger, for example, as a result of a PDL consensus process in the ledger associated with the registry service associated with the VC transaction based on the target registry service type information. In addition, at 820, the PDL node 608 forwards the VC transaction to RS-DID Doc / VC Reg 801 (e.g., VC registry) based on the target registry service information. RS-DID Doc / VC Reg 801 transforms the transaction into a message to recover the message (e.g., the VC registry transaction as a VC registry notification message). In an alternative or additional implementation, the PDL node 608 transforms the VC transaction (which includes the VC registry notification message 814) into a message and sends the VC transaction to RS-DID Doc / VCReg 801 as a VC registry notification message.

[0174] At 822, RS-DID Doc / VC Reg 801 may store the VC transaction and / or information (e.g., DID and VC) received as part of 820 (or vice versa) in local storage, off-chain storage, and / or as part of the ledger. At 824, RS-DID Doc / VC Reg 801 sends a confirmation message 824 to L-RMS 604, which may include the L-RMS ID (e.g., received as part of the transaction and / or message related to the VC registry notification at 820), the source identity, the registry service type / ID, the VC registry address, and the result of the storage request (e.g., success or failure).

[0175] At 826, the L-RMS 604 maintains the DID and the associated VC registry ID / address information in a local storage device or off-chain. At 828, the L-RMS 604 sends a VC storage response message to the end client 602, which may include the DID and the result (e.g., success or failure) of the storage request 802. In an alternative implementation, for failure conditions occurring at 810, 812, the L-RMS 604 may send a VC storage response message to the end client 602, which may include a failure indication with a cause value (e.g., such as a violation code, authorization failure, authentication failure, etc.).

[0176] Implementations may include adaptations for a DID controller that performs VC storage for a DID holder and / or subject. For example, in system 800, 802-828 may be applied with additional adaptations, i.e., 802 and 806-826 may also include a source identity corresponding to a DID holder (e.g., a subject) whose DID is controlled by the DID controller. In addition, access role information specific to the DID controller may be used in the storage process shown in system 800.

[0177] The implementation may include adaptation for updating of VC (e.g., based on a request from a DID holder or a DID controller): for example, at 802, the end client 602 may send a VC update request to the L-RMS 604, which VC update request may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as an "ID / DID holder", which may be a subject and / or an end user, or in the scenario of a DID controller, indicated as a "DID controller"), authorization information (e.g., a code and / or token received as authorization information during a successful registration), a DID, (multiple) VCs, etc.

[0178] In an alternative or additional implementation, the end client 602 may send a VC storage request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as an "ID / DID holder", which may be a subject and / or an end user, or in the scenario of a DID controller, indicating a "DID controller"), authorization information (e.g., a code and / or token received as authorization information during a successful registration), a DID, (multiple) VCs, and a request type set as an update indication of the (multiple) VCs.

[0179] 804-810: Same as described above.

[0180] 812, 814: The VC registry notification message (and related transactions) may include, in addition to other information elements, a "request type set as an update indication of (multiple) VCs" (eg, instead of a create / store indication).

[0181] 816-828: Same as described above.

[0182] The implementation may include adaptation for deletion and revocation of VC (e.g., based on a request from a DID holder, a DID controller, a ledger registration management service in a PDL platform, etc.): for example, at 802, the end client 602 may send a VC deletion / revocation request to the L-RMS 604, which VC deletion / revocation request may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as an "ID / DID holder", which may be a principal / end user, and / or in the scenario of a DID controller, indicated as a "DID controller"), authorization information (e.g., a code and / or token received as authorization information during a successful registration), a DID, (multiple) VCs, etc.

[0183] In an alternative or additional implementation, the end client 602 may send a VC storage request to the L-RMS 604, which may include a source identity (e.g., a PDL user ID), a registration ID, service type information (e.g., indicating a DID service), an access role (e.g., indicated as "ID / DID holder", which may be a principal / end user, and / or in the scenario of a DID controller, indicated as "DID controller"), authorization information (e.g., a code and / or token received as authorization information during a successful registration), a DID, (multiple) VCs, and a request type set as a VC deletion / revocation indication.

[0184] 804-810: Same as described above.

[0185] 812, 814: The VC registry notification message (and related transactions) may include, in addition to other information elements, a request type set to a VC delete / remove indication (eg, instead of a create / store indication).

[0186] 816-828: Same as described above.

[0187] In implementation, the smart contract can be used by the registry service described in different implementations to track lifetime expiration and linking of DID related entries, etc.

[0188] Fig. 9An example of a block diagram 900 of a device 902 (e.g., an apparatus) supporting digital identity management according to aspects of the present disclosure is illustrated. The device 902 may be an example of a network entity 102 as described herein. The device 902 may support wireless communications with one or more network entities 102, UEs 104, or any combination thereof. The device 902 may include components for bidirectional communication including components for sending and receiving communications (such as a processor 904, a memory 906, a transceiver 908, and an I / O controller 910). These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., a bus).

[0189] The processor 904, the memory 906, the transceiver 908, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure described herein. For example, the processor 904, the memory 906, the transceiver 908, or various combinations thereof or components thereof may support methods for performing one or more of the operations described herein.

[0190] In some implementations, the processor 904, the memory 906, the transceiver 908, or various combinations or components thereof may be implemented in hardware (e.g., in a communication management circuit system). The hardware may include a processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, which is configured to or otherwise supports components for performing the functions described in the present disclosure. In some implementations, the processor 904 and the memory 906 coupled to the processor 904 may be configured to perform one or more functions described herein (e.g., the processor 904 executes instructions stored in the memory 906). For example, in the context of the network entity 102, the transceiver 908 and the processor 904 coupled to the transceiver 908 are configured to cause the network entity 102 to perform various described operations and / or combinations thereof.

[0191] For example, according to examples disclosed herein, the processor 904 and / or the transceiver 908 can support wireless communication at the device 902. For example, the processor 904 and / or the transceiver 908 can be configured to and / or otherwise support components for: receiving a storage request, the storage request including a storage object, and one or more of the following items: a source identifier, a registration identifier, service type information, an access role, authorization information, a decentralized identifier, or a request type; sending an authorization verification request for the storage request; receiving an authorization verification response based at least in part on the authorization verification request; sending a registry notification based at least in part on the authorization verification response, the registry notification including the storage object, and one or more of the following items: registry service information, request type, source identifier, service type information, registration identifier, or authorization information; receiving a confirmation message based at least in part on the registry notification; and sending a storage response, the storage response including an indication of a result of the storage request.

[0192] In addition, in some implementations, the storage object includes one or more of the following: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the apparatus is implemented as part of a ledger registry management service, and wherein the processor is configured to: receive a storage request from one or more of an endpoint device or application; send an authorization verification request to a registry service, and receive an authorization verification response from the registry service; send a registry notification to one or more of a permissioned distributed ledger node or a permissioned distributed ledger network; receive a confirmation message from the registry service; and send a storage response to one or more of the endpoint devices or applications; the registry notification also includes one of the following or more: an identifier for a ledger registry service, an authorized access role for a storage request, or a lifetime for a storage object; the registry service includes a decentralized identifier operation participant registry service; the processor is further configured to send a registry notification transaction to a permissioned distributed ledger node, wherein the registry notification transaction includes one or more of the following items: a registry service type, a registry service identifier, a ledger registry service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for a storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information.

[0193] Additionally, in some implementations, the lifetime includes a lifetime for at least one of the one or more decentralized identifier documents or the one or more verifiable credentials; the storage request is associated with one or more of the decentralized identifier or the decentralized identifier document, and the storage response further includes one or more of the following: a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address; the request type includes one or more of the following: a create indication, an update indication, or a delete indication; the authorization verification request includes one or more of the following: a registration identifier, a source identifier, an access role for the storage request, or authorization information; The authorization information includes one or more of a code or a token; the authorization verification response includes one or more of the following: a registration identifier, a source identifier, or an indication of a result for an authorization verification request; the processor is further configured to perform message-to-transaction adaptation to transform a registry notification into a registry notification transaction; the registry notification is associated with one or more of a decentralized identifier document or a verifiable credential; the access role indicates whether the storage request is initiated by one or more of the following: an identity holder, an identity controller, a decentralized identifier holder, a decentralized identifier controller, or a verifiable credential issuer; the indication of the result of the storage request includes an indication of the success of the storage request; the indication of the result of the storage request includes an indication of the failure of the storage request.

[0194] In another example, according to examples disclosed herein, the processor 904 and / or the transceiver 908 may support wireless communication at the device 902. For example, the processor 904 and / or the transceiver 908 may be configured to or otherwise support components for: receiving an authorization verification request for a storage request for a storage object, the authorization verification request including one or more of the following: a registration identifier, a source identifier, an access role associated with the storage request, or an authorization code; processing the authorization verification request to determine whether the authorization verification request is valid; and sending an authorization verification response including an indication of a result of the authorization verification request and one or more of the following: a registration identifier or a source identifier.

[0195] In addition, in some implementations, the storage object includes one or more of the following items: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the device is implemented as part of a registry service, and wherein the processor is configured to: receive an authorization verification request from the ledger registration management service; and send an authorization verification response to the ledger registration management service; the indication of the result of the authorization verification request includes one of an indication of success of the authorization verification request or an indication of failure of the authorization verification request.

[0196] In another example, according to examples disclosed herein, the processor 904 and / or the transceiver 908 may support wireless communication at the device 902. For example, the processor 904 and / or the transceiver 908 may be configured to or otherwise support components for: receiving a registry notification transaction, wherein the registry notification transaction includes a storage object, and one or more of the following: a registry service type, a registry service identifier, a ledger registry management service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for the storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information; logging the registry notification transaction; and sending a confirmation message, the confirmation message including an indication of a result of the registry notification transaction, and one or more of the following: a registry service type, a registry service identifier, a storage object registry address, a storage object resolver identifier, or a storage object resolver address.

[0197] In addition, in some implementations, the storage object includes one or more of the following items: a decentralized identifier, a decentralized identifier document, or a verifiable credential; the device is implemented as part of a storage object registry service, and wherein the processor is configured to: receive a registry notification transaction from a permissioned distributed ledger node; and send a confirmation message to the ledger registry management service; the indication of the result of the registry notification transaction includes one of an indication of the success of the registry notification transaction or an indication of the failure of the registry notification transaction.

[0198] In another example, according to examples disclosed herein, the processor 904 and / or the transceiver 908 may support wireless communication at the device 902. For example, the processor 904 and / or the transceiver 908 may be configured to or otherwise support components for: sending a decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a request type, a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address; and receiving a confirmation message including a result of the decentralized identifier resolver transaction notification, and one or more of the following: a ledger registry management service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address.

[0199] Furthermore, in some implementations, the result of the decentralized identifier resolver transaction notification includes one of an indication of a success of the decentralized identifier resolver transaction notification or an indication of a failure of the decentralized identifier resolver transaction notification.

[0200] In another example, according to examples disclosed herein, the processor 904 and / or the transceiver 908 may support wireless communication at the device 902. For example, the processor 904 and / or the transceiver 908 may be configured to or otherwise support components for: receiving a decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address; storing at least some information included in the decentralized identifier resolver transaction notification; and sending a confirmation message including a result of the decentralized identifier resolver transaction notification, and one or more of the following: a ledger registry management service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address.

[0201] Furthermore, in some implementations, the result of the decentralized identifier resolver transaction notification includes one of an indication of a success of the decentralized identifier resolver transaction notification or an indication of a failure of the decentralized identifier resolver transaction notification.

[0202] The processor 904 may include an intelligent hardware device (e.g., a general purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some implementations, the processor 904 may be configured to operate a memory array using a memory controller. In some other implementations, the memory controller may be integrated into the processor 904. The processor 904 may be configured to execute computer-readable instructions stored in a memory (e.g., a memory 906) to cause the device 902 to perform various functions of the present disclosure.

[0203] The memory 906 may include random access memory (RAM) and read-only memory (ROM). The memory 906 may store computer-readable, computer-executable code, which includes instructions that, when executed by the processor 904, cause the device 902 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium (such as a system memory or another type of memory). In some implementations, the code may not be directly executable by the processor 904, but may cause a computer (e.g., when compiled and executed) to perform the functions described herein. In some implementations, the memory 906 may include, among other things, a basic I / O system (BIOS), which may control basic hardware operations or software operations, such as interaction with peripheral components or devices.

[0204] I / O controller 910 can manage input signals and output signals for device 902. I / O controller 910 can also manage peripheral devices that are not integrated into device 2402. In some implementations, I / O controller 910 can represent a physical connection or port to an external peripheral device. In some implementations, I / O controller 910 can utilize an operating system, such as

[0205] Or another known operating system. In some implementations, I / O controller 910 may be implemented as part of a processor such as processor M06. In some implementations, a user may interact with device 902 via I / O controller 910 or via hardware components controlled by I / O controller 910.

[0206] In some implementations, the device 902 may include a single antenna 912. However, in some other implementations, the device 902 may have more than one antenna 912 (e.g., multiple antennas), including multiple antenna panels or antenna arrays, which are capable of concurrently sending or receiving multiple wireless transmissions. The transceiver 908 may communicate bidirectionally via one or more antennas 912, wired or wireless links, as described herein. For example, the transceiver 908 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. The transceiver 908 may also include a modem that modulates packets, provides the modulated packets to one or more antennas 912 for transmission, and demodulates packets received from one or more antennas 912.

[0207] Fig.10 A flowchart of a method 1000 for supporting digital identity management according to aspects of the present disclosure is illustrated. The operations of the method 1000 may be implemented by the devices described herein or components thereof. For example, the operations of the method 1000 may be implemented by reference to Figures 1 to 9 The described network entity 102 performs. In some implementations, the device may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device may use dedicated hardware to perform various aspects of the described functions.

[0208] At 1002, the method may include receiving a storage request, the storage request including a storage object, and one or more of: a source identifier, a registration identifier, service type information, an access role, authorization information, a decentralized identifier, or a request type. The operations of 1002 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1002 may be implemented by reference to Figure 1 The described device is used to perform

[0209] At 1004, the method may include sending an authorization verification request for the storage request. The operations of 1004 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1004 may be described by reference to Figure 1 The described device is used to perform

[0210] At 1006, the method may include receiving an authorization verification response based at least in part on the authorization verification request. The operations of 1006 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1006 may be described by reference to Figure 1 The described device is used to perform

[0211] At 1008, the method may include sending a registry notification based at least in part on the authorization verification response, the registry notification including the storage object and one or more of the following: registry service information, request type, source identifier, service type information, registration identifier, or authorization information. The operations of 1008 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1008 may be implemented by reference to Figure 1 The described device is used to perform

[0212] At 1010, the method may include receiving a confirmation message based at least in part on the registry notification. The operations of 1010 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1010 may be described by reference to Figure 1 The described device is used to perform

[0213] At 1012, the method may include sending a storage response including an indication of the result of the storage request. The operations of 1012 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1012 may be implemented by reference to Figure 1 The described device is used to perform

[0214] Fig.11 A flowchart of a method 1100 for supporting digital identity management according to aspects of the present disclosure is illustrated. The operations of the method 1100 may be implemented by the devices described herein or components thereof. For example, the operations of the method 1100 may be implemented by reference to Figures 1 to 9 The described network entity 102 performs. In some implementations, the device may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device may use dedicated hardware to perform various aspects of the described functions.

[0215] At 1102, the method may include receiving an authorization verification request for a storage request for a storage object, the authorization verification request including one or more of the following: a registration identifier, a source identifier, an access role associated with the storage request, or an authorization code. The operations of 1102 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1102 may be described by reference to Figure 1 The described device is used to perform

[0216] At 1104, the method may include processing the authorization verification request to determine whether the authorization verification request is valid. The operations of 1104 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1104 may be described by reference to Figure 1 The described device is used to perform

[0217] At 1106, the method may include sending an authorization verification response, the authorization verification response including an indication of the result of the authorization verification request, and one or more of the following: a registration identifier or a source identifier. The operations of 1106 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1106 may be described by reference to Figure 1 The described device is used to perform

[0218] Fig.12 A flowchart of a method 1200 for supporting digital identity management according to aspects of the present disclosure is illustrated. The operations of the method 1200 may be implemented by the devices described herein or components thereof. For example, the operations of the method 1200 may be implemented by reference to Figures 1 to 9 The described network entity 102 performs. In some implementations, the device may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device may use dedicated hardware to perform various aspects of the described functions.

[0219] At 1202, the method may include receiving a registry notification transaction, wherein the registry notification transaction includes a storage object, and one or more of the following: a registry service type, a registry service identifier, a ledger registry service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for the storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information. The operations of 1202 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1202 may be performed by reference to Figure 1 The described device is used to perform

[0220] At 1204, the method may include recording a registry notification transaction. The operations of 1204 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1204 may be implemented by reference to Figure 1 The described device is used to perform

[0221] At 1206, the method may include sending a confirmation message including an indication of the result of the registry notification transaction and one or more of: a registry service type, a registry service identifier, a storage object registry address, a storage object resolver identifier, or a storage object resolver address. The operations of 1206 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1206 may be implemented by reference to Figure 1 The described device is used to perform

[0222] Fig.13 A flowchart of a method 1300 for supporting digital identity management according to aspects of the present disclosure is illustrated. The operations of the method 1300 may be implemented by the devices described herein or components thereof. For example, the operations of the method 1300 may be implemented by reference to Figures 1 to 9 The described network entity 102 performs. In some implementations, the device may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device may use dedicated hardware to perform various aspects of the described functions.

[0223] At 1302, the method may include sending a decentralized identifier resolver transaction notification, the decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a request type, a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address. The operations of 1302 may be performed according to examples described herein. In some implementations, aspects of the operations of 1302 may be implemented by reference to Figure 1 The described device is used to perform

[0224] At 1304, the method may include receiving a confirmation message including a result of the decentralized identifier resolver transaction notification and one or more of: a ledger registry service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address. The operations of 1304 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1304 may be implemented by reference to Figure 1 The described device is used to perform

[0225] Fig.14A flowchart of a method 1400 for supporting digital identity management according to aspects of the present disclosure is illustrated. The operations of the method 1400 may be implemented by the devices described herein or components thereof. For example, the operations of the method 1400 may be implemented by reference to Figures 1 to 9 The described network entity 102 performs. In some implementations, the device may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device may use dedicated hardware to perform various aspects of the described functions.

[0226] At 1402, the method may include receiving a decentralized identifier resolver transaction notification, the decentralized identifier resolver transaction notification including a decentralized identifier, and one or more of the following: a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address. The operations of 1402 may be performed according to examples described herein. In some implementations, aspects of the operations of 1402 may be implemented by reference to Figure 1 The described device is used to perform

[0227] At 1404, the method may include storing at least some of the information included in the decentralized identifier resolver transaction notification. The operations of 1404 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1404 may be described by reference to Figure 1 The described device is used to perform

[0228] At 1406, the method may include sending a confirmation message including the result of the decentralized identifier resolver transaction notification, and one or more of the following: a ledger registry service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address, and one or more of the following: a ledger registry service identifier, a decentralized identifier, a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address. The operations of 1406 may be performed according to the examples described herein. In some implementations, aspects of the operations of 1406 may be performed by reference to Figure 1 The described device is used to perform

[0229] It should be noted that the methods described herein describe possible implementations, and that the operations and steps may be rearranged or otherwise modified, and other implementations are possible. Furthermore, aspects from two or more methods may be combined.

[0230] The various illustrative blocks and components described in conjunction with the disclosure herein may be implemented or performed using a general purpose processor, a DSP, an ASIC, a CPU, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0231] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on a computer-readable medium or sent via a computer-readable medium as one or more instructions or codes. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described herein may be implemented using software executed by a processor, hardware, firmware, hard wiring, or any combination of these. Features that implement the functions may also be physically located in various locations, including being distributed so that portions of the functions are implemented at different physical locations.

[0232] Computer-readable media include both non-transient computer storage media and communication media, and communication media include any medium that facilitates the transfer of computer programs from one place to another. Non-transient storage media can be any available medium that can be accessed by a general-purpose computer or a special-purpose computer. By way of example and not limitation, non-transient computer-readable media can include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, disk storage or other magnetic storage devices, or can be used to carry or store desired program code components in the form of instructions or data structures and can be accessed by a general-purpose computer or a special-purpose computer, or any other non-transient medium of a general-purpose processor or a special-purpose processor.

[0233] Any connection may be appropriately referred to as a computer-readable medium. For example, if the software is sent from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave), the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology (such as infrared, radio, and microwave) is included in the definition of computer-readable medium. As used herein, disks and optical disks include CDs, laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically using lasers. Combinations of the above are also included within the scope of computer-readable media.

[0234] As used herein, including in the claims, "or" used in a list of items (e.g., a list of items beginning with a phrase such as "at least one of" or "one or more of" or "one or both of") indicates an inclusive list, so 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 (e.g., A and B and C). In addition, as used herein, the phrase "based on" may not be interpreted as a reference to a closed set of conditions. For example, an example step described as "based on condition A" may be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" may be interpreted in the same manner as the phrase "based at least in part on." In addition, as used herein, including in the claims, a "set" may include one or more elements.

[0235] When referring to a network entity, the terms "transmit," "receive," or "communicate" may refer to any part of a network entity of a RAN (e.g., base station, CU, DU, RU) that communicates with another device (e.g., directly or via one or more other network entities).

[0236] The descriptions set forth herein in conjunction with the accompanying drawings describe example configurations and do not represent all examples that may be implemented or within the scope of the claims. The term "example" as used herein means "used as an example, instance, or illustration," rather than "preferred" or "better than other examples." The specific implementation includes specific details for the purpose of providing an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some instances, known structures and devices are shown in block diagram form to avoid confusing the concepts of the described examples.

[0237] The description herein is provided to enable one of ordinary skill in the art to make or use the present disclosure. Various modifications to the present disclosure will be apparent to one of ordinary skill in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but should conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A network entity, comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to cause the network entity to: Receiving a storage request, the storage request comprising a storage object and one or more of the following: a source identifier, a registration identifier, service type information, an access role, authorization information, a decentralization identifier, or a request type; Sending an authorization verification request for the storage request; receiving an authorization verification response based at least in part on the authorization verification request; sending a registry notification based at least in part on the authorization verification response, the registry notification including the storage object and one or more of: registry service information, the request type, the source identifier, the service type information, the registration identifier, or authorization information; receiving a confirmation message based at least in part on the registry notification; as well as A storage response is sent, the storage response including an indication of a result of the storage request.

2. The network entity of claim 1, wherein the stored object comprises one or more of the following: a decentralized identifier, a decentralized identifier document, or a verifiable credential.

3. The network entity of claim 1 , wherein the network entity is implemented as part of a ledger registry management service, and wherein the at least one processor is configured to cause the network entity to: receiving the storage request from one or more of an endpoint device or an application; sending the authorization verification request to a registry service, and receiving the authorization verification response from the registry service; sending the registry notification to one or more of the permissioned distributed ledger nodes or permissioned distributed ledger networks; receiving the confirmation message from the registry service; as well as The stored response is sent to one or more of the endpoint device or the application.

4. The network entity of claim 3, wherein the registry notification further comprises one or more of: an identifier for the ledger registry management service, an authorized access role for the storage request, or a lifetime for the storage object.

5. The network entity of claim 3, wherein the registry service comprises a decentralized identifier operator participant registry service.

6. The network entity of claim 3, wherein the at least one processor is configured to cause the network entity to send a registry notification transaction to the permissioned distributed ledger node, wherein the registry notification transaction comprises one or more of: a registry service type, a registry service identifier, a ledger registry management service identifier, the source identifier, the service type information, the registration identifier, an authorized access role, the authorization information, a lifetime for the storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information.

7. The network entity of claim 6, wherein the lifespan comprises a lifespan for at least one of one or more decentralized identifier documents or one or more verifiable credentials.

8. A network entity according to claim 1, wherein the storage request is associated with one or more of a decentralized identifier or a decentralized identifier document, and the storage response also includes one or more of the following items: a decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or a decentralized identifier resolver address.

9. The network entity of claim 1, wherein the request type comprises one or more of the following: a create indication, an update indication, or a delete indication.

10. The network entity of claim 1, wherein the authorization verification request comprises one or more of: the registration identifier, the source identifier, an access role for the storage request, or authorization information. The network entity according to claim 10 , wherein the authorization information comprises one or more of a code or a token.

12. The network entity of claim 1, wherein the authorization verification response comprises one or more of: the registration identifier, the source identifier, or a result indication for the authorization verification request.

13. The apparatus of claim 1, wherein the processor is further configured to perform message-to-transaction adaptation to transform the registry notification into a registry notification transaction.

14. The network entity of claim 1, wherein the registry notification is associated with one or more of a decentralized identifier document or a verifiable credential.

15. The network entity of claim 1, wherein the access role indicates whether the storage request is initiated by one or more of: an identity holder, an identity controller, a decentralized identifier holder, a decentralized identifier controller, or a verifiable credential issuer.

16. The network entity of claim 1, wherein the indication of the result of the storage request comprises an indication of success of the storage request.

17. The network entity of claim 1, wherein the indication of the result of the storage request comprises an indication of a failure of the storage request.

18. A network entity, comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to cause the network entity to: Receiving an authorization verification request for a storage request for a storage object, the authorization verification request comprising one or more of the following: a registration identifier, a source identifier, an access role associated with the storage request, or an authorization code; processing the authorization verification request to determine whether the authorization verification request is valid; as well as An authorization verification response is sent, the authorization verification response including an indication of a result of the authorization verification request and one or more of: the registration identifier or the source identifier.

19. A network entity comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to cause the network entity to: receiving a registry notification transaction, wherein the registry notification transaction includes a storage object, and one or more of: a registry service type, a registry service identifier, a ledger registry service identifier, a source identifier, service type information, a registration identifier, an authorized access role, authorization information, a lifetime for the storage object, a decentralized identifier, a decentralized identifier document, a verifiable credential, or request type information; Recording the registry notification transaction; as well as A confirmation message is sent, the confirmation message including an indication of the result of the registry notification transaction and one or more of: a registry service type, a registry service identifier, a storage object registry address, a storage object resolver identifier, or a storage object resolver address.

20. A network entity, comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to cause the network entity to: sending a decentralized identifier resolver transaction notification, the decentralized identifier resolver transaction notification including a decentralized identifier and one or more of: a request type, a decentralized identifier registry address, a decentralized identifier resolver identifier, or a decentralized identifier resolver address; as well as Receiving a confirmation message, the confirmation message including a result of the decentralized identifier resolver transaction notification and one or more of: a ledger registry service identifier, the decentralized identifier, the decentralized identifier resolver identifier, a decentralized identifier document registry address, a decentralized identifier document registry identifier, or the decentralized identifier resolver address.

Images