User Choice in Data Location and Policy Compliance

Abstract

Different policy rules applicable to different data types are enforced. The computing system and method are implemented in a decentralized network that implements a distributed ledger that supports one or more decentralized identities (DIDs) for one or more users of the computing system. A request is received from an entity to perform an operation on data stored or to be stored in a storage device associated with an owner of the DID. The type of data requested to be operated on is then determined. One or more policy rules applicable to the determined data type are accessed. Based on the one or more policy rules, it is determined whether the operation to be performed on the data will cause the data to comply with the one or more policy rules. Based on the determination, the request is allowed or denied.

Description

Background Art

[0001] Most documents or records that prove identity in use today are issued by centralized organizations such as governments, schools, employers, or other service centers or regulatory organizations. These organizations usually maintain the identity of each member in a centralized identity management system. A centralized identity management system is a centralized information system used by an organization to manage issued identities, their authentication, authorization, roles, and privileges. Centralized identity management systems are considered secure because they usually use professionally maintained hardware and software. Typically, the identity issuing organization sets the terms and requirements for registering people with the organization. Finally, when one party needs to verify the identity of another party, the verifying party often needs to obtain information used to verify and / or authenticate the identity of the other party through a centralized identity management system.

[0002] A decentralized identifier (DID) is a new type of identifier that is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) provides the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in the ledger portion cannot be retroactively changed without changing all subsequent ledger portions, which provides a fairly secure platform. Since DIDs are usually not controlled by a centralized management system, but owned by the owner of the DID, DIDs are sometimes called unauthorized identities. However, in reality, different countries or organizations may formulate specific requirements and rules about the options and permissions that individuals should have. Specifically, certain types of data at different locations or within different organizations may need to be handled in different ways.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as described above. Rather, this background is merely provided to illustrate one exemplary technology area in which some embodiments described herein may be practiced. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0005] Embodiments disclosed herein relate to a computing system and method for enforcing different policy rules applicable to different data types. The computing system and method are implemented in a decentralized network that implements a distributed ledger, which is configured to back up one or more decentralized identifiers (DIDs) for one or more users of the computing system. First, a request to operate on data is received from an entity, and the data is stored or is to be stored in a storage device associated with the owner of the decentralized identifier (DID). Then, the type of data requested to be operated is determined. Thereafter, one or more policy rules applicable to the type of data determined are accessed. Based on the one or more policy rules accessed, a determination is made as to whether the operation to be performed on the data will cause the data to comply with one or more policy rules. When it is determined that the operation will cause the data to comply with one or more policy rules, the request is allowed.

[0006] Additional features and advantages will be set forth in the description that follows, and in part will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention may 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 described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the above and other advantages and features are obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments shown in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

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

[0009] Figure 2 An example environment for creating a decentralized identity (DID) is shown;

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

[0011] Figure 4 An example decentralized storage device or identity hub is shown;

[0012] Figure 5 An overview comparison between centralized and decentralized data systems is shown;

[0013] Figure 6An example embodiment for enforcing one or more policy rules applicable to a data type is shown;

[0014] Figure 7 A flow chart illustrating an example method for enforcing one or more policy rules applicable to a data type;

[0015] Figure 8 A flow chart illustrating an example method for determining the type of data;

[0016] Fig. 9 A flow chart illustrating an example method for determining whether an operation on data will cause the data to comply with one or more policy rules;

[0017] Fig.10 A flow chart illustrating an example method for allowing (or denying) access to requested data; and

[0018] Fig.11 A flow chart of an example method for enforcing one or more policy rules when a DID owner requests access to another DID owner's data or data storage device is shown. DETAILED DESCRIPTION

[0019] Embodiments disclosed herein relate to a computing system and method for enforcing different policy rules applicable to different data types. The computing system and method are implemented in a decentralized network that implements a distributed ledger, which is configured to back up one or more decentralized identifiers (DIDs) for one or more users of the computing system. First, a request to operate on data is received from an entity, and the data is stored or is to be stored in a storage device associated with the owner of the decentralized identifier (DID). Then, the type of data requested to be operated is determined. Thereafter, one or more policy rules applicable to the determined data type are accessed. Based on the one or more policy rules accessed, a determination is made as to whether the operation to be performed on the data will cause the data to comply with one or more policy rules. When it is determined that the operation will cause the data to comply with one or more policy rules, the request is allowed.

[0020] The principles described herein provide technological advances to allow government laws and / or organizational rules to be enforced in a decentralized environment, while still giving users (e.g., DID owners) significant control over their own data.

[0021] Because the principles described herein can be implemented in the context of a computing system, Figure 1 Some introductory discussion describing the computing system. The description will then return to the principles of the DID platform with respect to the remaining figures.

[0022] Computing systems now increasingly take a variety of forms. For example, a computing system may be a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device that is not conventionally 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 of the following devices or systems (or combinations thereof): the device or system (or combination thereof) includes at least one physically tangible processor and physically tangible memory, which is capable of having computer executable instructions that can be executed by the processor thereon. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed over a network environment and may include multiple constituent computing systems.

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

[0024] Computing system 100 also has a number of structures on it that are generally referred to as "executable components." For example, memory 104 of computing system 100 is shown as including executable component 106. The term "executable component" is a name for a structure that is known to those of ordinary skill in the computing arts as a structure that can be software, hardware, or a combination thereof. For example, when implemented in software, one of ordinary skill in the art will understand that the structure of an executable component can include a software object, routine, method, etc. that can be executed on a computing system, whether or not such executable component is present in a stack of the computing system, or whether or not the executable component is present on a computer-readable storage medium.

[0025] In such cases, one of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium so that when interpreted by one or more processors of the computing system (e.g., by a processor thread), the computing system is caused to perform functions. Such a structure can be directly computer-readable by the processor (which is the case if the executable component is binary). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) to generate such a binary file that is directly interpretable by the processor. When the term "executable component" is used, such an understanding of the example structure of the executable component is well within the understanding of one of ordinary skill in the computing arts.

[0026] The term "executable component" is also well understood by those of ordinary skill to include structures such as hard-coded or hard-wired logic gates, which are implemented exclusively or almost exclusively in hardware, such as in a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other special circuit. Therefore, the term "executable component" is a term used for structures that are well understood by those of ordinary skill in the computing field, whether implemented in software, hardware, or a combination. In this specification, the terms "component", "agent", "manager", "service", "engine", "module", "virtual machine", etc. may also be used. As used in this specification and cases, these terms (whether or not expressed with modifying clauses) are also intended to be synonymous with the term "executable component" and therefore also have structures that are well understood by those of ordinary skill in the computing field.

[0027] 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 that performs the action) direct the operation of the computing system in response to having executed the computer executable instructions constituting the executable component. For example, such computer executable instructions may be embodied in one or more computer readable media forming a computer program product. An example of such an operation involves the manipulation of data. If such actions are implemented exclusively or almost exclusively in hardware, such as in 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 a memory 104 of the computing system 100. The computing system 100 may also include a communication channel 108 that allows the computing system 100 to communicate with other computing systems via, for example, a network 110.

[0028] Although not all computing systems require a user interface, in some embodiments, computing system 100 includes a user interface system 112 for interacting with a user. User interface system 112 may include output mechanism 112A and input mechanism 112B. The principles described herein are not limited to precise output mechanism 112A or input mechanism 112B, as this will depend on the nature of the device. However, output mechanism 112A may include, for example, a speaker, a display, a tactile output, a hologram, etc. Examples of input mechanism 112B may include, for example, a microphone, a touch screen, a hologram, a camera, a keyboard, a mouse of other pointer inputs, any type of sensor, etc.

[0029] The embodiments described herein may include or utilize a dedicated or general-purpose computing system including computer hardware, such as, for example, 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 can be any available media that can be accessed by a general-purpose or special-purpose computing system. The computer-readable medium that stores computer-executable instructions is a physical storage medium. The computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct computer-readable media: a storage medium and a transmission medium.

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

[0031] "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 or wireless), the computing system appropriately treats the connection as a transmission medium. Transmission media may include networks and / or data links that can be used to carry computer executable instructions or desired program code devices in the form of data structures and that can be accessed by general or special computing systems. The above combinations should also be included in the scope of computer-readable media.

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

[0033] 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 certain function or group of functions. Alternatively or additionally, the computer executable instructions may configure a computing system to perform a certain function or group of functions. Computer executable instructions may be, for example, binary files, or even instructions that undergo some conversion (such as compilation) before being directly executed by a processor, such as intermediate format instructions, such as assembly language, or even source code.

