Control over delegated use of DID-related data

Abstract

Embodiments disclosed herein relate to computing systems and methods for DID owner control of delegated use of DID-related data. A delegation permission is attached to a DID-related data object provided by a DID owner to a first third-party entity. The delegation permission specifies interactions that should occur between the DID owner and a second third-party entity that receives the DID-related data object from the first third-party entity. The DID-related data object is provided to the first third-party entity. Various interactions are received from the second third-party entity that attempts to use the DID-related data object. The second third-party entity is allowed to use the DID-related data object when the received interactions satisfy the delegation permission.

Description

Background Technology

[0001] Most currently used identity verification documents or records are issued by centralized organizations (such as governments, schools, employers, or other service centers or regulatory bodies). These organizations typically maintain the identity of each member within a centralized identity management system. A centralized identity management system is a centralized information system used by organizations to manage issued identities and their authentication, authorization, roles, and permissions. Centralized identity management systems are generally considered secure because they typically use professionally maintained hardware and software. Typically, the identity issuing organization sets terms and requirements for those registering with the organization. When one party needs to verify the identity of another, the verifying party often needs to obtain information for verifying and / or authenticating the other party's identity through a centralized identity management system.

[0002] Decentralized Identifiers (DIDs) are a new type of identifier that is independent of any centralized registry, identity provider, or authentication authority. Distributed ledger technologies, such as blockchain, provide the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a globally distributed ledger to verifiably record transactions between two or more parties. Once a transaction is recorded, data in the ledger cannot be traced back without altering all subsequent parts of the ledger, providing a fairly secure platform. Because DIDs are typically not controlled by a centralized management system but are owned by the DID's owner, they are sometimes referred to as authorizationless identities.

[0003] The subject matter claimed herein is not limited to embodiments that address any shortcomings or operate only in environments such as those described above. Rather, this background is provided merely to illustrate an example technical field in which some of the embodiments described herein can be implemented. Summary of the Invention

[0004] This synopsis is provided to introduce a set of concepts in a simplified form, which will be further described in the detailed embodiments below. This synopsis is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter.

[0005] The embodiments disclosed herein relate to a computing system and method for a DID owner to control the delegated use of DID-related data. A delegation license is attached to a DID-related data object provided by the DID owner to a first third-party entity. The delegation license specifies the interactions that should occur between the DID owner and a second third-party entity, which receives the DID-related data object from the first third-party entity. The DID-related data object is provided to the first third-party entity. Various interactions are received from the second third-party entity attempting to use the DID-related data object. When the received interactions satisfy the delegation license, the second third-party entity is permitted to use the DID-related data object.

[0006] Additional features and advantages will be set forth in the description which follows, and will be apparent in part from that description, or may be learned by practice of the teachings herein. The features and advantages of the invention can be realized and obtained by means of the tools and combinations particularly pointed out in the appended claims. The features of the invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as set forth below. Attached Figure Description

[0007] To illustrate how the aforementioned and other advantages and features can be obtained, the subject matter briefly described above will be described in more detail with reference to specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments and are therefore not intended to be limiting in scope. Additional specific and detailed descriptions and explanations of the embodiments will be provided using the accompanying drawings, in which:

[0008] Figure 1 An example computing system in which the principles described herein can be employed is shown;

[0009] Figure 2 An example environment for creating decentralized identifiers (DIDs) is shown;

[0010] Figure 3 An example environment for various DID management operations and services is shown;

[0011] Figure 4 An example of a decentralized storage device or identity center is shown;

[0012] Figure 5A and Figure 5B An example embodiment of a computing system environment for delegated use of DID-related data by a DID owner is shown; and

[0013] Figure 6 A flowchart is shown illustrating an example method used by the DID owner to delegate control over DID-related data. Detailed Implementation

[0014] The embodiments disclosed herein relate to a computing system and method for a DID owner to control the delegated use of DID-related data. A delegation license is attached to a DID-related data object provided by the DID owner to a first third-party entity. The delegation license specifies the interactions that should occur between the DID owner and a second third-party entity, which receives the DID-related data object from the first third-party entity. The DID-related data object is provided to the first third-party entity. Various interactions are received from the second third-party entity attempting to use the DID-related data object. When the received interactions satisfy the delegation license, the second third-party entity is permitted to use the DID-related data object.

[0015] The embodiments disclosed herein represent a technological advancement relative to existing systems. For example, a DID owner may wish to provide his or her DID-related data objects, such as videos, images, documents, etc., to a first third-party entity known to the DID owner. However, the first third-party entity can subsequently provide the DID-related data objects to one or more second third-party entities without the DID owner's permission, and the DID owner may not be aware of these one or more second third-party entities. Attaching various delegated permissions to the DID-related data objects allows the DID owner to retain at least some level of control over the data. Before allowing one or more second third-party entities access to the DID-related data, the DID owner can specify what type of information he or she wants to receive from these entities. This increases user convenience and productivity because the DID owner and the one or more second third-party entities know what will happen if the DID-related data is used. One or more second third-party entities are not required to provide unwanted information, which in turn reduces unnecessary interactions between parties, saving time and reducing the use of processing resources.

[0016] Because the principles described in this article can be executed within the context of a computing system, references will be made. Figure 1 This section provides an introductory discussion of the computing system. The description then returns to the principles of the decentralized identifier (DID) platform, as outlined in the remaining figures.

[0017] Computing systems are increasingly taking on a wide variety of forms. A computing system can be, for example, a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) comprising at least one physical and tangible processor and physical and tangible memory capable of having computer-executable instructions thereon that can be executed by the processor. The memory can take any form and can depend on the nature and form of the computing system. Computing systems can be distributed across a network environment and can comprise multiple constituent computing systems.

[0018] like Figure 1 As shown, in its most basic configuration, computing system 100 typically includes at least one hardware processing unit 102 and memory 104. Processing unit 102 may include a general-purpose processor and may also include a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or any other special-purpose circuitry. Memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of both. The term "memory" may also be used herein to refer to a non-volatile mass storage device such as a physical storage medium. If the computing system is distributed, processing, memory, and / or storage capacity may also be distributed.

[0019] The computing system 100 also has multiple structures thereon, which are generally referred to as "executable components". For example, the memory 104 of the computing system 100 is shown to include executable component 106. The term "executable component" is a name for a structure well known to those skilled in the art of computing, which can be software, hardware, or a combination thereof. For example, when implemented in software, those skilled in the art will understand that the structure of an executable component can include software objects, routines, methods, etc., that can be executed on the computing system, whether such executable component is present in the heap of the computing system or on a computer-readable storage medium.

[0020] In this context, those skilled in the art will recognize that the structure of an executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by processor threads), it enables the computing system to perform functions. Such a structure can be directly computer-readable by the processor (as if the executable component were binary). Alternatively, the structure can be constructed to be interpretable and / or compileable (whether in a single-level or multi-level system) to generate such binary data that can be directly interpreted by the processor. This understanding of an example structure of an executable component is entirely within the scope of what those skilled in the art of computing would understand when using the term "executable component."