[0034] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the above-described features or acts. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0035] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment with various 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. The present invention can also be practiced in a distributed system environment, in which local and remote computing systems that are linked (or by a hardwired data link, a wireless data link, or a combination of a hardwired data link and a wireless data link) through a network both perform tasks. In a distributed system environment, program modules can be located in both local memory storage devices and remote memory storage devices.

[0036] Those skilled in the art will also appreciate that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the following 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 devices, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

[0037] The remaining figures can discuss various computing systems that can correspond to the computing system 100 described previously. The computing systems of the remaining figures include various components or functional blocks that can implement various embodiments disclosed herein as will be explained. Various components or functional blocks can be implemented on a local computing system, or can be implemented on a distributed computing system that includes an element residing in the cloud or implements various aspects of cloud computing. Various components or functional blocks can be implemented as software, hardware, or a combination of software and hardware. The computing systems of the remaining figures may include more or fewer components than the components shown in the figure, and some of the components can be combined according to circumstances. Although not necessarily shown, the various components of the computing system can access and / or utilize processors and memories (such as processor 102 and memory 104) as needed to perform their various functions.

[0038] Now about Figure 2 Give some introductory discussion of decentralized identities (DIDs) and the environments in which they are created and reside. Figure 2 As shown, DID owner 201 may own or control DID 205 that represents the identity of DID owner 201. DID owner 201 may register a DID using a creation and registration service, which will be explained in more detail below.

[0039] DID owner 201 may be any entity that can benefit from a DID. For example, DID owner 201 may be a human or a human organization. Such an organization may include a company, department, government, agency, or any other organization or group of organizations. Each individual may have a DID, and each individual's organization(s) may also have a DID.

[0040] DID owner 201 may alternatively be a machine, system or device, or a collection of (multiple) machines, (multiple) devices and / or (multiple) systems. In other embodiments, DID owner 201 may be a sub-part of a machine, system or device. For example, a device may be a printed circuit board, where the sub-parts of the circuit board are individual components of the circuit board. In such an embodiment, a machine or device may have a DID and each sub-component may also have a DID. A DID owner may also be a software component, such as described above with respect to Figure 1 An example of a complex executable component 106 may be an artificial intelligence. The artificial intelligence may also have a DID.

[0041] Thus, DID owner 201 may be any reasonable entity, human or non-human, that is capable of creating a DID 205, or at least has a DID 205 created for and associated with it. Although DID owner 201 is shown as having a single DID 205, this need not be the case, as there may be any number of DIDs associated with DID owner 201, as the case may be.

[0042] 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 DID owner 201 at least within the scope in which the DID is expected to be used. For example, the identifier can be a locally unique identifier, and it may be more desirable to be a globally unique identifier for identity systems that are expected to operate globally. In some embodiments, DID 205 can be a uniform resource identifier (URI) (such as a uniform resource locator (URL)) or other pointer that associates DID owner 201 with a mechanism for participating in a trusted interaction with DID owner 201.

[0043] DID 205 is "decentralized" because it does not require a centralized third-party management system for generation, management, or use. Therefore, DID 205 remains under the control of DID owner 201. This is different from conventional centralized IDs, which base trust on centralized institutions and remain under the control of enterprise directory services, certificate authorities, domain name registries, or other centralized institutions (collectively referred to herein as "centralized institutions"). Therefore, DID 205 can be any identifier that is under the control of DID owner 201 and independent of any centralized institution.

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

[0045] Also like Figure 2 As shown, DID owner 201 has control over a private key 206 and a public key 207 pair associated with DID 205. Because DID 205 is independent of any centralized authority, private key 206 should always be completely under the control of DID owner 201. That is, private and public keys should be generated in a decentralized manner to ensure that they remain under the control of DID owner 201.

[0046] As will be described in more detail below, the private key 206 and public key 207 pair may 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 central authority, as this may result in the private key 206 and public key 207 pair not always being completely under the control of the DID owner 201. Figure 2 While this specification describes private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may be used depending on the circumstances.

[0047] Figure 2 Also shown is a DID document 210 associated with DID 205. As will be explained in more detail below, DID document 210 may be generated when DID 205 is created. In its simplest form, DID document 210 describes how to use DID 205. Thus, 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, which is to be used to store representations of DID 205, as will be explained in more detail below. Thus, DID document 210 may have different methods depending on the particular distributed ledger.

[0048] 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 third-party entities that are given permission by DID owner 201 to access 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.

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

[0050] The DID document 210 may also include authorization information 212. The authorization information 212 may allow the DID owner 201 to authorize a third-party entity to modify the DID document 210 or a portion of the document without giving the third party the authority to prove ownership of the DID 205. For example, the authorization information 212 may allow the third party to update any specified set of one or more fields in the DID document 210 using any specified update mechanism. Alternatively, the authorization information may allow the third party to limit the use of the DID 205 by the DID owner 201 for a specified period of time. This may be useful when the DID owner 201 is a minor child and the third party is the child's parent or guardian. The authorization information 212 may allow the parent or guardian to limit the use of the DID 201 until the child is no longer a minor.

[0051] The authorization information 212 may also specify one or more mechanisms that the third party 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 discussed previously with respect to the authentication information 211.

[0052] The DID document 210 may also include one or more service endpoints 213. A service endpoint may include a network address where a service representing the DID owner 201 operates. Examples of specific services include discovery services, social networks, file storage services (such as identity servers or hubs), and verifiable claim repository services. Thus, the service endpoints 213 operate as pointers to services operating on behalf of the DID owner 201. These pointers may be used by the DID owner 201 or a third-party entity to access services operating on behalf of the DID owner 201. Specific examples of the service endpoints 213 will be explained in more detail below.

[0053] The DID document 210 may also include identification information 214. The 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. Thus, for different purposes, the identification information 214 listed in the DID document 210 may represent different personas of the DID owner 201. For example, a persona may be pseudonymous; for instance, the DID owner 201 may include a pen name in the DID document when identifying him or her as the author of an article posted on a blog. A persona may be completely anonymous; for example, the DID owner 201 may only want to disclose his or her position or other background data (such as school teacher, FBI agent, adult over 21, etc.) in the DID document, rather than his or her name. And a persona may be specific to who the DID owner 201 is as an individual; for example, the DID owner 201 may include information identifying him or her as a volunteer for a specific charity organization, an employee of a specific company, a winner of a specific award, etc.

[0054] The DID document 210 may also include credential information 215, which may also be referred to herein as attestation. The credential information 215 may be any information associated with the background of the DID owner 201. For example, the credential information 215 may be (but is not limited to) qualifications, achievements, government IDs, government entitlements such as passports or driver's licenses, payment providers or bank accounts, university degrees or other educational histories, employment status and history, or any other information regarding the background of the DID owner 201.

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

[0056] Figure 2 A distributed ledger or blockchain 220 is also shown. The distributed ledger 220 can be any decentralized distributed network including various computing systems that communicate with each other. For example, the distributed ledger 220 can 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 by ellipsis 260. The distributed ledger or blockchain 220 can operate according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers that can correspond to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0057] In the context of DID 205, a 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 an actual distributed ledger. Alternatively, in some other embodiments, DID document 210 may be stored in a data storage device (not shown) associated with distributed ledger or blockchain 220.

[0058] As described above, a representation of DID 205 is stored on each distributed computing system of the distributed ledger or blockchain 220. For example, in Figure 2 In the example of FIG. 2 , this is shown as DID hash 231, DID hash 241, DID hash 251, which are, ideally, identical 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. 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.

[0059] In one embodiment, when DID user 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger or blockchain 220. Distributed ledger or blockchain 220 thus records that DID 205 now exists. Because distributed ledger or blockchain 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, DID hash 231, DID hash 241, and DID hash 251 may also include a record or timestamp specifying when DID 205 was created. At a later date, when DID document 210 is modified, this may also be recorded in DID hash 231, DID hash 241, and DID hash 251. DID hash 231 , DID hash 241 , and DID hash 251 may also include a copy of public key 207 , such that DID 205 is cryptographically bound to DID document 210 .

[0060] Already referenced Figure 2 Having described DIDs and how they generally operate, specific embodiments of DIDs will now be explained. Figure 3 , an environment 300 that can be used to perform various DID lifecycle management operations and services will now be explained. It should be understood that for ease of explanation, Figure 3 The environment can be referenced as needed Figure 2 The elements in .