[0021] Those skilled in the art will readily understand that the term "executable component" includes structures implemented exclusively or nearly exclusively in hardware (such as within a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or any other dedicated circuitry), such as hard-coded or hard-wired logic gates. Therefore, the term "executable component" is a term for structures well-known to those skilled in the art of computing, whether implemented in software, hardware, or a combination thereof. In this specification, the terms "component," "agent," "manager," "service," "engine," "module," "virtual machine," etc., may also be used. As used in this specification and in this example, these terms (whether or not they are modified by a clause) are also intended to be synonymous with the term "executable component" and therefore also have structures well-understood by those skilled in the art of computing.

[0022] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If such actions are implemented in software, one or more processors (of the associated computing system performing the action) instruct the operation of the computing system in response to the execution of computer-executable instructions constituting an executable component. For example, such computer-executable instructions may be implemented on one or more computer-readable media forming a computer program product. Examples of such operations involve manipulation of data. If such actions are implemented exclusively or almost exclusively in hardware, such as within an FPGA or ASIC, the computer-executable instructions may be hard-coded or hard-wired logic gates. The computer-executable instructions (and the manipulated data) may be stored in memory 104 of computing system 100. Computing system 100 may also include a communication channel 108 that allows computing system 100 to communicate with other computing systems via, for example, network 110.

[0023] While not all computing systems require a user interface, in some embodiments, computing system 100 includes a user interface system 112 for interaction with a user. User interface system 112 may include an output mechanism 112A and an input mechanism 112B. The principles described herein are not limited to the precise output mechanism 112A or input mechanism 112B, and will therefore depend on the nature of the device. However, output mechanism 112A may include, for example, a speaker, display, haptic output, virtual or augmented reality, hologram, etc. Examples of input mechanism 112B may include, for example, a microphone, touchscreen, virtual or augmented reality, hologram, camera, keyboard, mouse or other pointer input, any type of sensor, etc.

[0024] The embodiments described herein may include or utilize dedicated or general-purpose computing systems including computer hardware, such as one or more processors and system memory, as discussed in more detail below. The embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available medium that can be accessed by a general-purpose or dedicated computing system. A computer-readable medium storing computer-executable instructions is a physical storage medium. A computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: storage media and transmission media.

[0025] Computer-readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other physical and tangible storage medium that can be used to store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computing system.

[0026] A “network” is defined as one or more data links that enable the transmission of electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or another communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computing system correctly regards that connection as a transmission medium. Transmission media may include networks and / or data links, which may be used to carry desired program code in the form of computer-executable instructions or data structures, and may be accessible by general-purpose or special-purpose computing systems. Combinations of the foregoing should also be included within the scope of computer-readable media.

[0027] Furthermore, upon arrival at various computing system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be cached in the RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computing system RAM and / or a less volatile storage medium at the computing system. Therefore, it should be understood that storage media can be included in computing system components that also (or even primarily) utilize the transmission medium.

[0028] Computer-executable instructions include, for example, instructions and data that, when executed at a processor, cause a general-purpose computing system, a special-purpose computing system, or a special-purpose processing device to perform a specific function or group of functions. Alternatively or additionally, computer-executable instructions can configure a computing system to perform a specific function or group of functions. Computer-executable instructions can be, for example, binary instructions or even instructions that have undergone some form of translation (such as compilation) before being directly executed by a processor, such as intermediate format instructions in assembly language, or even source code.

[0029] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. Rather, the described features and actions are disclosed as exemplary forms for implementing the claims.

[0030] Those skilled in the art will understand that this invention can be implemented in network computing environments with many types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses), etc. This invention can also be practiced in distributed system environments, where both local and remote computing systems perform tasks via network links (or via hardwired data links, wireless data links, or a combination of hardwired and wireless data links). In a distributed system environment, program modules can reside in local and remote memory storage devices.

[0031] Those skilled in the art will also understand that the present invention can be implemented in a cloud computing environment. A cloud computing environment may be distributed, although this is not required. When distributed, a cloud computing environment may be internationally distributed within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the many other advantages that can be derived from such a model when properly deployed.

[0032] The remaining figures may discuss various computing systems that may correspond to the previously described computing system 100. The computing systems in the remaining figures include various components or functional blocks that can implement the various embodiments disclosed herein as will be explained. These various components or functional blocks may be implemented on a local computing system or on a distributed computing system that includes elements residing in the cloud or aspects implementing cloud computing. The various components or functional blocks may be implemented as software, hardware, or a combination of software and hardware. The computing systems in the remaining figures may include more or fewer components than those shown in the figures, and some components may be combined where circumstances permit.

[0033] Now refer to Figure 2 This section provides an introductory discussion of decentralized identifiers (DIDs) and the environments in which they are created and reside. Figure 2 A portion of decentralized network 200 is shown. For example... Figure 2 As shown, DID owner 201 can own or control DID 205, which represents the identity of DID owner 201. DID owner 201 can register DIDs using the creation and registration service, which will be explained in more detail below.

[0034] The DID owner 201 can be any entity that can benefit from the DID. For example, the DID owner 201 can be a person or an organization of a person. Such an organization can include a corporation, department, government, agency, or any other organization or group of organizations. Each individual can have a DID, and the organizations(s) to which each person belongs can also have DIDs.

[0035] DID owner 201 may alternatively be a machine, system, or device, or a collection of machines, devices, and / or systems. In other embodiments, DID owner 201 may be a sub-component of a machine, system, or device. For example, a device may be a printed circuit board, wherein sub-components of the circuit board are the various components of the circuit board. In such embodiments, the machine or device may have a DID, and each sub-component may also have a DID. The DID owner may also be a software component, such as those referenced above. Figure 1The executable component 106 is described. An example of a complex executable component 106 could be artificial intelligence. Therefore, an artificial intelligence device could also have a DID.

[0036] Therefore, the DID owner 201 can be any entity, human or non-human, capable of creating DID 205 or having at least DID 205 created for and / or associated with it. Although the DID owner 201 is shown to have a single DID 205, this is not required, as any number of DIDs may exist associated with the DID owner 201 where circumstances permit.

[0037] As described above, DID owner 201 can create and register DID 205. DID 205 can be any identifier that can be associated with DID owner 201. Preferably, the identifier is unique to the DID owner 201, at least within the scope of the DID's intended use. As an example, the identifier can be a locally unique identifier, and perhaps more ideally, a globally unique identifier of an identity system intended for global operation. In some embodiments, DID 205 can be a Uniform Resource Identifier (URI) (such as a Uniform Resource Locator (URL)) or other pointers to mechanisms that associate DID owner 201 with trusted interactions with DID owner 201.

[0038] DID 205 is "decentralized" because it does not require a centralized, third-party management system for its generation, management, or use. Therefore, DID 205 remains under the control of the DID owner 201. This differs from traditional centralized IDs, which are based on centralized authorizing authorities and remain under the control of company directory services, certification authorities, domain name registries, or other centralized authorizing authorities (collectively referred to here as "centralized authorizing authorities"). Therefore, DID 205 can be any identifier under the control of the DID owner 201 and independent of any centralized authorizing authority.

[0039] In some embodiments, the structure of DID 205 can be as simple as a username or some other human-understandable term. However, in other embodiments, for enhanced security, DID 205 is preferably a random string of numbers and letters. In one embodiment, DID 205 can be a string of 128 numbers and letters. Therefore, the embodiments disclosed herein do not depend on any specific implementation of DID 205. In a very simple example, DID 205 is shown as "123ABC" in the figure.