[0061] like Figure 3 As shown, environment 300 may include various devices and computing systems that may be owned by DID owner 21 or otherwise under the control of DID owner 21. These may include user device 301. User device 301 may be, but is not limited to, a mobile device such as a smart phone, a computing device such as a laptop, or any device such as a car or appliance that includes computing capabilities. Device 301 may include a web browser 302 operating on the device and an operating system 303 operating the device. More broadly, dashed line 304 indicates that all of these devices may be owned by DID owner 201 or otherwise under the control of DID owner 201.

[0062] The environment 300 also includes a DID lifecycle management module 320. It should be noted that in operation, the DID lifecycle management module 320 can reside on and be executed by the user device 301, the web browser 302, and the operating system 303 as shown by lines 301a, 302a, and 303a. Therefore, for ease of explanation, the DID lifecycle management module 320 is shown as separate.

[0063] like Figure 3 As shown, the DID lifecycle management module 320 includes a DID creation module 330. The DID creation module 330 can be used by the DID owner 201 to create the 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 to create the DID 205. The DID creation module 330 can have one or more drivers that are configured to work with a specific distributed ledger (such as the distributed ledger 220) so that the DID 205 complies with the underlying methods of the distributed ledger.

[0064] A specific embodiment will now be described. For example, the UI 335 may provide a prompt for the user to enter a username or some other human-recognizable name. This name may be used as the display name of the DID 205 to be generated. As previously described, the DID 205 may be a long string of random numbers and letters, and therefore it is advantageous to have a human-recognizable name for the display name. The DID creation module 330 may then generate the DID 205. In an embodiment with the UI 335, the DID 205 may be shown in a list of identities and may be associated with a human-recognizable name.

[0065] The DID creation module may also include a key generation module 350. The key generation module may generate the previously described private key 206 and public key 207 pair. The DID creation module 330 may then generate a DID document 210 using the DID 205 and the private and public key pair.

[0066] In operation, DID creation module 330 accesses register 310, which is configured as a specific distributed ledger that will record transactions related to DID 205. DID creation module 330 uses register 310 to record DID hash 231, DID hash 241, and DID hash 251 in the distributed ledger in the manner previously described, and stores DID document 210 in the manner previously described. This process can use public key 207 in hash generation.

[0067] In some embodiments, DID lifecycle management module 320 may include ownership module 340. Ownership module 340 may provide a mechanism to ensure that DID owner 201 knows that DID owner 201 solely controls DID 205. In this way, the provider of DID lifecycle management module 320 can ensure that the provider does not control DID 205, but only provides management services.

[0068] As previously described, the key generation module 350 generates a pair of private key 206 and public key 207, and the public key 207 is then recorded in the DID document 210. Therefore, the public key 207 can be used by all devices associated with the DID owner 201 and all third parties who wish to provide services to the DID owner 201. Therefore, when the DID owner 201 desires to associate a new device with the 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 register 310 to update the DID document 210 to reflect that the new device is now associated with the DID 205 and this will be reflected in the updated transaction on the distributed ledger 220, as previously described.

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

[0070] In embodiments where the additional public keys 208 and 209 are associated with different devices, the additional public keys 208 and 209 may be recorded in the DID document 210 as being associated with those devices. Figure 3 It should be understood that except Figure 3 In addition to the information shown, the DID document 210 may also include information previously provided about Figure 2 If the DID document 210 existed before the device-specific public key was generated, the DID document 210 would be updated by the creation module 330 via the register 310 , and this would be reflected in the updated transaction on the distributed ledger 220 .

[0071] In some embodiments, the DID owner 201 may wish to keep the association of the device with the public key or even with the DID 205 secret. Therefore, the DID creation module 330 may cause such data to be shown in the DID document 210 secretly.

[0072] As described so far, DID 205 has been associated with all devices under the control of DID owner 201, even when those devices have their own public keys. However, in some embodiments, it may be useful for each device or some subset of devices under the control of DID owner 201 to have their own DID. Therefore, in some embodiments, DID creation module 330 may generate additional DIDs, such as DID 331, for each device. The creation module would then generate private and public key pairs and DID documents for each of these devices and record them on distributed ledger 220 in the manner previously described. Such an embodiment may be advantageous for devices that may change ownership, because it is possible to associate a particular device DID with a new owner of the device by granting authorization permissions to the new owner in the DID document and revoking such permissions from the old owner.

[0073] As described above, to ensure that the private key is completely under the control of the DID owner 201, the private key is created on a user device 301, a browser 302, or an operating system 303 owned or controlled by the DID owner 201 executing the DID management module 320. In this way, there is little chance that a third party, especially a provider of the DID lifecycle management module 320, can gain control of the private key 206. However, the DID owner 201 may lose the device storing the private key 206, which may cause the DID owner 201 to lose access to the DID 205. Therefore, in some embodiments, the UI 335 may include an option to allow the DID owner 201 to export the private key 206 to an off-device secure database 305 under the control of the DID owner 201. In some embodiments, the private key 206 may be stored as a QR code that can be scanned by the DID owner 201.

[0074] In some other embodiments, the DID lifecycle management module 320 may include a recovery module 360 ​​that 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 the DID 205, which can later be used to recover the lost private key. In embodiments with a UI 335, the UI 335 can allow the DID owner 201 to provide the required information that will be needed by the one or more recovery mechanisms 365 when implementing the recovery mechanism. The recovery module can then be run on any device associated with the DID 205.

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

[0076] Figure 4 An embodiment of an environment 400 in which a DID such as DID 205 may be utilized is shown. Specifically, environment 400 will be used to describe the use of DID 205 associated with one or more decentralized storage devices or identity hubs. It should be noted that Figure 4 This may include first Figure 2 or 3 are references to elements discussed above and therefore the same figure numbers are used for ease of explanation.

[0077] In one embodiment, identity hub 410 can be multiple instances of the same identity hub. This is represented by line 410A. Therefore, various identity hubs 410 can include at least some of the same data and services. Therefore, if any changes are made to one of the identity hubs in identity hub 410, the change can be reflected in the remaining identity hubs. For example, the first identity hub 411 and the second identity hub 412 are implemented in a cloud storage device, and therefore can be able to hold a large amount of data. Therefore, a complete data set can be stored in these identity hubs. However, identity hub 412 and identity hub 413 may have less memory space. Therefore, in these identity hubs, descriptors of the data stored in the first identity hub and the second identity hub may be included. Alternatively, records of changes made to the data in other identity hubs may be included. Therefore, changes in one of the identity hubs in identity hub 410 are either completely replicated in other identity hubs, or at least records or descriptors of the data are recorded in other identity hubs.

[0078] Because identity hubs can be multiple instances of the same identity hub, only a complete description of the first identity hub 411 will be provided, as the description may also apply to identity hubs 412-415. As shown, identity hub 411 may include a data storage device 420. Data storage device 420 may be used to store any type of data associated with DID owner 201. In one embodiment, the data may be a collection 422 of a particular type of data corresponding to a particular protocol. For example, collection 422 may be medical record data corresponding to a particular protocol for medical data. Collection 422 may be any other type of data.

[0079] 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 data may have settings 421 that allow the data to be exposed publicly but do not include any authentication of the DID owner 201. This type of data may be used for relatively unimportant data, such as color schemes, etc. A second subset of data may have settings 421 that allow the data to be exposed publicly and include authentication of the DID owner 201. A third subset of data may have settings 421 that encrypt the subset of data using a private key 206 and a public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data would require a party to have access to the public key 207 or some other associated public key in order to decrypt the data. The process may also include authentication of the DID owner 201. A fourth subset of data may have settings 421 that restrict the data to a subset of third parties. This may require the use of a public key associated with the subset of third parties to decrypt the data. For example, DID owner 201 may have setting 421 specify that only public keys associated with friends of DID owner 201 may decrypt the data.

[0080] In some embodiments, identity hub 411 may have a permission module 430 that allows DID owner 201 to set specific authorizations or permissions for third parties such as third party 401 and third party 402 to access identity hub. For example, DID owner 201 may provide his or her spouse with access permissions to all data 420. Alternatively, DID owner 201 may allow access to his or her doctor to obtain any medical records. It should be understood that DID owner 201 may allow any number of third parties to access a subset of data 420. This will be explained in more detail below.