[0040] For example Figure 2As shown, DID owner 201 controls the private key 206 and public key 207 pair associated with DID 205. Because DID 205 is independent of any centralized authority, private key 206 should always be fully controlled by DID owner 201. That is, the private and public keys should be generated in a decentralized manner to ensure they remain under the control of DID owner 201.

[0041] As will be described in more detail below, the private key 206 and public key 207 pair can be generated on a device controlled by the DID owner 201. The private key 206 and public key 207 pair should not be generated on a server controlled by any centralized authority, as this could result in the private key 206 and public key 207 pair not always being entirely under the control of the DID owner 201. Although Figure 2 While the private and public key pairs have been described in this specification, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may be used when circumstances permit.

[0042] Figure 2 A DID document 210 associated with DID 205 is also shown. As will be explained in more detail below, DID document 210 can be generated when DID 205 is created. In its simplest form, DID document 210 describes how DID 205 will be used. Therefore, DID document 210 includes a reference to DID 205, which is the DID described by DID document 210. In some embodiments, DID document 210 may be implemented according to a method specified by a distributed ledger 220 (such as a blockchain), which will be used to store a representation of DID 205, as will be explained in more detail later. Therefore, DID document 210 may have different methods depending on the specific distributed ledger.

[0043] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 can be used by a third-party entity that has been granted permission by DID owner 201 to access the information and data owned by DID owner 201. Public key 207 can also be used to verify that DID owner 201 actually owns or controls DID 205.

[0044] DID document 210 may also include authentication information 211. Authentication information 211 may specify one or more mechanisms by which DID owner 201 can prove that DID owner 201 owns DID 205. In other words, the mechanisms of authentication information 211 can show evidence of the binding between DID 205 (and thus its DID owner 201) and DID document 210. In one embodiment, authentication information 211 may specify the use of public key 207 in a signing operation to prove ownership of DID 205. Alternatively or additionally, authentication information 211 may specify the use of public key 207 in a biometric operation to prove ownership of DID 205. Therefore, authentication information 211 may include any number of mechanisms by which DID owner 201 can prove that DID owner 201 owns DID 205.

[0045] DID document 210 may also include authorization information 212. Authorization information 212 may allow DID owner 201 to authorize a third-party entity to modify DID document 210 or certain portions of the document without granting the third party the right to prove ownership of DID 205. For example, authorization information 212 may allow a third party to use any specified update mechanism to update any specified set of one or more fields in DID document 210. Alternatively, the authorization information may allow a third party to restrict DID owner 201's use of DID 205 for a specified period. This may be useful when DID owner 201 is a minor child and the third party is the child's parent or guardian. Authorization information 212 may allow the parent or guardian to restrict DID owner 201's use until the child is no longer a minor.

[0046] The authorization information 212 may also specify one or more mechanisms that third parties will need to follow to prove that they are authorized to modify the DID document 210. In some embodiments, these mechanisms may be similar to those previously discussed with respect to the authentication information 211.

[0047] DID document 210 may also include one or more service endpoints 213. A service endpoint may include a network address of a service operating in the name of DID owner 201. Examples of specific services include discovery services, social networks, file storage services such as identity servers or central hubs, and verifiable claim repository services. Therefore, service endpoints 213 serve as pointers to services operating in the name of DID owner 201. These pointers can be used by DID owner 201 or third-party entities to access services operating in the name of DID owner 201. Specific examples of service endpoints 213 will be explained in more detail below.

[0048] DID document 210 may also include identification information 214. Identification information 214 may include personally identifiable information, such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Therefore, the identification information 214 listed in DID document 210 may represent different roles of the DID owner 201 for different purposes.

[0049] Roles can be pseudo-anonymous. For example, when identifying DID owner 201 as the author of an article published on a blog, he or she may include a pseudonym in the DID document. Roles can be completely anonymous. For example, DID owner 201 may only want to disclose his or her title or other background information (e.g., school teacher, FBI agent, adult over 21, etc.) in the DID file, without disclosing his or her name. As yet another example, a role can be specific to who DID owner 201 is as an individual. For example, DID owner 201 may include information identifying him or her as a volunteer for a specific charity, an employee of a specific company, a recipient of a specific award, etc.

[0050] DID document 210 may also include verification information 215. Verification information 215 may be any information associated with the background of DID owner 201. For example, verification information 215 may be (but is not limited to) qualifications, achievements, government ID, government rights such as a passport or driver's license, payment provider or bank account, university degree or other educational history, employment status and history, or any other information about the background of DID owner 201. In some embodiments, DID owner 201 collects various signed credentials included in the verification information from different third-party entities.

[0051] DID document 210 may also include various other information 216. In some embodiments, other information 216 may include metadata specifying when DID document 210 was created and / or when it was last modified. In other embodiments, other information 216 may include cryptographic proof of the integrity of DID document 210. In still other embodiments, other information 216 may include additional information specified by a particular method of implementing the DID document or expected by DID owner 201.

[0052] Figure 2 Distributed ledger 220 is also shown. Distributed ledger 220 can be any decentralized distributed network comprising various computing systems communicating with each other. For example, distributed ledger 220 may include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems, as shown in ellipsis 260. Distributed ledger 220 can operate according to any known standards or methods for distributed ledgers.

[0053] In the context of DID 205, the distributed ledger or blockchain 220 is used to store a representation of DID 205 pointing to DID document 210. In some embodiments, DID document 210 may be stored on the actual distributed ledger. Alternatively, in other embodiments, DID document 210 may be stored in a data storage device (not shown) associated with distributed ledger 220.

[0054] As described above, the representation of DID 205 is stored on each distributed computing system of the distributed ledger 220. For example, in Figure 2 In this diagram, these are shown as DID hash 231, DID hash 241, and DID hash 251, which are ideally identical hash copies of the same DID. DID hash 231, DID hash 241, and DID hash 251 can then point to the location of DID document 210. The distributed ledger or blockchain 220 can also store many other representations of other DIDs, as shown by reference numerals 232, 233, 234, 242, 243, 244, 252, 253, and 254.

[0055] In one embodiment, when DID owner 201 creates DID 205 and the associated DID document 210, DID hashes 231, 241, and 251 are written to the distributed ledger 220. Therefore, the distributed ledger 220 records that DID 205 now exists. Because the distributed ledger 220 is decentralized, DID 205 is not under the control of any entity other than DID owner 201. In addition to a pointer to DID document 210, each DID hash in DID hashes 231, 241, and 251 may also include a record or timestamp specifying when DID 205 was created. On subsequent dates, when DID document 210 is modified, each modification (and possibly including a timestamp of the modification) may also be recorded in DID hashes 231, 241, and 251. DID hash 231, DID hash 241 and DID hash 251 may also include a copy of public key 207, so that DID 205 is cryptographically bound to DID document 210.

[0056] Reference Figure 2 Having described DID and how it generally works, we will now explain specific implementations of a DID environment. Now, let's move on to... Figure 3 This will explain the computing system environment 300 that can be used to perform various DID management operations and services. It should be understood that, for ease of explanation, Figure 3 The environment can be referenced as needed. Figure 2 The components in.

[0057] like Figure 3 As shown, environment 300 may include various devices and computing systems that can be owned or controlled by DID owner 201. These devices may include user device 301. User device 301 may be, but is not limited to, mobile devices such as smartphones, computing devices such as laptop computers, or any device such as automobiles or electrical appliances that include computing capabilities. Device 301 may include a web browser 302 operating on the device and an operating system 303 operating the device. More broadly, the dashed line 304 indicates that all these devices may be owned or otherwise controlled by DID owner 201.

[0058] Environment 300 also includes a DID management module 320. It should be noted that in operation, the DID management module 320 may reside on and be executed by one or more of the user device 301, web browser 302, and operating system 303, as shown in corresponding lines 301a, 302a, and 303a. Therefore, for ease of explanation, the DID management module 320 is shown as separate. In some embodiments, the management module 320 may be referred to as a "digital wallet" or a "user agent."

[0059] like Figure 3 As shown, the DID management module 320 includes a DID creation module 330. The DID creation module 330 can be used by the DID owner 201 to create DID 205 or any number of additional DIDs, such as DID 331. In one embodiment, the DID creation module may include, or otherwise access, a user interface (UI) element 335 that can guide the DID owner 201 in creating DID 205. The DID creation module 330 may have one or more drivers configured to work with a specific distributed ledger, such as distributed ledger 220, such that DID 205 conforms to the underlying methodology of that distributed ledger.

[0060] Specific embodiments will now be described. For example, UI 335 may provide a prompt to the user to enter a username or some other human-recognizable name. This name may be used as the display name for the DID 205 to be generated. As previously mentioned, DID 205 may be a long string of random numbers and letters, so having a human-recognizable name for the display name may be advantageous. DID creation module 330 can then generate DID 205. In an embodiment with UI 335, DID 205 may be displayed in an identity list and may be associated with a human-recognizable name.

[0061] The DID creation module 330 may also include a key generation module 350. The key generation module can generate the aforementioned private key 206 and public key 207 pair. Then, the DID creation module 330 can use the DID 205 and the private and public key pair to generate a DID document 210.

[0062] In operation, the DID creation module 330 accesses the registrar 310, which is configured to record a specific distributed ledger associated with DID 205. The DID creation module 330 uses the registrar 310 to record DID hash 231, DID hash 241, and DID hash 251 in the distributed ledger as described above, and stores the DID document 210 as described above. This process can utilize the public key 207 in hash generation.

[0063] In some embodiments, the DID management module 320 may include an ownership module 340. The ownership module 340 can provide a mechanism to ensure that the DID owner 201 has complete control over DID 205. In this way, the provider of the DID management module 320 can ensure that the provider does not control DID 205 but only provides management services.

[0064] As previously described, the key generation module 350 generates a private key pair 206 and a public key pair 207, and then the public key 207 is recorded in the DID document 210. Therefore, the public key 207 can be used by all devices associated with the DID owner 201, as well as by all third parties wishing to provide services to the DID owner 201. Thus, when the DID owner 201 wishes to associate a new device with DID 205, the DID owner 201 can execute the DID creation module 330 on the new device. The DID creation module 330 can then use the registrar 310 to update the DID document 210 to reflect that the new device is now associated with DID 205. This update will be reflected in the transactions on the distributed ledger 220, as previously described.

[0065] However, in some embodiments, having a public key for each device 301 owned by the DID owner 201 can be advantageous, as this allows the DID owner 201 to sign with a device-specific public key without needing access to a general public key. In other words, since the DID owner 201 will use different devices at different times (e.g., a mobile phone in one case and a laptop in another), having a key associated with each device to provide efficiency in signing using those keys is advantageous. Therefore, in such embodiments, when an additional device executes the DID creation module 330, the key generation module 350 can generate additional public keys 208 and 209. These additional public keys can be associated with the private key 206, or in some cases, paired with a new private key.

[0066] In embodiments where additional public keys 208 and 209 are associated with different devices, additional public keys 208 and 209 can be recorded in DID document 210 as associated with those devices. This is in Figure 3 As shown in the image. It is understandable that, besides... Figure 3 In addition to the information shown (information 208, 209, and 365), DID document 210 may also include previously mentioned information. Figure 2 The information described (information 205, 207, and 211 to 216). If DID document 210 exists before the generation of the device-specific public key, DID document 210 will be updated by creation module 330 via registrar 310, and this will be reflected in the update transaction on distributed ledger 220.

[0067] In some embodiments, the DID owner 201 may wish to keep the association between the device and the public key or the association between the device and DID 205 confidential. Therefore, the DID creation module 330 can make such data confidentially displayed in the DID document 210.

[0068] As described above, DID 205 is already associated with all devices under the control of DID owner 201, even though these devices have their own public keys. However, in some embodiments, it may be useful for each device or a subset of devices under the control of DID owner 201 to have its own DID. Therefore, in some embodiments, DID creation module 330 may generate an additional DID, such as DID 331, for each device. DID creation module 330 then generates a private key and public key pair and a DID document for each device and records them on distributed ledger 220 in the manner described above. Such embodiments may be advantageous for devices whose ownership can change, as it is possible to associate the device-specific DID with the new owner of the device by granting authorization permissions to the new owner and revoking such permissions from the old owner in the DID document.

[0069] As described above, to ensure that the private key 206 is entirely under the control of the DID owner 201, the private key 206 is created on a user device 301, browser 302, or operating system 303 owned or controlled by the DID owner 201 who executes the DID management module 320. In this way, it is virtually impossible for a third party (and most importantly, the provider of the DID management module 320) to gain control of the private key 206.

[0070] However, DID owner 201 may lose the device storing private key 206, which could result in DID owner 201 losing access to DID 205. Therefore, in some embodiments, UI 335 may include an option to allow DID owner 201 to export private key 206 to an offline device security database 305 under the control of DID owner 201. As an example, database 305 may be as follows (reference below) Figure 4 The identity center 410 described herein is one of the identity centers. Storage module 380 is configured to store data (such as private key 206 or authentication information 215 made by or about DID owner 201) outside the device, in database 305, or in identity center 410, which will be described in more detail later. Of course, in some embodiments, if the device has sufficient storage resources, storage module 380 may store at least some data on the device. In some embodiments, private key 206 may be stored as a QR code that can be scanned by DID owner 201.

[0071] In other embodiments, the DID management module 320 may include a recovery module 360, which can be used to recover a lost private key 206. In operation, the recovery module 360 ​​allows the DID owner 201 to select one or more recovery mechanisms 365 when creating DID 205, which can later be used to recover the lost private key. In embodiments with a UI 335, the UI 335 may allow the DID owner 201 to provide information that will be used by one or more recovery mechanisms 365 during recovery. The recovery module 360 ​​can then operate on any device associated with DID 205.

[0072] DID management module 320 may also include revocation module 370 for revoking or disconnecting a device from DID 205. In operation, the revocation module may use UI element 335, which may allow DID owner 201 to indicate the desire to remove a device from the device associated with DID 205. In one embodiment, revocation module 370 may access DID document 210 and may cause all references to the device to be removed from DID document 210. Alternatively, the device's public key may be removed. This change in DID document 210 can then be reflected as an update transaction on distributed ledger 220, as previously described.