[0081] Identity hub 411 may also have a messaging module 440. In operation, the messaging module allows the identity hub to receive messages, such as receiving requests from parties (such as third party 401 and third party 402) to access the data and services of the identity hub. In addition, messaging module 440 allows identity hub 411 to respond to messages from third parties and also communicate with DID resolver 450. This will be explained in more detail below. Ellipsis 416 indicates that identity hub 411 may have additional services depending on the situation.

[0082] In one embodiment, the DID owner 201 may wish to authenticate the new device 301 to the identity hub 411 that is already associated with the DID 205 in the manner previously described. Therefore, the DID owner 201 may utilize the DID management module 320 associated with the new user device 301 to send a message to the identity hub 411 to declare that the new user device is associated with the DID 205 of the DID owner 201.

[0083] However, identity hub 411 may not initially recognize the new device as owned by DID owner 201. Therefore, identity hub 411 may contact DID resolver 450 using messaging module 440. The message sent to DID resolver 450 may include DID 205.

[0084] DID resolver 450 may be a service, application, or module that is configured in operation to search distributed ledger 220 for a DID document associated with a DID. Thus, 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 may then be provided to identity hub 411.

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

[0086] In this embodiment, the challenge can be successfully answered because the new user device is owned by DID owner 201 and therefore has access to private key 206. Identity hub 411 can then record in permission module 430 that the new user device 301 can access the data and services of identity hub 411 and the remaining identity hubs in identity hub 411.

[0087] It will be noted that this process of authenticating the new user device 301 is performed without requiring the DID owner 201 to provide any username, password, etc. to the provider of the identity hub 411 (i.e., the first cloud storage provider) before the identity hub 411 can be accessed. Instead, access is determined in a decentralized manner based on the DID 205, the DID document 210, and the associated public and private keys. Since these are always in the control of the DID owner 201, the provider of the identity hub 411 is not involved and is therefore unaware of the transaction or any personal information of the DID owner 201.

[0088] In another example embodiment, DID owner 201 may provide DID 205 to third-party entity 401 so that the third party may access data or services stored on identity hub 411. For example, DID owner 201 may be a human being at a scientific conference who desires to allow third party 401, who is also a human being, to access his or her research data. Thus, DID owner 201 may provide DID 205 to third party 401.

[0089] Once the third party 401 has access to the DID 205, he or she can access the DID resolver 450 to access the DID document 210. As previously described, the DID document 210 can include an endpoint 213, which is an address or pointer to the identity hub 411. The third party 401 can then use the address or pointer to access the identity hub 411.

[0090] Third party 401 may send a message to messaging module 440 to request permission to access the research data. Messaging module 440 may then send a message to DID owner 201 to ask whether third party 401 should be given access to the research data. Because the DID owner desires to provide access to the data, DID owner 201 may allow permission to third party 401, and the permission may be recorded in permission module 430.

[0091] Messaging module 440 may then send a message to third party 401 to notify the third party that he or she can access the research data. Identity hub 411 and third party 401 may then communicate directly so that the third party can access the data. It should be noted that in many cases, it is actually the identity hub associated with third party 401 that is communicating with identity hub 411. However, it may be the device of third party 401 that is communicating.

[0092] Advantageously, the above process allows the identity hub 411 and third parties 401 to communicate and share data without requiring the third party to access the identity hub 411 in a conventional manner. Instead, communication is provided in a decentralized manner using the DID 205 and the DID document 210. This advantageously allows the DID owner to have full control over the process.

[0093] like Figure 4 As shown, third party 402 may also use DID 205 and DID document 210 to request permission to access identity hub 411. Thus, embodiments disclosed herein allow any number of third parties to access identity hub 411.

[0094] Having described an example environment for creating a DID and an example environment for various DID lifecycle management operations and services, we will now discuss Figure 5 A simplified comparison between a “centralized” data system and a “decentralized” data system (that implements DIDs).

[0095] Figure 5 , one or more centralized data systems 501 are shown on the left side of . A "centralized data system" as referred to herein is a database or data system stored and maintained by a centralized organization. The database or data system may be located in a single location as a true "centralized" data system, or it may be a distributed database including multiple database files located in different locations. However, whether the data system is located in a single location or multiple locations, as long as the data system is stored and maintained by a centralized organization, such a data system is referred to as a "centralized data system" herein.

[0096] Most existing data systems are centralized. For example, Figure 5 As shown, medical database 510 is an example centralized database. Medical database 510 may be stored and maintained by a hospital, clinic office, and / or data service provider. Medical database 510 includes Alice's data 511 and Bob's data 512. Ellipses 513 indicate that there may be any number of patient's records stored in medical database 510. Currently, even though the law may require health service providers to make medical data available to the respective patients, each patient typically cannot continuously access his / her own medical data. If a patient wants to review his / her complete medical history, he / she typically needs to submit a written request or request in person.

[0097] In addition, the social media database 520 and the email database 530 are also examples of centralized data systems. For example, a social media company (e.g., Facebook) maintains its own database 520, which may include personal information of each user, content generated by the corresponding user, communications between the corresponding user and other users, etc. Figure 5 As shown, social media database 520 may include Alice's records (i.e., Alice data 521) and Bob's records (i.e., Bob data 522). Alice 521's records may include personal information that Alice entered in the settings, her friend's ID, messages posted by Alice, advertisements clicked by Alice, etc. Similarly, Bob's records 522 may include similar types of information associated with Bob's social media account. Ellipsis 523 indicates that any number of user records may be stored in social media database 520, which are controlled and maintained by the social media service provider. Even in this case, each social media account holder can usually access his / her own account information, but the social media service provider has real control over all data. For example, if the server of the social media service provider is shut down or the hard disk crashes, the user may lose connection or even lose data. Another example, if the server of the social media service is hacked, the user's information may be lost even if the user is unaware.

[0098] Similarly, email database 530 is another example of a centralized data system. Email database 530 is controlled and maintained by an email service provider (e.g., outlook.com, gmail.com, etc.). Most existing service providers maintain their own email servers, and each user must register an account with the email server to obtain an email account. Once an email account is registered, the account is stored on a server maintained by the service provider. For example, Figure 5 As shown, the email database 530 hosted by the email server may include Alice's email account data 531 and Bob's email account data 532. Ellipses 533 indicate that there may be any number of email account records stored in the email database 530. Alice's email account data 531 may include her personal information entered when she registered the email account. Alice's email data 531 may also include all emails received and sent by her using the email account. Similarly, Bob's email account data 432 may include similar information related to Bob's email account. If the email server is shut down, the user will not be able to receive or send emails, and will not be able to retrieve his / her email history unless a local copy is stored on the user's own device. Email servers may also be vulnerable to cyber attacks. When such an attack occurs, users usually do not realize that their information has been hacked.

[0099] Figure 5The right side of FIG. 5 shows a simplified decentralized system 502 that provides each DID owner with a personal storage device in the ID hub 550. The personal storage device in the ID hub 550 is controlled by the DID owner, not by a centralized organization. For example, Figure 5 As shown, ID hub 550 includes Alice's personal storage device and Bob's personal storage device. Ellipsis 580 indicates that there may be any number of personal storage devices, each of which is associated with a DID (or DID owner).

[0100] Alice's personal storage device 560 includes Alice's medical data 561, Alice's social media data 562, and Alice's email data 563. Ellipsis 564 indicates that Alice's other types of personal data may be stored in Alice's personal storage device 560 in the ID hub 550. Similarly, Bob's personal storage device 570 stores Bob's medical data 571, Bob's social media data 572, and Bob's email data 573. Ellipsis 574 indicates that Bob's other types of personal data may be stored in Bob's personal storage device 570 in the ID hub 550.

[0101] In the decentralized system 502, each DID owner has great control over his / her own personal data via his / her DID. For example, Alice 566 has access to personal storage 560 via her DID 565; and Bob 576 has access to his / her personal storage 570 via his DID 575. Without the consent of each user, no centralized entity can access the information and data of all users. In theory, as long as the user stores his / her DID (or the private key of his / her DID) securely, others cannot crack the data stored in the ID hub. Compared with the centralized data system 501 on the left, it is clear that, unlike the centralized data system 501 in which each centralized organization maintains and controls the data of each user, the decentralized system 502 allows each user (e.g., DID owner) in the user to store and control his / her own data individually. The user (eg, DID owner) can decide whether the data should be made public and / or who can access the data; and the user can also decide whether he / she wants to delete any part of the data or make any changes to it.