[0073] Figure 4An embodiment of a computing system environment 400 in which a DID such as DID 205 can be utilized is shown. Specifically, environment 400 will be used to describe the use of DID 205 relative to one or more decentralized storage devices or identity centers 410, each under the control of DID owner 201, to store data belonging to or about DID owner 201. For example, it can be used Figure 3 The storage module 380 stores the data within the identity center. It should be noted that... Figure 4 This can include the first reference Figure 2 or Figure 3 The references to the elements discussed are therefore used with the same reference numerals for ease of explanation.

[0074] In one embodiment, identity center 410 can be multiple instances of the same identity center. This is indicated by line 410A. Therefore, various identity centers 410 can include at least some of the same data and services. Thus, if a change is made to at least some portion of the data (and potentially any portion of any data) in one of the identity centers 410, that change can be reflected in one or more (and possibly all) of the remaining identity centers.

[0075] Identity center 410 can be any data storage device that can be exclusively controlled by DID owner 201. As an example only, the first identity center 411 and the second identity center 412 are implemented in cloud storage devices (possibly in the same cloud, or even on different clouds managed by different cloud providers), thus potentially enabling the storage of large amounts of data. Therefore, the entire set of data can be stored in these identity centers.

[0076] However, identity centers 413 and 414 may have limited storage space. Therefore, these identity centers may include descriptors of data stored in the first and second identity centers. Alternatively, records of changes to data in other identity centers may also be included. Thus, changes in one identity center of identity center 410 are either completely copied to other identity centers, or at least one record or descriptor of that data is recorded in other identity centers.

[0077] Since an identity center can be multiple instances of the same identity center, only a complete description of the first identity center 411 will be provided, as this description can also be applied to identity centers 412 through 414. As shown, identity center 411 may include a data storage device 420. The data storage device 420 can be used to store any type of data associated with DID owner 201. In one embodiment, the data may be a collection 422 of specific types of data corresponding to a specific protocol. For example, collection 422 may be medical record data corresponding to a specific protocol for medical data. Collection 422 may include any other type of data, such as proof 215 made by or about DID owner 201.

[0078] In one embodiment, the stored data may have different authentication and privacy settings 421 associated with the stored data. For example, a first subset of the data may have a setting 421 that allows the data to be publicly exposed, but this does not include any authentication of the DID owner 201. This type of data can be used for relatively unimportant data such as color schemes. A second subset of the data may have a setting 421 that allows the data to be publicly exposed and includes authentication of the DID owner 201. A third subset of the data may have a setting 421 that encrypts a subset of the data using a private key 206 and public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data will require a party to have access to public key 207 (or some other associated public key) to decrypt the data. The process may also include authentication of the DID owner 201. A fourth subset of the data may have a setting 421 that restricts the data to a subset of third parties. This may require decrypting the data using the public key associated with the subset of third parties. For example, DID owner 201 can specify setting 421 to allow only the public key associated with a friend of DID owner 201 to decrypt the data. Regarding data stored by storage module 380, these settings 411 can be at least partially determined by… Figure 3 It consists of 380 storage modules.

[0079] In some embodiments, the identity center 411 may have a licensing module 430 that allows the DID owner 201 to set specific authorizations or permissions for third parties such as third parties 401 and 402 to access the identity center. For example, the DID owner 201 may grant his or her spouse access to all data 420. Alternatively, the DID owner 201 may grant access to his or her doctor for any medical records. It should be understood that the DID owner 201 may allow any number of third parties to access a subset of data 420. This will be explained in more detail later. For data stored by the storage module 380, these access permissions 430 may be at least partially granted by... Figure 3 It consists of 380 storage modules.

[0080] Identity center 411 may also have a message transceiver module 440. In operation, the message transceiver module allows the identity center to receive messages, such as requests from parties like third parties 401 and 402 to access the identity center's data and services. Furthermore, message transceiver module 440 allows identity center 411 to respond to messages from third parties and also communicates with DID resolver 450. This will be explained in more detail later. The ellipsis 416 indicates that identity center 411 may have additional services when circumstances permit.

[0081] In one embodiment, DID owner 201 may wish to authenticate the new device 301 to identity center 411, which is already associated with DID 205, in the manner described above. Therefore, DID owner 201 can use the DID management module 320 associated with the new user device 301 to send a message to identity center 411 declaring that the new user device is associated with DID 205 of DID owner 201.

[0082] However, Identity Center 411 may not initially recognize the new device as owned by DID owner 201. Therefore, Identity Center 411 can use Message Transceiver 440 to contact DID resolver 450. Messages sent to DID resolver 450 may include DID 205.

[0083] DID resolver 450 may be a service, application, or module configured in operation to search for DID documents associated with a DID in distributed ledger 220. Therefore, in this embodiment, DID resolver 450 may use DID 205 to search distributed ledger 220, which may result in DID resolver 450 finding DID document 210. DID document 210 can then be provided to identity center 411.

[0084] As previously described, DID document 210 may include public key 208 or 209 associated with new user equipment 301. To verify that the new user equipment is owned by DID owner 201, identity center 411 may use messaging module 440 to provide a password challenge to new user equipment 301. This password challenge will be constructed such that only devices with access to private key 206 can successfully answer the challenge.

[0085] In this embodiment, since the new user equipment is owned by DID owner 201, it can access private key 206 and thus successfully answer queries. Identity center 411 can then record in license 430 that the new user equipment 301 is able to access data and services of identity center 411 and the rest of identity center 410.

[0086] It should be noted that before accessing Identity Center 411, DID owner 201 does not need to provide any username, password, etc., to the provider of Identity Center 411 (i.e., the first cloud storage provider) to perform the authentication process for new user device 301. Instead, access is determined in a decentralized manner based on DID 205, DID document 210, and the associated public and private keys. Since these are always under the control of DID owner 201, the provider of Identity Center 411 is not involved and therefore unaware of the transaction or any personal information of DID owner 201.

[0087] In another example embodiment, DID owner 201 may provide DID 205 to third-party entity 401, enabling the third party to access data or services stored on identity center 411. For example, DID owner 201 could be someone who wants to allow third party 401 (also a human) access to his or her research data at a scientific conference. Therefore, DID owner 201 may provide DID 205 to third party 401.

[0088] Once a third party 401 can access DID 205, he or she can access DID resolver 450 to access DID document 210. As previously mentioned, DID document 210 may include endpoint 213, which is an address or pointer to a service associated with the decentralized identity.

[0089] After completing the research data example, third party 401 can send a message to message transceiver module 440 requesting permission to access the research data. Then, message transceiver module 440 can send a message to DID owner 201, inquiring whether permission should be granted to third party 401 to access the research data. Because the DID owner wishes to grant access to the data, DID owner 201 can grant permission to third party 401, and this permission can be recorded in permission 430.

[0090] The message transceiver module 440 can then send a message to the third party 401, notifying the third party that he or she can access the research data. Then, the identity center 411 and the third party 401 can communicate directly, enabling the third party to access the data. It should be noted that in many cases, it will actually be the identity center associated with the third party 401 communicating with the identity center 411. However, it can be the device of the third party 401 that is communicating.