[0102] As described above, decentralized systems typically give users (e.g., DID owners) a great deal of control over their data; and in such decentralized systems, centralized organizations typically no longer have control over each user's data. However, governments and organizations typically have laws and / or rules that regulate certain types of data. The principles described herein will allow such laws and / or rules to be implemented in a decentralized system so that even though users (e.g., DID owners) still have a great deal of control over their own data, the laws and rules can still be enforced.

[0103] Figure 6 An example embodiment in a decentralized environment 600 for enforcing one or more policy rules applicable to a data type is shown. Figure 6 As shown, the ID hub 650 may be similar to Figure 5 ID Hub 550 or Figure 4 ID hub 650 may be a cloud service that provides personal storage devices for multiple DID owners (e.g., Alice and Bob). Ellipsis 680 indicates that ID hub 650 may store personal data of any number of DID owners. Alice's personal data is stored in Alice's personal storage device 660 in ID hub 650. Bob's personal data is stored in Bob's personal storage device 670 in ID hub 650.

[0104] Alice's personal storage device 660 can store many different types of personal data, such as Alice's medical data 661, social media data 662, email data 663, etc. The ellipsis 666 indicates that Alice's personal storage device 660 can store other types of personal data of Alice. Figure 3 , 4 5, Alice 640 has a great deal of control over her personal data 661-663 via the DID management module 630. The DID management module 630 may be similar to Figure 3 The DID management module 320 is shown. For example, the DID management module 630 can be implemented on Alice's mobile device (eg, cell phone) and / or personal computer.

[0105] When entity 610 requests access to Alice's personal storage device 660 in ID hub 650 to operate on data stored or to be stored in storage device 660, the ID hub can notify Alice's DID management module 630. Alternatively, the notification can be sent directly from the device of entity 610 (e.g., a computing system) to Alice's DID management module 630 via a more direct communication channel. Alice's DID module 630 can then determine what type of data is stored or to be stored in Alice's personal storage device 660. After determining the type of data, one or more applicable policy rules can be accessed. Based on one or more applicable policy rules, Alice's DID management module 630 can then determine whether the operation on Alice's data will cause the data to comply with one or more applicable policy rules.

[0106] Policy rules may be stored in a policy rule library 620. The policy rule library 620 may be a cloud-based service that stores many available policy rules 621-623. The ellipsis 623 indicates that any number of policy rules may be stored in the policy rule library. The policy rule library 620 may include many third-party rules 621, such as rules of different governments applicable to different types of personal data. The third-party rules 621 may also include rules of different organizations applicable to data related to the corresponding organization. The policy rule library 620 may also include personal rules 622 set by some of the DID owners. The personal rules may be stored together with an address (or link) pointing to the DID owner's personal storage device 660 or to the DID management module 630, or stored together with an identifier that can be traced to the DID. The ellipsis 623 indicates that there may be other types of rules that do not fall into the third-party rules 621 or the personal rules 622. For example, some rules set by one DID owner may affect the data access of another DID owner.

[0107] Alternatively or additionally, at least some of the policy rules may be stored in the DID management module 630. For example, Alice's DID management module 630 may store some third-party rules 631 related to Alice's personal data. Alice's DID management module may also store some or all of Alice's personal rules. Alternatively or additionally, at least some of the policy rules may be stored in Alice's personal storage device 660 and / or in a common storage area in the ID hub 650, which may be accessible to each DID owner or DID owner's personal storage device in the DID owner's personal storage device.