[0091] Advantageously, the above process allows Identity Center 411 and third party 401 to communicate and share data without requiring the third party to access Identity Center 411 in a conventional manner. Instead, communication is provided in a decentralized manner using DID 205 and DID file 210. This advantageously allows the DID owner to have complete control over the process.

[0092] like Figure 4 As shown, third party 402 can also use DID 205 and DID document 210 to request permission to access identity center 411. Therefore, the embodiments disclosed herein allow any number of third parties to access identity center 410.

[0093] Figure 5A An embodiment of a computing system environment 500 according to the embodiments disclosed herein is shown, which will be used to explain how a DID owner can control the delegation of DID-related data. It should be noted that since computing system environment 500 may correspond to one or more of the previously described computing system environments 100-400, therefore... Figure 5A This can include the first reference Figures 2-4 The references to the elements discussed are therefore used with the same reference numerals for ease of explanation.

[0094] Suppose that DID owner 201 wishes to delegate permission to a third-party entity 530 to access one or more DID-related data objects, such as data objects 420A and 420B, included in data 420 stored in identity center 411. The third-party entity 530 may own DID 535 or otherwise associate with DID 535. DID-related data objects 420A and 420B can be considered "DID-related" because the data is identified by and associated with DID owner 201's DID 205. DID-related data objects 420A and 420B can include any reasonable type of data, such as video, audio, images, and document data. Therefore, the embodiments disclosed herein are not limited to the types of DID-related data objects 420A and 420B.

[0095] Third-party entity 530 may be granted access to one or more of the DID-related data objects 420A and 420B, enabling third-party entity 530 to read and / or write the data objects, or otherwise manipulate or use the data objects. For example, DID-related data object 420A may be a video of DID owner 201 to be viewed by third-party entity 530, or it may be a document to be edited by third-party entity 530. Since DID owner 201 wishes to delegate permission to access the DID-related data objects to third-party entity 530, there is no problem when third-party entity 530 reads or writes the data objects. In some embodiments, DID-related data objects 420A and / or 420B may be encrypted by DID owner 201 using a private key and a public key, 206 and 207, as previously described. In this case, access to public key 207 may be granted to third-party entity 530, enabling the decryption of the encrypted DID-related data objects.

[0096] While the DID owner 201 may wish to delegate the license to use the DID-related data object to a third-party entity 530, he or she may not want the third-party entity 530 to further delegate the license to use the DID-related data object to other third-party entities, such as third-party entities 540, 550, 560, or any number of additional third-party entities, as indicated by ellipsis 570. Third-party entities 530-570 may be persons or organizations of persons, or may be machines, systems, or devices, or collections of machines, devices, and / or systems. For example, if the DID-related data object 420A is a video, the DID owner 201 may not want any entity other than third-party entity 530 to view the video. Alternatively, if the DID-related data object 420A is a document that he or she has created, the DID owner 201 may not want any entity other than third-party entity 530 to view the document without some form of payment. In either case, the DID owner 201 may not want the third-party entity 530 to delegate the license to use the DID-related data object without some form of control over such delegation. Advantageously, the embodiments disclosed herein provide a manner in which the DID owner 201 controls the delegation of permissions to use the DID-related data objects 420A and / or 420B when the data objects are provided to other third-party entities without the authorization of the DID owner 201.

[0097] like Figure 5AAs shown, the computing system environment 500 may include a delegation module 510. In one embodiment, the delegation module 510 may be implemented by a third-party entity, such as a provider of the DID management module 320 and / or the identity center 410. In other embodiments, the delegation module 510 may reside on a server computer separate from the device 301 owned by the DID owner 201. In other embodiments, the delegation module 510 may be part of the DID management module 320, or may at least share some functionality with the DID management module 320. In a further embodiment, the delegation module 510 may be part of or hosted by one of the identity centers in the identity center 410. Therefore, the embodiments disclosed herein are not limited to where the delegation module 510 is implemented.

[0098] In this embodiment, the delegation module 510 may have access to or has been provided with DID-related data objects 420A and / or 420B. Upon receiving DID-related data objects 420A and / or 420B, the delegation module 510 may attach or associate one or more delegation licenses 520 with DID-related data objects 420A and / or 420B. As will be explained in more detail below, delegation licenses 520 may specify one or more interactions that should occur between the DID owner 201 and any third-party entity that has received DID-related data objects 420A and / or 420B from third-party entity 530 before other third-party entities are able to use DID-related data objects 420A and / or 420B. For ease of explanation, delegation licenses 520 will be interpreted only in relation to being attached to DID-related data object 420A. However, this interpretation may also apply to DID-related data object 420B.

[0099] Figure 5B An example embodiment of delegation license 520 is illustrated. As shown, in the example embodiment, delegation license 520 may include a first delegation license 521, a second delegation license 522, a third delegation license 523, and any number of additional delegation licenses as indicated by ellipsis 524. Each delegation license 521-524 may specify a particular interaction that should occur before the third-party entities (i.e., third-party entities 540, 550, and 560) are able to use the DID-related data 420A. It should be noted that in other embodiments, delegation license 520 may include only one or a smaller subset of delegation licenses 521-524. Specific examples of the interactions specified or defined by delegation licenses 521-524 will be explained in more detail below.

[0100] In some embodiments, delegation license 520 may include geographic delegation license 525. DID owner 201 may use geographic delegation license 525 to restrict the geographic areas where third-party entities 540, 550, and 560 can use DID-related data object 420A. For example, DID owner 201 may wish to restrict delegation to his or her home country, state, or country. Therefore, third-party entities 540, 550, and 560 cannot use DID-related data object 420A outside the geographic area specified in geographic delegation license 525.

[0101] In other embodiments, delegation license 520 may include time delegation license 526. Time delegation license 526 may be used by DID owner 201 to restrict the use of DID-related data object 420A by third-party entities 540, 550, and 560 for a specific time period. For example, the specific time period may be several weeks or several months. After the time specified by time delegation license 526 expires, DID-related data object 420A may become unusable by third-party entities 540, 550, and 560.

[0102] After delegation license 520 has been attached to DID-related data object 420A, the data object can be provided to third-party entity 530. In this case, since DID owner 201 wants third-party entity 530 to be able to use DID-related data object 420A, access to the public key 207 that can decrypt DID-related data object 420A is provided or granted to third-party entity 530. It is understood that delegation license 520 may generally not be applicable to third-party entity 530, as entity 530 intends to use DID-related data object 420A. As previously stated, delegation license 520 is attached to DID-related data object 420A so that DID owner 201 can have some control over the use of DID-related object 420A by any attached third-party entity receiving it from third-party entity 530. However, in some embodiments, DID owner 201 may include in delegation license 520 a permission to impose restrictions on third-party entity 530's use of DID-related data object 420A.

[0103] like Figure 5A As shown, a third-party entity can provide a DID-related data object 420A with an additional delegation license 520 to a third-party entity 540. As illustrated, the third-party entity 540 can own or be associated with DID 545. When the third-party entity 540 attempts to use the DID-related data object 420A, the delegation license 520 can specify defined interactions that need to occur before the DID-related data object 420A can be used.

[0104] For example, in one embodiment, suppose one of the delegation licenses 521-524 specifies an interaction that results in a count 515A of the number of third-party entities that receive DID-related data objects 420A from third-party entity 530. This could be useful if the DID owner 201 simply wants to know how frequently the DID-related data object 420A has been accessed after it has been provided to the third-party entity 530, and does not care about the identity of the third-party entity. In such an embodiment, the delegation module 510 may include a ledger 515. Alternatively, the ledger 515 may be stored in an identity center 411 or some other database such as database 305.

[0105] Therefore, as Figure 5A As shown, third-party entity 540 can provide interaction 546 to delegation module 510, which notifies delegation module that third-party entity 540 is attempting to use DID-related data object 420A. Upon receiving interaction 546, count 515A can be written to ledger 515. Once count 515A has been recorded, third-party entity 540 can be allowed to read and / or write or otherwise manipulate or use DID-related data object 420A without any input from DID owner 201. In some embodiments, this may include providing or otherwise allowing third-party entity 540 access to public key 207, enabling the decryption of DID-related data object 420A.

[0106] In another embodiment, for the delegated licenses described above, additionally or alternatively, it is assumed that one of the delegated licenses 521-524 specifies an interaction that includes requesting third-party entity 540 to provide historical information about from whom the entity received DID-related data object 420A. In this embodiment, third-party entity 540 may provide interaction 546, which notifies the delegated module 510 that it received DID-related data object 420A from third-party entity 530. However, if third-party entity 540 receives DID-related data object 420A from one of third-party entities 550 or 560 after one of the third-party entities 550 or 560 has received DID-related data object 420A from third-party entity 530, this would be included in interaction 546.

[0107] Upon receiving interaction 546, management module 510 can record history 516. History 516 may include information about the identity of the third-party entity that has provided DID-related data object 420A. Recording this usage chain of the third-party entity may be useful in cases where the DID owner 201 may want to know the identity of the third-party entity attempting to use DID-related data object 420A but may not be interested in any further information about the third-party entity. Once history 516 is recorded, the third-party entity can be allowed to use DID-related data object 420A, which may include providing access to public key 207 to decrypt DID-related data object 420A.

[0108] like Figure 5A As shown, third-party entity 540 can provide third-party entity 550 with a DID-related data object 420A with an additional delegation license 520. As shown, third-party entity 550 can own or be associated with DID 555. When third-party entity 550 attempts to use the DID-related data object 420A, the delegation license 520 can specify defined interactions that need to occur before the DID-related data object 420A can be used.

[0109] In one embodiment, with or alternative to the delegated licenses described above, it is assumed that one of the delegated licenses 521-524 specifies a dynamic interaction between a third-party entity 550 and the DID owner 201. This dynamic interaction can be useful when the DID-related data object 420A is of a sensitive type or a type that the DID owner 201 may wish to keep confidential. For example, the DID-related data object 420A could be a medical or financial record provided to the third-party entity 530 for a specific purpose. Before authorizing the third-party entity 550 to use the DID-related data object 420A, the DID owner 201 may want to determine who the third-party entity 550 is and why that entity is attempting to use the DID-related data object 420A.

[0110] Therefore, the delegation module 510 can receive an interaction 556 notifying the delegation module that a third-party entity 550 is attempting to use the DID-related data object 420A. Since the DID-related data object 420A is a sensitive type, the dynamic module 518 included in the delegation module 510 can initiate a dynamic interaction 518A with the third-party entity 550. For example, suppose the DID-related data object 420A is a medical record. Therefore, the dynamic module 518 can prompt the DID owner 201 to ask the third-party entity 550 a series of questions 518A in real time. In this embodiment, the real-time questions may include inquiring about the identity of the third-party entity 550 and why the third-party entity 550 needs to use the DID-related data object 420A. As indicated by interaction 556, the third-party entity 550 can answer the questions in real time. For example, in the case of medical records, third-party entity 550 can reply that they are doctors and have been provided with DID-related data object 420A by third-party entity 530 via third-party entity 540 in order to provide a second opinion to DID owner 201 and third-party entity 530. In this example, third-party entity 530 could also be a doctor.

[0111] If the DID owner is satisfied with the response allowing third-party entity 550 to use DID-related data object 420A, he or she can authorize dynamic module 518 to allow third-party entity 550 to use DID-related data object 420A. This may include providing access to public key 207 to decrypt DID-related data object 420A. If the DID owner 201 is not satisfied, he or she can continue to ask more questions until satisfied, or he or she can instruct dynamic module 518 to refuse the use of DID-related data object 420A. Advantageously, requiring dynamic interaction before allowing the use of DID-related data object 420A allows DID owner 201 to determine in real time whether the third party that provided DID-related data object 420A to him / her from third-party entity 530 should be allowed to use DID-related data object 420A.

[0112] like Figure 5A As shown, third-party entity 540 may provide third-party entity 560 with a DID-related data object 420A with an additional delegation license. Alternatively or additionally, the DID-related data object 420A may be provided from third-party entity 550. As shown, third-party entity 560 may own or be associated with DID 565. When third-party entity 560 attempts to use the DID-related data object 420A, the delegation license 520 may specify defined interactions that need to occur before the DID-related data object 420A can be used.

[0113] In one embodiment, with respect to the foregoing delegated license, it is assumed that one of the delegated licenses 521-524 specifies that payment of fees is provided before the DID-related data object 420A can be used. This may be useful in instances where the DID-related data object 420A is of the type such as books or movies that the DID owner 201 may want to sell to an entity other than third-party entity 530, or if the DID owner 201 simply wants to make money from the DID-related data object 420A.

[0114] Therefore, the delegation module 510 can receive interaction 566, which notifies the delegation module that a third-party entity 560 is attempting to use the DID-related data object 420A. Since delegation licensing requires payment, the payment module 517 included in the delegation module 510 can request payment 517A from the third-party entity 560. As indicated by interaction 566, the third-party entity 560 can then provide payment to the payment module 517. After verifying the payment, the payment module 517 can allow the third-party entity 560 to use the DID-related data object 420A, which may include providing access to the public key 207 to decrypt the DID-related data object 420A.

[0115] The following discussion now involves multiple methods and method actions that can be performed. Although method actions may be discussed in a specific order or illustrated in a flowchart as occurring in a specific order, a specific order is not required unless specifically stated otherwise, or required because an action depends on another action that is completed before that action is performed.

[0116] Figure 6 A flowchart illustrating an example method for a DID owner to delegate control over DID-related data is shown. Refer to the preceding discussion. Figures 1-5B One or more of them are used to describe method 600.

[0117] Method 600 includes the action of attaching a delegation license to one or more DID-related data objects to be provided by the DID owner to a first third-party entity. This delegation license specifies at least one or more interactions to occur between the DID owner and one or more second third-party entities, which have already received the one or more DID-related data objects from the first third-party entity before the one or more second third-party entities can use the one or more DID-related data objects (action 610). For example, as previously described, delegation module 510 may attach delegation license 520, including one or more of delegation licenses 521-526, to DID-related data objects 420A and / or 420B. Delegation license 520 specifies various interactions, such as interactions 546, 556, and 566, that should occur before third-party entities (such as third-party entities 540, 550, and 560) that have already received DID-related data objects 420A and / or 420B from third-party entity 530 can use the DID-related data objects 420A and / or 420B. Third-party entities 540, 550, and 560 may receive DID-related data objects 420A and / or 420B directly from third-party entity 530, or indirectly from third-party entity 530 via another third-party entity among third-party entities 540, 550, and 560 that has already received data objects from third-party entity 530.