[0108] The dotted line indicates that not necessarily only one of the above storage devices can store all or part of the policy rules. More than one storage device can store policy rules at the same time. For example, in some embodiments, the policy rule library 620 can store a large set of rules accessible by multiple ID hubs or different DID management modules provided by different DID system providers. In some embodiments, the policy rule library 620 may not store any personal rules at all. In some embodiments, the DID hub 650 can store a subset of rules applicable to the data of the DID owner stored in a specific DID hub 650. The DID owner's personal storage device (e.g., Alice's personal storage device 660) and / or the corresponding DID management module (e.g., Alice's DID management module 630) can store only her personal rules and / or only third-party rules applicable to her own data.

[0109] In some embodiments, the policy rule base 620 can allow each of the rule setters (e.g., government entities and / or organizations) to input and update their own rules. In some embodiments, the policy rule base 620 can periodically contact each of the third-party rule setters to inquire whether the existing rules have changed. If the rules change, the service provider of the policy rule base 620 can manually or automatically update the rules. The third-party rules 631 stored in Alice's DID management module 630, Alice's personal storage device 660, and / or ID hub 650 can also be updated regularly. These updates can be based on updates in the policy rule base 620, or directly triggered by notifications from the rule setters.

[0110] In addition, third-party rules do not have to be stored in at least one of the above-mentioned storage devices. Each rule setter (e.g., a government entity or organization) can maintain its own rules on its own web page or server. The policy rule library 620 may include only a list of links (e.g., URLs), each of which links (e.g., URLs) to a rule server of a corresponding government or organization. Alternatively, the list of links may be stored in Alice's DID management module 640, Alice's personal storage device 660, and / or ID hub 650. The DID owner's DID management module 630, personal storage device 660, and / or ID hub 650 can communicate directly with each of the rule setter's servers to obtain applicable rules.

[0111] like Figure 6As shown, when entity 610 requests an operation on Alice's medical data 661, Alice's DID management module 630 can receive notifications from Alice's personal storage device 660, ID hub 650, and / or entity 610. Each of the dashed arrow lines 691, 692, and 693 represents a communication channel to the DID management module of the DID owner (e.g., Alice's DID management module 630). Any one or more of these communication channels (691, 692, and / or 693) can be implemented for the DID management module of the DID owner (e.g., Alice's DID management module 630) to receive notifications of data requests from entity 610.

[0112] Next, based on the received notification, Alice's DID management module 630 determines what type of data is requested. Figure 6 As shown, in this case, the data type is medical data. Based on the determined data type, Alice's DID management module 630 will then determine whether there are any policy rules applicable to the determined data type (e.g., medical data). Alice's DID management module 630 can access any one or more of the above-mentioned storage devices (including but not limited to policy rule library 620, ID hub 650, Alice's personal storage device 660, Alice's DID management module 630), and policy rules can be stored in these storage devices.

[0113] For example, in some embodiments, Alice's DID management module 630 accesses more than one storage device substantially simultaneously. In some embodiments, Alice's DID management module 630 first accesses local storage and / or Alice's personal storage device and checks whether there are applicable third-party rules or personal rules for medical data. In the event that applicable rules 631 are not stored in the management module, the DID management module 630 may then access the policy rule library 620 to see if there are additional rules that may be applicable.

[0114] Furthermore, in addition to the data type, other factors may be considered in determining whether any applicable rules exist, such as information related to the requesting entity 610, and / or the locations of the parties (e.g., the location of the DID owner, the location of the ID hub, the location of the requesting entity 610, etc.). For example, the entity 610 may be a doctor located in the United States. The doctor 610 may request that Alice's medical data 661 be recorded in Alice's personal storage device 660.

[0115] When the ID hub 650 and / or Alice's personal storage device 660 receives a request from an entity 610 (e.g., a doctor), Alice's DID management module determines that there are many policy rules applicable to medical data. However, each country / region may have a different set of rules to regulate the handling of medical data. Alice's DID management module 630 can further filter all policy rules applicable to medical data based on the doctor's location (e.g., the United States). In this case, only the US rules will apply. Additionally, based on the hospital or clinic where the doctor 610 works, there may be additional rules set by the hospital or clinic that apply here.

[0116] In addition to the third-party rules, Alice's DID management module 630 may also access Alice's personal rules 622, 632, 665, and / or 692. Alice 640 may have set more rules to restrict access to her medical data 661. If Alice's personal rules are stricter than third-party rules (e.g., government rules or hospital rules) applicable to Alice's medical data, the DID management module 630 may allow Alice's personal rules 632 to override the third-party rules. However, if Alice's personal rules are not as strict as the third-party rules, the DID management module 630 may decide to ignore Alice's personal rules and apply the third-party rules.

[0117] In some embodiments, when the DID owner's personal rules conflict with third-party rules, the DID management module 630 can generate a notification to the DID owner before granting or denying the request. The DID owner can interact with the notification and manually determine whether the request should be approved or denied on the fly.

[0118] As another example, entity 610 may be a potential employer of Alice. Alice's potential employer 610 may request access to Alice's social media data 662 stored in Alice's personal storage device 660. ID hub 650 or Alice's personal storage device 660 receives the request from Alice's employer 610 and sends a notification to Alice's DID management module 630. Alice's DID management module 630 will then determine what type of data is requested. In this case, the data type is social media data. Based on this determination, Alice's DID management module 630 accesses one or more policy rules that may apply to social media data.

[0119] There may not be any government rules regulating access to social media data, but the social media service provider may have set some rules. The social media service provider may require the account owner's consent to allow third parties to access the user's social media content. If Alice 640 has not set personal rules to agree to the potential employer's request, such a request may be automatically denied. After the request is denied, Alice's DID management module 630 may then send a notification to Alice to inform her that her potential employer has requested access to her social media data 662, but that the request has been denied.

[0120] After receiving the notification, Alice can then decide to set a personal rule at her DID management module 630 to approve her potential employer's request. When her potential employer 610 requests the same operation again, the request will be approved based on the newly entered personal rule. Alice's personal rules can be very specific. For example, in this case, Alice can set a personal rule to grant her potential employer permission to access her social media data 662 only once or for a very limited period of time (e.g., a week or a month).

[0121] In some embodiments, when a certain type of data is requested to be entered or accessed for the first time, Alice's DID management module 630 may only need to access the policy rule library 620 and / or the rules stored in the ID hub. Thereafter, Alice's DID management module 630 may store the accessed relevant rules in Alice's personal storage device 660 in the DID management module 630 and / or the ID hub 650. Rules applicable to a specific type of data may be stored in the personal storage device of the DID owner together with the specific type of data. For example, rules applicable to medical data may be stored together with Alice's medical data 661. When Alice's medical data is accessed for the second time, Alice's DID management module 630 will be able to quickly retrieve and apply the rules stored in Alice's DID management module 630 and / or in Alice's personal storage device 660.

[0122] The policy rule base 620 can be periodically updated by the cloud service provider based on the rules of different governments and / or organizations. As briefly described above, the cloud service provider can also grant permission to each entity in the government or organizational entity so that these entities can update the rules on their own. Once the rules in the policy rule base 620 are updated, the policy rule base 620 can notify Alice's DID management module, Alice's personal storage device 660, and / or the ID hub 650 to update the rules stored in each of these storage devices. Alternatively, Alice's DID management module 630, Alice's personal storage device 660, and / or the ID hub 650 can periodically access the policy rule base 620 to check whether the rules have been updated.

[0123] In addition, after the data operation is completed, Alice's personal management module 630 can generate a notification to show whether the data operation is successful or failed or an overview of what happened to the requested data. The notification can be based on the DID owner's selection. The DID owner can choose not to receive any notifications. Alternatively, the DID owner can choose to receive notifications only in certain cases. For example, Alice can choose to receive notifications only when her medical data 661 is updated. In some embodiments, the DID owner can choose to receive simple notifications or complex notifications. For example, Alice can choose to receive notifications indicating that some of her data has been accessed by others. Alternatively, Alice can choose to receive a comprehensive notification including more information. For example, when Alice's family doctor enters a new record in Alice's medical data 661, the notification can show the date and time when the new record is entered, the size of the new record, and even the detailed information of the new record.

[0124] Alternatively, in some embodiments, when an operation is requested on the data of one DID owner, the other DID owner may be notified. For example, if Alice is a minor, when Alice's data is requested, her parents may receive notification from the parent's DID management module and / or via any other communication channel, even if such access does not violate any rules.

[0125] In some embodiments, entity 610 may also be the owner of the DID. The DID document of entity 610 may include information related to the DID owner and / or the relationship between the DID owner and Alice. For example, the DID of entity 610 may indicate that entity 610 is Alice's current family doctor. In such a case, even if one or more rules apply to Alice's medical data, applying these rules may still allow entity 610 to read and update Alice's medical data 661. Every time Alice visits her family doctor 610, family doctor 610 will update her medical data 661 stored in her personal storage device 660. Each of these data transactions may then be recorded in a blockchain. The blockchain for medical data may be a private blockchain. Alternatively, a public blockchain that does not record information that can be easily traced to a specific individual may be implemented.

[0126] As another example, entity 610 may even be Alice 640 herself. When Alice 640 requests access to her own medical data 661, there may also be certain applicable rules. For example, she may not be allowed to modify medical data 661, even if medical data 661 is stored in her personal storage device 660. If Alice 640 requests to update her medical data 661, DID management module 630 may apply a rule that prohibits anyone other than a doctor from modifying any medical data and deny her request to modify her own medical data 661.

[0127] The following discussion now relates to various methods and method actions that can be performed. Although method actions may be discussed in a particular order or illustrated in a flowchart as occurring in a particular order, no particular order is required unless otherwise specified or because one action depends on another action being completed before the action is performed.

[0128] Figure 7 1 shows a flow chart of an example method 700 for enforcing one or more policy rules applicable to a data type. The method 700 is related to the previously discussed Figure 2-Figure 6 The invention may be described in one or more of the accompanying drawings.

[0129] Method 700 includes receiving a request from an entity for an operation on data that is stored or is to be stored in a storage device associated with an owner of a DID (701). The entity may be Figure 6 The data stored in the storage device associated with the owner of the DID may be Alice's medical data 661, social media data 662, and / or email data 663 stored in Alice's personal storage device 660, such as Figure 6As shown. Alice's personal storage device 660 can be hosted in the ID hub 650 via a cloud service provider. After the entity requests an operation on the data, the notification can be notified by the DID management module 630 of the DID owner. For example, Figure 6 As shown, entity 610 may request access to Alice's medical data 661. Thereafter, Alice's DID management module 630 receives notification of the request. The notification may be sent from Alice's personal storage device 660, ID hub 650, and / or a device of entity 610.

[0130] After receiving the request, the type of data being requested is determined (702). Based on the determined type of data, one or more policy rules applicable to the type of data are accessed (703). Thereafter, the one or more applicable rules are applied to the requested data so that a determination can be made as to whether the operation will cause the data to comply with the one or more policy rules (704). If the operation will cause the data to comply with the one or more policy rules, the operation is allowed (705). If the operation will not cause the data to comply with the one or more policy rules, the operation is denied (706).

[0131] Figure 8 A flowchart of an example method 800 for determining the type of data requested to be operated on is illustrated, which may correspond to an embodiment of step 702 of method 700, which may correspond to an embodiment of step 703 of method 700. Method 702 may include scanning metadata of data to determine the type of data (801). After the type of data is determined, one or more policy rules may be accessed (802, 803, 804, 805, and / or 806). In some embodiments, the policy rules may be stored in a policy rule library 620, and thus the policy rule library is accessed (802). In some embodiments, the policy rules may be stored in an ID hub 650, and each storage device in the storage device of the DID owner may access the ID hub 650, and thus the ID hub 650 is accessed (803). In some embodiments, the policy rules may be stored in a personal storage device of the DID owner, and thus the personal storage device of the DID owner is accessed (804). In some embodiments, the policy rules may be stored in a DID management module, and thus the DID management module is accessed (805). Policy rules do not have to be stored in only one place. For example, policy rules may be stored in policy rule repository 620 and may also be stored in ID hub 650, and either or both storage devices may be accessed.

[0132] Each storage device in the storage device can be accessed substantially simultaneously or sequentially. For example, in some embodiments, the policy rules stored locally in the DID management module 630 can be accessed first (805). If no applicable rules are found in the DID management module 630, the policy rules stored in the ID hub 650 can be accessed (803). If no applicable rules are still found in the ID hub 650, the policy rule library 620 can be accessed (802). In some embodiments, personal rules 622, 634, 666 can be accessed first, and then third-party rules 621, 632, 664 can be accessed, and vice versa.

[0133] Ellipsis 806 indicates that the policy rules may also be stored in some other storage devices. For example, some of the policy rules may be stored in a government or organization's website or server, and only the address or link of the policy rule may be stored in a policy rule base, ID Hub, a DID owner's storage device, and / or a DID management module. In such an embodiment, unless the link to the policy rule has changed, there is little need to update the policy rule base. However, each time a policy rule is accessed, the system may need to access a remote server, which may cost additional network bandwidth, other resources, and / or time to complete the process.

[0134] Additionally, method 800 includes determining whether one or more policy rules are applicable to the determined data type (807). After determining step 807, applicable rules may be further filtered based on additional information, including but not limited to information related to the DID owner, the data requesting entity, and / or the data generating entity (808).

[0135] The policy rule base accessed in step 802 is intended to include a large set of policy rules applicable to different data types. When the policy rule base is accessed, a large number of policy rules can first be filtered based on the data type, and only the rules applicable to the data type are sent to the DID management module 630. However, in some cases, the policy rules applicable to the data type may still include too many rules. For example, each country and / or state may have slightly different regulations on medical data. In such a case, it would be unnecessary to apply all rules related to medical data to the medical data of a specific DID owner. Therefore, the policy rules applicable to the data type can be further filtered based on additional information to fit the data of a specific DID owner (808). For example, the rules applicable to medical data can be further filtered based on the geographic location of the DID owner, the geographic location of the data, the geographic location of the requesting entity, and / or the geographic location of the entity generating the data (e.g., the location of the doctor).

[0136] In some embodiments, policy rules (808) may also be filtered based on other information about the DID owner, information about the entity that generated or updated the data, and / or information about the requesting entity. For example, the entity requesting the data may be a government employer of the DID owner. The requested data may be the results of a random drug test ordered by the government employer. In such a case, there may be special policy rules that allow the government employer to access the random drug test results, even though drug test results are typically a type of medical data.

[0137] Fig. 9 A flow chart of an example method 900 for determining whether an operation will cause data to comply with one or more policy rules is shown, which method 900 may correspond to an embodiment of step 704 of method 700. Method 900 may include analyzing a relationship of one or more applicable rules and, based on the analysis, determining whether one rule should override another rule (901).

[0138] One or more applicable rules may overlap and / or complement each other. One or more applicable rules may also conflict with each other. In particular, certain third-party rules may conflict with certain personal rules. For example, government regulations may require that certain data be retained for a threshold number of years, certain data may not be changed once entered, certain data should not be accessible to third parties even if the DID owner agrees (e.g., the DID owner is a minor), etc.

[0139] For example, the government may require that tax records be retained for at least 3 years. In this case, even if the DID owner wants to delete his / her tax records, or grant another party permission to delete such records, applicable rules may prohibit such operations. Similarly, if the DID owner wants to change his / her criminal record, government rules may prohibit such a request. Therefore, even if the DID owner's criminal record may be stored in his / her personal storage device, he / she may not be allowed to change his / her criminal record. In another example, the DID owner may be a minor who has agreed to disclose some of his / her personal records to third parties. Although such consent generally allows third parties to access the personal data of adults, when the DID owner is a minor, the consent may be overridden by default denial.

[0140] Based on the determination 901 of whether at least one rule should override another rule, a final determination is made as to whether the request should be approved or denied (902). The final determination may then be sent to a party (903, 904, 905) and / or recorded in a storage device (906). The determination may be sent simultaneously or sequentially to one or more parties, including but not limited to the DID hub 650, the DID owner (e.g., the DID owner's management module 630, the DID owner's personal storage device 660, the DID owner's email address, the DID owner's phone number via SMS, and / or a second DID owner (e.g., a parent of a minor).

[0141] In some embodiments, the determination may be sent to the ID hub (902). After the ID hub receives the determination, the ID hub may further determine whether the determination should be sent to the DID owner or some other DID owner. In some embodiments, the determination may be sent directly to the DID owner (903). For example, the DID management module 630 may generate a notification on the DID owner's mobile device and notify the DID owner that the request has been approved or rejected. In some embodiments, the determination may also be sent to a second DID owner (904). For example, when the DID owner is a minor, his / her parent or guardian may be notified of the determination. Another example, a user may have multiple DIDs, or each of the same user's devices may have a separate DID, and the user may wish to receive notifications on each of his / her devices.

[0142] In some embodiments, the determination may be recorded in the ID hub (907), in the personal storage device of the DID owner (908), in the personal storage device of the second DID owner (909), and / or in the DID management module (910). The recorded determination may be stored with the rule as part of the rule application history. When similar requests are received, the determination of similar requests should generally be similar to the determination of past requests. If the determination of the new request is different from the determination in the record, an additional notification or alert may be and is sent to the DID owner, or the request may be temporarily suspended to await the approval or confirmation of the DID owner.

[0143] Fig.10The flowchart illustrates an example method 1000 for allowing a request, which can correspond to an embodiment of step 705 of method 700. The step of allowing (or denying) the request can be automatic or manual. The DID management module 630 can access one or more applicable policy rules and automatically determine whether the request should be allowed or denied. Thereafter, the DID management module 630 can automatically send the determination to the personal storage device of the DID owner to allow or deny the request entity access to the data.

[0144] In some embodiments, the step of allowing or denying the request may not be automatic. The DID management module 630 can generate a notification to the DID owner. The notification can show the DID owner (or a second DID owner) whether there are any rules (1002, 1005) applicable to the type of data requested. If the answer is yes, the notification can further show the DID owner whether the requested operation will cause the data to comply with the applicable policy rules (1003, 1004). The notification can prompt the user for an indication so that the user can confirm or override the determination made by the DID management module 630.

[0145] The DID owner can set personal rules to require the DID management module to notify the DID owner before each determination in making the determination. The DID owner can also set personal rules to require the DID management module to notify the DID owner only in certain situations. For example, when there are no applicable rules, the DID management module 630 can have a default determination to deny or allow the request, or request the DID owner to make a determination. The DID owner can enter their indication immediately. After receiving the user indication (1006), the DID management module 630 then allows (1007) or denies (1008) the request. The user indication and / or the result of the operation can then be recorded (1009) in the storage device. The user indication and / or the result of the operation can be stored as a personal rule in one or more storage devices. As Figure 8 shown, the rules can be stored in a policy rule library, an ID hub, the storage device of the DID owner or a second DID owner, and / or the DID management module.

[0146] The content of 1002 - 1005 represents the possible content of the notification. The dashed lines indicate that only some of the content in 1002 - 1005 can be sent to the DID owner. In some embodiments, or under certain user settings, no notification can be sent to the DID owner.

[0147] Arrow line 1010 and arrow line 1011 indicate that in some embodiments or under certain user settings, the permission or rejection request will be automatically executed without requiring user instructions. In some embodiments, or under some user settings, there may be no notification to be sent to the user, and the permission and rejection requests are automatically executed by the DID owner's DID management module 630. However, the operation results can still be stored in the storage device, and if the DID owner wants to review which operations have been performed in the past, he / she will still be able to review them conveniently.

[0148] The storage device for storing user instructions and / or operation results may be Figure 6 and Figure 8 The one or more storage devices shown include, but are not limited to, a DID owner's DID management module 630 , a DID owner's personal storage device 660 , an ID hub 650 , and a policy rule library 620 .

[0149] like Figure 2-Figure 4 As discussed in , in a decentralized system, many users will use decentralized identifiers to identify themselves. In such an environment, the entity requesting access to the DID owner's data may be another DID owner or the DID owner himself / herself. Fig.11 A flow diagram illustrating an example method 1100 for implementing one or more policy rules when a DID owner requests access to another DID owner's data or data storage device. In some cases, the two DID owners may be the same.

[0150] Method 1100 includes receiving a request from a first DID owner for an operation on data that is stored or is to be stored in a storage device associated with a second DID owner (1101). As described above, the first DID owner and the second DID owner may have the same DID, i.e., be the same DID owner. Alternatively, the first DID owner and the second DID owner may have different DIDs, i.e., be different DID owners.

[0151] After receiving the request, the type of data requested is then determined (1102). Based on the determined data type, one or more policy rules applicable to the data type and / or the first DID owner and / or the second DID owner are accessed (1103). Thereafter, the one or more applicable rules may be further filtered based on the information of the first DID owner and / or the second DID owner to generate a subset of one or more policy rules (1104). The subset of one or more policy rules is applicable to the requested data. For example, the geographic location of the first DID owner and / or the second DID owner may be used to determine whether rules for a particular country / region are applicable.

[0152] Based on the subset of one or more policy rules, a determination is made as to whether the operation will cause the data to comply with the subset of one or more policy rules (1105). If the determination is to allow the operation on the data, the first DID owner is granted access to the data (1106); and if the determination is to deny the operation on the data, the first DID owner is denied access to the data (1107). A record of the completed operation may then be recorded in a storage device or on a blockchain (1108). If the record of the completed operation is recorded on a blockchain, a chain of operations on the same piece of data may be conveniently retrieved from the blockchain.

[0153] For example, the requested data may be Alice's medical data. The first DID owner may be Alice's family doctor. Based on the type of data (e.g., medical data), one or more policy rules applicable to the medical data are accessed. Based on the information of the first DID owner and the second DID owner (e.g., the doctor-patient relationship, the location of the patient and / or doctor), one or more policy rules may then be filtered. Based on the additional information of the first DID owner and the second DID owner, a subset of one or more policy rules applicable to Alice's medical data may be filtered out. If Alice and her doctor are both in the United States, U.S. rules (e.g., the HIPAA privacy rule may be one of them) apply. Each policy rule in the subset of policy rules is then applied to Alice's medical data. In this case, the operation may cause the data to comply with a subset of one or more policy rules. Therefore, Alice's family doctor is likely to be granted permission to update Alice's medical data.

[0154] After Alice's medical data is updated by her family doctor, some information related to the transaction can be recorded in the blockchain. For example, the time of data entry, the doctor's DID information, and Alice's DID information can all be recorded in the blockchain. Such a blockchain can be a private blockchain because the records are related to personal medical data, unless the information stored in the blockchain cannot be easily traced to Alice's personal identity. Exactly what type of data will be recorded in the blockchain will be determined based on the type of data, the type of data operation, the applicable rules, and the type of decentralized service. Sensitive information can always be stored in Alice's personal storage device 660 and / or her DID management module 630.

[0155] For the process and method disclosed herein, the operations performed in the process and method can be implemented in different orders. In addition, the operations outlined are provided only as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with additional operations, or expanded into additional operations without departing from the essence of the disclosed embodiments.

[0156] The present invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments should be considered illustrative and not restrictive in all respects. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes that fall within the meaning and scope of the equivalents of the claims should be included within their scope.

Claims

1. A computing system, include: one or more processors; as well as One or more computer-readable hardware storage devices having computer-executable instructions thereon, the computer-executable instructions being structured to, when executed by the one or more processors, configure the computing system to: Receiving input for setting one or more policy rules, the one or more policy rules applicable to: (1) types of data of one or more users stored in a decentralized storage service, and (2) entities requesting an operation on the data of the users, the users being associated with a first decentralized identifier DID; storing the one or more policy rules at the computing system; receiving a request from an entity associated with a second DID to perform an operation on data, the data being stored or to be stored in a storage device associated with a user associated with a first DID, wherein the entity is provided with the first DID, causing the entity to access a distributed ledger containing a hash of the first DID to obtain a DID document associated with the first DID, the DID document containing a service endpoint of the decentralized storage service, and causing the entity to access the service endpoint in the decentralized storage service to request the user's data stored at the decentralized storage service; sending a notification to the user, the notification notifying the user associated with the first DID of a request from the entity to operate on data associated with the first DID stored in the decentralized storage service, wherein in response to receiving the notification, the user authenticates the entity associated with the second DID; determining the type of data requested to be operated on; accessing one or more policy rules applicable to the type of data; determining, based on the one or more policy rules, whether the operation to be performed on the data will cause the data to comply with the one or more policy rules; and Based on the determination, the request is allowed when the operation will cause the data to comply with the one or more policy rules.

2. The computing system of claim 1 , wherein the computing system is further configured to filter the one or more policy rules based on information associated with the user and / or the entity to determine a subset of the one or more policy rules applicable to the requested data, and wherein the accessing of the one or more policy rules applicable to the type of data is the subset of the one or more policy rules applicable to accessing data of the user.

3. A computing system according to claim 1, wherein the request is a request to store data generated by the entity in a storage device associated with the user associated with the first DID, or a request to read data stored in a storage device associated with the user.

4. The computing system of claim 3, wherein the determining whether the operation to be performed on the data will cause the data to comply with the one or more policy rules include: analyzing the relationship between the one or more applicable rules, and Based on analyzing the relationship between the one or more applicable rules, it is determined whether at least one rule should override another rule.

5. The computing system of claim 1 , wherein the act of determining the type of the data include: Scanning metadata of said data, and Based on the scanned metadata, at least one type of the data is determined. 6 . The computing system of claim 1 , wherein the one or more policy rules include personal rules determined by the user associated with the first DID.

7. The computing system of claim 1 , wherein at least one of the one or more policy rules is stored in the storage device associated with the user associated with the first DID, At least one of the one or more policy rules is stored at a remote server, and / or At least one policy rule of the one or more policy rules is stored at a DID control application implemented at the computing system.

8. The computing system of claim 1, further configured to: The one or more policy rules are generated in response to receiving the request from the entity.

9. The computing system of claim 1, wherein the allowing the request include: generating the notification when the operation to be performed on the data would cause the data to fail to comply with the one or more policy rules; as well as In response to the notification, an indication is received from the user associated with the first DID indicating whether the operation should be allowed or denied.

10. The computing system of claim 1, wherein the second DID is the same as or different from the first DID.

11. The computing system of claim 10, further configured to: filtering the one or more policy rules based on geographic information of the user associated with the first DID and / or the entity associated with the second DID to determine a subset of the one or more policy rules applicable to the requested data, Wherein said accessing one or more policy rules applicable to said type of data is accessing said subset of one or more policy rules applicable to said requested data.

12. A method for enforcing one or more policy rules applicable to a type of data at a decentralized storage device, the method include: Receiving input for setting one or more policy rules, the one or more policy rules applicable to: (1) types of data of one or more users stored in a decentralized storage service, and (2) entities requesting an operation on the data of the users, the users being associated with a first decentralized identifier DID; storing the one or more policy rules; receiving a request from an entity associated with a second DID to perform an operation on data, the data being stored or to be stored in a storage device associated with a user associated with a first DID, wherein the entity is provided with the first DID, causing the entity to access a distributed ledger containing a hash of the first DID to obtain a DID document associated with the first DID, the DID document containing a service endpoint of the decentralized storage service, and causing the entity to access the service endpoint in the decentralized storage service to request the user's data stored at the decentralized storage service; sending a notification to the user, the notification notifying the user associated with the first DID of a request from the entity to operate on data associated with the first DID stored in the decentralized storage service, wherein in response to receiving the notification, the user authenticates the entity associated with the second DID; determining the type of data requested to be operated on; accessing one or more policy rules applicable to the type of data; determining, based on the one or more policy rules, whether the operation to be performed on the data will cause the data to comply with the one or more policy rules; and Based on the determination, the request is allowed when the operation will cause the data to comply with the one or more policy rules.

13. The method according to claim 12, further comprising: include: filtering the one or more policy rules based on information about the user and / or the entity to determine a subset of the one or more policy rules applicable to the requested data, and wherein the accessing of the one or more policy rules applicable to the type of data is the subset of the one or more policy rules applicable to accessing data of the user.

14. A method according to claim 12, wherein the request is a request to store data generated by the entity in a storage device associated with the user associated with the first DID, or a request to read data stored in a storage device associated with the user.

15. The method of claim 12, wherein the determining whether the operation to be performed on the data will cause the data to comply with the one or more policy rules include: analyzing the relationship between the one or more applicable rules, and Based on analyzing the relationship between the one or more applicable rules, it is determined whether at least one rule should override another rule.

16. The method of claim 12, wherein determining the type of the data include: Scanning metadata of said data, and Based on the scanned metadata, at least one type of the data is determined.

17. The method of claim 12, wherein the one or more policy rules include personal rules determined by the user associated with the first DID.

18. The method of claim 12, wherein the allowing the request include: generating the notification when the operation to be performed on the data would cause the data to fail to comply with the one or more policy rules; as well as In response to the notification, an indication is received from the user associated with the first DID indicating whether the operation should be allowed or denied.

19. A computer program product, include: One or more computer-readable hardware storage devices having computer-executable instructions stored thereon, the computer-executable instructions being structured such that when the computer-executable instructions are executed by one or more processors of a computing system, the computer-executable instructions configure the computing system to perform at least the following actions: Receiving a request from an entity associated with a second decentralized identifier DID to perform an operation on data, the data being stored or to be stored in a storage device associated with a user associated with the first DID; determining the type of data requested to be operated on; accessing one or more policy rules applicable to the type of data; determining, based on the one or more policy rules, whether the operation to be performed on the data will cause the data to comply with the one or more policy rules; as well as Based on the determination, the request is allowed when the operation will cause the data to comply with the one or more policy rules.

20. The computer program product of claim 19, wherein the computing system is further configured to filter the one or more policy rules based on information associated with the user and / or the entity to determine a subset of the one or more policy rules that are applicable to the requested data, and wherein the accessing of the one or more policy rules applicable to the type of data is the subset of the one or more policy rules applicable to accessing data of the user.

Images