[0118] Method 600 includes an action (action 620) of providing one or more DID-related data objects to a first third-party entity after attaching a delegation license. For example, as previously described, delegation module 510 may provide DID-related data objects 420A and / or 420B to third-party entity 530 after attaching a delegation license 520.

[0119] Method 600 includes receiving one or more interactive actions (action 630) from one or more second third-party entities when one or more second third-party entities attempt to use one or more DID-related data objects. For example, as previously described, when a third-party entity attempts to use DID-related data objects 420A and / or 420B, the delegation module 510 can receive one of the interactions 546, 556, and 566 from one of the third-party entities 540, 550, and 560.

[0120] Method 600 includes an action (action 640) in which one or more second third-party entities are permitted to use one or more DID-related data objects when one or more received interactions satisfy a delegation permission. For example, as previously described, when delegation permission 520 has been satisfied, delegation module 510 may permit the use of DID-related data objects 420A and / or 420B. In some embodiments, this may include providing access to public key 207, enabling the decryption of DID-related data objects 420A and / or 420B.

[0121] The operations performed in the processes and methods disclosed herein may be implemented in different orders. Furthermore, the operations outlined are provided as examples only, and some operations may be optional, combined into fewer steps and operations, supplemented with further operations, or extended as additional operations without diminishing the essence of the disclosed embodiments.

[0122] This invention may be practiced in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered illustrative in all respects only, and not restrictive. Therefore, the scope of the invention is indicated by the appended claims, and not by the foregoing description. All changes within the meaning and equivalent scope of the claims should be included within its scope.

Claims

1. A computing system implemented in a decentralized network that implements a distributed ledger, the distributed ledger being configured to support one or more decentralized identities (DIDs) for one or more users of the computing system, the computing system comprising: One or more hardware processors; as well as One or more computer hardware storage devices storing computer-executable instructions configured to cause the computing system, when executed by the one or more processors, to: A delegation license is attached to one or more DID-related data objects, which are to be provided by the DID owner to a first third-party entity. The delegation license specifies at least one or more interactions to occur between the DID owner and one or more second third-party entities, which have received the one or more DID-related data objects from the first third-party entity before the one or more second third-party entities are able to use the one or more DID-related data objects. After attaching the delegated license, the one or more DID-related data objects are provided to the first third-party entity; When the one or more second third-party entities attempt to use the one or more DID-related data objects, receive one or more interactions from the one or more second third-party entities; as well as When one or more received interactions satisfy the delegated permission, the one or more second third-party entities are allowed to use the one or more DID-related data objects.

2. The computing system of claim 1, wherein the one or more interactions include a count of the number of second third-party entities attempting to use the one or more DID-related data objects.

3. The computing system of claim 1, wherein the one or more interactions include a request for a specific second third-party entity to provide historical information about other third-party entities that have used the one or more DID-related data objects.

4. The computing system of claim 1, wherein the one or more delegated licenses specify that the one or more second third-party entities should be in a specified location when attempting to use the one or more DID-related data objects.

5. The computing system of claim 1, wherein the one or more delegated licenses specify that the one or more second third-party entities should use the one or more DID-related data objects within a specified time period.

6. The computing system of claim 1, wherein the one or more interactions include: Before allowing the use of the one or more DID-related data objects, receive payment for the specified fee from the one or more second third-party entities.

7. The computing system of claim 1, wherein the one or more interactions include: Before the one or more second third-party entities can use the one or more DID-related data objects, further information is dynamically received from the one or more second third-party entities.

8. The computing system of claim 7, wherein the dynamic reception of further information is based on the type of the one or more DID-related data objects.

9. The computing system of claim 1, wherein the one or more second third-party entities receive the one or more DID-related data objects directly from the first third-party entity or from one or more other second third-party entities.

10. The computing system of claim 1, wherein allowing use of the one or more DID-related data objects includes providing access to a public key configured to decrypt the one or more DID-related data objects.

11. A method for delegating the use of DID-related data by a decentralized identity (DID) owner in a computing system implemented in a decentralized network of a distributed ledger, the distributed ledger being configured to support one or more DIDs for one or more users of the computing system, the method comprising: The action of attaching a delegation license to one or more DID-related data objects, which are to be provided by the DID owner to a first third-party entity, the delegation license specifying at least one or more interactions to occur between the DID owner and one or more second third-party entities, which have received the one or more DID-related data objects from the first third-party entity before the one or more second third-party entities are able to use the one or more DID-related data objects; The action of providing the one or more DID-related data objects to the first third-party entity after attaching the delegated permission; When the one or more second third-party entities attempt to use the one or more DID-related data objects, they receive one or more interactive actions from the one or more second third-party entities. as well as When one or more received interactions satisfy the delegated permission, the one or more second third-party entities are permitted to use the one or more DID-related data objects.

12. The method of claim 11, wherein the one or more interactions include recording a count of the number of second third-party entities attempting to use the one or more DID-related data objects.

13. The method of claim 11, wherein the one or more interactions include a request for a specific second third-party entity to provide historical information about other third-party entities that have used the one or more DID-related data objects.

14. The method of claim 11, wherein the one or more delegated licenses specify that the one or more second third-party entities should be in a specified location when attempting to use the one or more DID-related data objects.

15. The method of claim 11, wherein the one or more delegated licenses specify that the one or more second third-party entities should use the one or more DID-related data objects within a specified time period.

16. The method of claim 11, wherein the one or more interactions comprise: Before allowing the use of the one or more DID-related data objects, receive payment for the specified fee from the one or more second third-party entities.

17. The method of claim 11, wherein the one or more interactions comprise: Before the one or more second third-party entities can use the one or more DID-related data objects, further information is dynamically received from the one or more second third-party entities.

18. The method of claim 11, wherein the one or more second third-party entities receive the one or more DID-related data objects directly from the first third-party entity or from one or more other second third-party entities.

19. The method of claim 11, wherein allowing use of the one or more DID-related data objects includes providing access to a public key configured to decrypt the one or more DID-related data objects.

20. A computer program product comprising one or more computer hardware storage devices storing computer-executable instructions configured to, when executed by one or more processors of a computing system, cause the computing system to perform a method for delegating use of decentralized identity (DID) owner control of DID-related data, the method comprising: The action of attaching a delegation license to one or more DID-related data objects, which are to be provided by the DID owner to a first third-party entity, the delegation license specifying at least one or more interactions to occur between the DID owner and one or more second third-party entities, which have received the one or more DID-related data objects from the first third-party entity before the one or more second third-party entities are able to use the one or more DID-related data objects; The action of providing the one or more DID-related data objects to the first third-party entity after attaching the delegated permission; When the one or more second third-party entities attempt to use the one or more DID-related data objects, they receive one or more interactive actions from the one or more second third-party entities. as well as When one or more received interactions satisfy the delegated permission, the one or more second third-party entities are permitted to use the one or more DID-related data objects.

Images