Event-based DID delegation authority transfer

Abstract

Embodiments relate to computing systems and methods for event-based DID delegation authority transfer. An indication that a first DID user is attempting to use a delegated DID on behalf of a second DID user is received. The first DID user has previously been delegated authority to use the delegated DID by operating a legal relationship or legal agreement between the first DID user and the second DID user. A determination is made as to whether an event has occurred that changes the legal relationship or legal agreement between the first DID user and the second DID user. If an event has occurred, the delegation of authority to use the delegated DID is automatically revoked so that the first DID user can no longer use the delegated DID. If the event has not yet occurred, the first DID user is allowed to continue using the delegated DID.

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 technologies, such as blockchain, offer the opportunity to use fully decentralized identifiers. Distributed ledger technologies use a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in that portion of the ledger cannot be retroactively changed without changing all subsequent portions of the ledger, which provides a fairly secure platform. Because DIDs are typically not controlled by a centralized management system, but rather owned by the owner of the DID, DIDs are sometimes referred to as unauthorized identities.

[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 computing systems and methods for event-based DID delegation authority transfer. An indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of a second DID user is received. The first DID user has previously been delegated the authority to use the delegated DID by operating a legal relationship or legal agreement between the first DID user and the second DID user that provides delegated authority. A determination is made as to whether an event has occurred that changes the legal relationship or legal agreement between the first DID user and the second DID user. If an event has occurred, the delegation of authority to use the delegated DID is automatically revoked, so that the first DID user can no longer use the delegated DID on behalf of the second DID user. If the event has not yet occurred, the first DID user is allowed to continue to use the delegated DID on behalf of the second DID user.

[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 given with reference to specific embodiments shown in the accompanying drawings. It is understood that these drawings depict only typical embodiments and are not therefore 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 example embodiment of a computing system environment for event-based DID delegated authorization transfer is illustrated; and

[0013] Figure 6A flow chart of an example method for event-based DID delegate authority transfer is illustrated. DETAILED DESCRIPTION

[0014] Embodiments disclosed herein relate to computing systems and methods for event-based DID authorization transfer. An indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of a second DID user. By operating a legal relationship or legal agreement between the first DID user and the second DID user that provides delegated authority. The first DID user has previously been delegated the authority to use the delegated DID. A determination is made as to whether an event has occurred that changes the legal relationship or legal agreement between the first DID user and the second DID user. If an event has occurred, the delegation of authority to use the delegated DID is automatically revoked, so that the first DID user can no longer use the delegated DID on behalf of the second DID user. If the event has not yet occurred, the first DID user is allowed to continue to use the delegated DID on behalf of the second DID user.

[0015] The embodiments disclosed herein represent a technological advancement over existing systems. For example, based on a legal relationship between a first DID user and a second DID user or based on a legal agreement between DID users, a first DID user may be given a delegation authority to use the DID of a second DID user on behalf of a second user. However, an event may occur that may change the legal relationship or legal agreement. For example, a child may become an adult, a couple may divorce, or a legal agreement may be terminated. In such an event, the second DID user may no longer want the first DID user to have the delegation authority to use the DID of the second user. Therefore, when an event occurs that changes the legal relationship or legal agreement, the delegation authority is revoked and control is returned to the second user. This improves the convenience and productivity of the user because the second DID is able to gain control of his or her DID. In addition, since the second user does not need to use computing resources to gain control of his or her DID after the event, time and processing resources are saved.

[0016] 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.

[0017] 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.

[0018] like Figure 1 As shown, in its most basic configuration, the computing system 100 typically includes at least one hardware processing unit 102 and memory 104. The processing unit 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If such actions are implemented in software, one or more processors (of the associated computing system 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.

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

[0024] 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.

[0025] 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.

[0026] "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.

[0027] 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.

[0028] Computer executable instructions include, for example, instructions and data that, when executed at a processor, cause a general purpose computing system, a special purpose computing system, or a special purpose processing device to perform a 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] The remaining figures may discuss various computing systems that may correspond to the previously described computing system 100. The computing systems of the remaining figures include various components or functional blocks that may implement the various embodiments disclosed herein as will be explained. The various components or functional blocks may be implemented on a local computing system, or may be implemented on a distributed computing system that includes elements residing in the cloud or that implements various aspects of cloud computing. The various components or functional blocks may 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 those shown in the figures, and some of the components may be combined as appropriate.

[0033] Now about Figure 2 Give some introductory discussion of decentralized identifiers (DIDs) and the environments in which they are created and reside. Figure 2 The diagram shows a portion of a decentralized network 200. 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.

[0034] 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, a department, a government, an agency, or any other organization or group of organizations. Each individual may have a DID, and each organization (or organizations) to which the individual belongs may also have a DID.

[0035] DID owner 201 may alternatively be a machine, system or device, or a collection of machines, devices and / or systems. In other embodiments, DID owner 201 may be a sub-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-part 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. Therefore, the artificial intelligence may also have a DID.

[0036] Thus, DID owner 201 may be any entity, human or non-human, that is capable of creating a DID 205 or at least has a DID 205 created for and / or 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.

[0037] As described above, DID owner 201 can create and register DID 205. DID 205 can be any identifier that can be associated with DID owner 201. Preferably, the identifier is unique to 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.

[0038] 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 authorities and remain under the control of enterprise directory services, certificate authorities, domain name registries, or other centralized authorities (collectively referred to herein as "centralized authorities"). Therefore, DID 205 can be any identifier that is under the control of DID owner 201 and independent of any centralized authority.

[0039] In some embodiments, the structure of DID 205 can be as simple as a username or some other human understandable term. However, in 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 in the figure as "123ABC".

[0040] Also like Figure 2As 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.

[0041] 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 centralized 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 as appropriate.

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

[0043] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 can be used by 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.

[0044] 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.

[0045] 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 right 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 owner 201 until the child is no longer a minor.

[0046] 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.

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

[0048] 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. Therefore, the identification information 214 listed in the DID document 210 may represent different personas of the DID owner 201 for different purposes.

[0049] For example, a persona can be pseudo-anonymous. As an example, a DID owner 201 can include a pseudonym in a DID document when identifying him or her as the author of an article published on a blog. A persona can be completely anonymous. As an example, a DID owner 201 may only want to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.) in a DID document, rather than his or her name. As yet another example, a persona can be specific to who the DID owner 201 is as an individual. As an example, a DID owner 201 can include information identifying him or her as a volunteer for a particular charity, an employee of a particular company, a winner of a particular award, etc., and so on.

[0050] DID document 210 may also include credential information 215. Credential information 215 may be any information associated with the background of DID owner 201. For example, credential information 215 may be, but is not limited to, qualifications, achievements, government IDs, government entitlements such as a passport or driver's license, payment providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of DID owner 201. In some embodiments, DID owner 201 collects various signed credentials included in the credential information from different third-party entities.

[0051] The DID document 210 may also include various other information 216. In some embodiments, the other information 216 may include metadata that specifies when the DID document 210 was created and / or when it was last modified. In some other embodiments, the other information 216 may include a cryptographic proof of the integrity of the DID document 210. In further 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.

[0052] Figure 2Also shown is a distributed ledger 220. The distributed ledger 220 may be any decentralized distributed network including various computing systems that communicate with each other. For example, the distributed ledger 220 may include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems as shown by ellipsis 260. The distributed ledger 220 may operate according to any known standard or method for distributed ledgers.

[0053] 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 the 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 220.

[0054] As described above, a representation of DID 205 is stored on each distributed computing system of distributed ledger 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 hashed 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.

[0055] In one embodiment, when DID owner 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger 220. Distributed ledger 220 thus records that DID 205 now exists. Because distributed ledger 220 is decentralized, DID 205 is not under the control of any entity other than DID owner 201. In addition to a pointer to DID document 210, DID hash 231, DID hash 241, and DID hash 251 may each include a record or timestamp specifying when DID 205 was created. At a later date, when modifications are made to DID document 210, each modification (and potentially also the timestamp of the modification) 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 .

[0056] Already referenced Figure 2 Having described DIDs and how they generally operate, a specific embodiment of a DID environment will now be explained. Figure 3 , a computing system environment 300 that can be used to perform various DID 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 .

[0057] like Figure 3 As shown, environment 300 may include various devices and computing systems that may be owned by DID owner 201 or otherwise under the control of DID owner 201. 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.

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

[0059] like Figure 3 As shown, the DID management module 320 includes a DID creation module 330. The DID creation module 330 can be used by the DID owner 201 to create the DID 205 or any number of additional DIDs, such as DID 331. In one embodiment, the DID creation module can 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.

[0060] 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 having a human-recognizable name for the display name may be advantageous. 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.

[0061] The DID creation module 330 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.

[0062] 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.

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

[0064] As previously described, the key generation module 350 generates a 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 the update will be reflected in the transaction on the distributed ledger 220, as previously described.

[0065] 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 device-specific 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 350 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.

[0066] 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 (information 208, 209 and 365), DID document 210 may also include previously 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.

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

[0068] 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. DID creation module 330 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 device-specific DID with a new owner of the device by granting authorization rights to the new owner in the DID document and revoking such rights from the old owner.

[0069] As described above, to ensure that the private key 206 is completely under the control of the DID owner 201, the private key 206 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 (and most importantly, the provider of the DID management module 320) can gain control of the private key 206.

[0070] However, DID owner 201 may lose the device storing private key 206, which may cause DID owner 201 to lose access to DID 205. Therefore, in some embodiments, UI 335 may include an option to allow DID owner 201 to export private key 206 to an off-device secure database 305 under the control of DID owner 201. As an example, database 305 may be the following about Figure 4 The storage module 380 is configured to store data (e.g., private key 206 or credential information 215 made by or about DID owner 201) outside the device in database 305 or identity hub 410, which will be described in more detail later. Of course, in some embodiments, if the device has sufficient storage resources, the storage module 380 can store at least some data on the device. In some embodiments, the private key 206 can be stored as a QR code that can be scanned by the DID owner 201.

[0071] 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 information to be used by the one or more recovery mechanisms 365 in the recovery process. The recovery module can then be run on any device associated with the DID 205.

[0072] The DID 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 370 may access the DID document 210 and may cause all references to the device to be removed from the DID document 210. 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.

[0073] Figure 4 An embodiment of a computing system 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 in association with one or more decentralized repositories or identity hubs 410, each under the control of DID owner 201 to store data belonging to or about DID owner 201. For example, DID 205 may be used to store data belonging to or about DID owner 201. Figure 3 The storage module 380 stores the data in the identity hub. 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.

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

[0075] Identity hub 410 may be any data repository that may be under the exclusive control of DID owner 201. By way of example only, first identity hub 411 and second identity hub 412 are implemented in cloud storage locations (possibly in the same cloud, or even on different clouds managed by different cloud providers), and thus may be able to hold large amounts of data. Thus, complete data sets may be stored in these identity hubs.

[0076] However, identity hub 413 and identity hub 414 may have less memory space. Therefore, in these identity hubs, descriptors of data stored in the first identity hub and the second identity hub may be included. Alternatively, records of changes made to data in other identity hubs may be included. Therefore, changes to one of the identity hubs in identity hub 410 are either completely replicated in the other identity hubs, or at least a record or descriptor of the data is recorded in the other identity hubs.

[0077] 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 through 414. 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 include any other type of data, such as credentials 215 made by or about DID owner 201.

[0078] In one embodiment, the stored data may have different authentication and privacy settings 421 associated with the stored data. For example, a first subset of 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 enable settings 421 to specify that only public keys associated with friends of DID owner 201 may decrypt the data. With respect to data stored by storage module 380, these settings 411 may be at least partially determined by Figure 3 The storage module 380 is composed of.

[0079] 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 access permissions to all data 420 to his or her spouse. 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. With respect to data stored by storage module 380, these access permissions 430 may be at least partially determined by Figure 3 The storage module 380 is composed of.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 430 that new user device 301 can access the data and services of identity hub 411 and the remaining identity hubs in identity hub 410.

[0086] 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.

[0087] 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.

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

[0089] Completing the research data example, 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 430.

[0090] 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.

[0091] 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.

[0092] 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 410.

[0093] Figure 5An embodiment of a computing system environment 500 is illustrated, which will be used to explain the event-based DID delegation authority transfer according to the embodiments disclosed herein. It should be noted that since the computing system environment 500 can correspond to one or more of the computing system environments 100 to 400 described previously, Figure 5 Can include first about Figures 2 to 4 Reference to the elements discussed, and therefore for ease of description, the same reference numerals may be used. It should be noted that although Figure 5 The various elements shown in the figure are shown as being separated, but this is only for the convenience of explanation. Therefore, the various elements can be combined as needed, and there may be more than Figure 5 Greater or fewer elements are shown.

[0094] As illustrated, computing system environment 500 may include DID owner 201, which may be considered a first DID user, and DID user 510, which may be considered a second DID user. DID user 510 may own or otherwise control a DID 515, which may be generated in the manner previously described. DID user 510 may also own or otherwise control an identity hub 516, which may function in a manner similar to the previously described identity hub 410. Although not illustrated, DID user 510 may also have access to a DID management module, which may function in a manner similar to the previously described DID management module 320.

[0095] DID owner 201 may have authorization to use DID 515 on behalf of DID user 510 based on a legal relationship that gives DID owner 201 delegation authority. For example, in one embodiment, DID owner 201 may be a parent or other legal guardian of DID user 510 and reside in a legal jurisdiction that gives parents or legal guardians delegation authority to acquire and then use a DID on behalf of a minor child or other legal ward. Thus, in such an embodiment, DID owner 201 is able to acquire DID 515 for DID user 510 and then use DID 515 on behalf of DID user 510. It will be understood that the legal relationship as a parent or other legal guardian gives DID owner 201 delegation authority to use DID 515 on behalf of DID user 510, rather than any active delegation by DID user 510.

[0096] In another embodiment, DID owner 201 may be married to DID owner user 510 or in a marriage-equivalent domestic partnership relationship and reside in a jurisdiction that allows a spouse or domestic partner to use a DID on behalf of his or her spouse or domestic partner. Thus, in such an embodiment, DID owner 201 is able to use DID 515 on behalf of DID user 510. Likewise, the legal relationship of being a spouse or domestic partner gives DID owner 201 delegated authority to use DID 515 on behalf of DID user 510, rather than any active delegation by DID user 510. It should be noted that in addition to parents, guardians, spouses, or domestic partners, there may be any number of additional legal relationships in various legal jurisdictions that give DID owner 201 delegated authority to obtain and / or use DID 515 on behalf of DID user 510. Thus, the embodiments disclosed herein are not limited to any particular legal relationship between DID owner 201 and DID user 510.

[0097] However, in some other embodiments, DID owner 201 and DID user 510 may not be in a legal relationship that gives DID owner 201 delegated authority to acquire and / or use DID 515 on behalf of DID user 510. Therefore, in such embodiments, DID owner 201 and DID user 510 may enter into a legal agreement in which DID user 510 actively delegates DID 515 to DID owner 201 for use on his or her behalf. For example, in a legal jurisdiction in which a marriage or domestic partnership does not automatically give delegation authority to DID owner 201 to use DID 515 on behalf of DID user 510, a married or cohabiting DID owner 201 and DID user 510 may enter into a legal agreement that provides such delegation authority. The legal agreement may be as simple as DID user 510 actively delegating use of DID 515 to DID owner 201 by specifying the terms and limitations of the delegation and how long the delegation should last. In some other embodiments, the DID owner 201 and the DID user 510 may enter into a legal agreement such as a contract.

[0098] In some embodiments, DID owner 201 may be an employee of DID user 510. In such embodiments, the legal agreement may be an employment contract or the like, specifying that DID owner 201 has delegated authority to use DID 515 on behalf of DID user 510, as long as DID owner 201 is employed by DID user 510. It should be noted that DID owner 201 and DID user 510 may enter into any number of legal agreements that provide DID owner 201 with delegated authority to use DID 515 on behalf of DID user 510. Thus, the embodiments disclosed herein are not limited by any type of legal agreement.

[0099] In some embodiments, certain events may occur that may change the delegated permissions discussed previously. In some embodiments, the legal relationship between DID owner 201 and DID user 510 may change, such that DID user 510 gains the ability to consent to or deny delegated use of DID 515. In some other embodiments, the legal agreement between DID owner 201 and DID user 510 may be terminated or may change, such that DID user 510 no longer wishes to delegate use of DID 515 to DID owner 201. Advantageously, embodiments disclosed herein provide a mechanism for transferring delegated permissions from DID owner 201 back to DID user 510 upon the occurrence of various events, as will now be explained.

[0100] like Figure 5 As shown, the computing system environment 500 may include a delegation module 520. In one embodiment, the delegation module 520 may be implemented by a third-party entity, such as a provider of the DID management module 320 and / or the identity hub 410. In some other embodiments, the delegation module 520 may be hosted on a server computer separate from the device 301 owned by the DID owner 201 or any device owned by the DID user 510. In some other embodiments, the delegation module 520 may be part of the DID management module 320 or a part of the DID management module owned by the DID user 510, or may share at least some functions with the DID management module 320 or a DID management module owned by the DID user 510. In some further embodiments, the delegation module 520 may be part of or hosted by one of the identity hubs or the identity hub 516 in the identity hub 410. Therefore, the embodiments disclosed herein are not limited by where the delegation module 520 is implemented or by the entity that implements the delegation module.

[0101] As illustrated, the delegation module 520 may include a legal relationship module or database 530. In operation, the legal relationship module 530 may be configured to store or access legal relationship information 531, 532, and any number of additional information about various legal relationships between the DID owner 201 and the DID user 510 as illustrated by ellipsis 533. For example, in one embodiment, the legal relationship information 531-533 may state that a parent or legal guardian has automatic authority to obtain and use the delegated DID on behalf of his or her child or legal ward until the child or legal ward reaches the age of majority, which age may be defined by the information 531. In another embodiment, the legal relationship information 531-533 may specify that a spouse has authority to use the delegated DID on behalf of his or her spouse. In yet other embodiments, the legal relationship information 531-533 may include specific information about the legal relationship between the DID owner 201 and the DID user 510, such as whether they are a parent and child, the age of the DID user 510, and the marital status of the parties. In some embodiments, the legal relationship module 530 may be updateable so that changes in information (such as changes in the age of majority or changes in marriage laws within a jurisdiction) may be reflected in the legal relationship information 531-533.

[0102] In some embodiments, the delegation module 520 may also include a legal agreement module or database 540. In operation, the legal relationship module 540 may be configured to store or access various legal agreements 541, 542, and any number of additional legal agreements between the DID owner 201 and the DID user 510 as illustrated by the ellipsis 543. By way of example, in one embodiment, the legal agreements 541-543 may be employment contracts between the DID owner 201 and the DID user 510 that grant the DID owner 201 delegated authority to use the DID 515. In another embodiment, the legal agreements 541-543 may be agreements stating that the DID user 510 consents to the delegated use of the DID 515.

[0103] The delegation module 520 may also include an event module 550. In operation, as will be explained in more detail below, the event module 550 may monitor DID owner 201's attempts to use DID 515 to determine whether an event 551, 552, or any number of additional events as illustrated by ellipsis 553, has occurred that has changed the legal relationship (i.e., 531, 532, or 533) or legal agreement (i.e., 541, 542, or 543) between DID owner 201 and DID user 510. For example, in one embodiment, the event 551-553 may be that DID user 510 has reached the age of majority in the relevant jurisdiction and is therefore no longer legally bound to DID owner 201. In another embodiment, the event 551-553 may be that DID user 510 has divorced DID owner 201 or that DID user 510 has died. In still other embodiments, events 551 - 553 may be that DID user 510 has terminated employment with DID owner 201 or DID user 510 has terminated a legal agreement with DID owner 201 .

[0104] If events 551-553 have occurred, then DID owner 201 may no longer have delegation authority to use delegated DID 515 on behalf of DID user 510. In such a case, delegation module 520 may revoke delegation authority so that DID owner 201 can no longer use DID 515 on behalf of DID user 510. However, if events 551-553 have not occurred, delegation module 520 may continue to allow DID owner 201 to use delegated DID 515 on behalf of DID user 510.

[0105] A specific example of using the DID delegation module 520 in the process of event-based DID delegation authority transfer will now be explained. In one specific example, assume that the DID owner 201 is the parent of the DID user 510 and therefore has automatic authority to use the delegated DID 515 on behalf of the DID user 510 within the relevant legal jurisdiction. Figure 5 As shown, DID owner 515 can show an indication of attempting to use delegated DID 515 by presenting delegated DID 515 to delegation module 520. Legal relationship module 530 can determine, for example, based on legal relationship information 531-533 that DID owner 201 is authorized to use delegated DID 515 on behalf of DID user 510 because DID user 510 is under the age of majority in the relevant jurisdiction. Event module 550 can also determine that events 551-553 that would change the legal relationship have not occurred. Therefore, DID owner 201 may be allowed to use DID 515 on behalf of DID user 510.

[0106] The delegation module 520 can provide the delegated DID 515 to the entity 560, which can own or otherwise be associated with the DID 565. The DID owner 201 can use the delegated DID 515 to obtain various types of DID-related data for the DID user 510 from the entity 560, such as DID-related data 566. The DID-related data 566 (and any other DID-related data discussed herein) can be considered "DID-related" because the data is identified by and associated with the DID 515 of the DID user 510. The DID-related data 566 (and any other DID-related data discussed herein) can contain any reasonable type of data, such as video, audio, pictures, document data, member data, etc. Therefore, the embodiments disclosed herein are not limited by the type of DID-related data. For example, assume that the entity 560 is a social media service. In such a case, the DID owner 201 can use the delegated DID 515 to register a social media account for the DID user 510. Social media accounts can be a type of DID-related data. As shown, DID-related data 566 can be stored in identity hub 411 of DID owner 201 and also stored in identity hub 516 of DID user 510. Therefore, both DID owner 201 and DID user 510 can use DID-related social media accounts 566.

[0107] Likewise, the delegation module 520 can provide the delegated DID 515 to the entity 570, which can own or otherwise be associated with the DID 575. The DID owner 201 can use the delegated DID 515 to obtain various types of DID-related data for the DID user 510 from the entity 570, such as the DID-related data 576. For example, assume that the entity 570 is a provider of video clips. In such a case, the DID owner 201 can use the delegated DID 515 to obtain video clips for the DID user 510. Video clips can be a type of DID-related data. As shown, the DID-related data 576 can be stored in the identity hub 411 of the DID owner 201, and also stored in the identity hub 516 of the DID user 510. Therefore, both the DID owner 201 and the DID user 510 can use the DID-related video clips 576.

[0108] Assume that at a later time, DID owner 210 again attempts to use delegated DID 515 on behalf of DID user 510. Assume also that this later time is after DID user 515 has reached the age of majority in the relevant jurisdiction. In such a case, event module 550 may determine that events 551-553 have been sent, i.e., DID user 515 is no longer a minor child of DID owner 201 because he or she has reached the age of majority. Therefore, the legal relationship specified by legal relationship information 531-533 will no longer be valid, and DID owner 201 will no longer have the automatic delegated authority to use DID 515 on behalf of DID user 510.

[0109] Thus, delegation module 520 may automatically revoke the delegation of authority so that DID owner 201 can no longer use DID 515 on behalf of DID user 510. For example, in one embodiment, delegation module 520 may provide command 521 to DID owner 201 that revokes the delegated authority by removing any tokens, signed statements, etc. used by DID owner 201 to indicate that he or she has delegated authority.

[0110] It will be appreciated that if authorization is revoked, DID user 510 may want to regain full control over any DID-related data acquired by DID owner 201 on behalf of DID user 510. Therefore, in one embodiment, command 521 may also cause DID owner 201 to remove DID-related data 566 and 576 (as well as any other DID-related data) from identity hub 411, as illustrated by the dashed lines. In this manner, DID owner 201 may no longer use or access DID-related data associated with DID 515, thereby giving DID user 510 full control over such DID-related data.

[0111] In some embodiments, even after events 551-553 occur, DID user 510 may still wish to continue to allow DID owner 201 to have authorization to use DID 515 on his or her behalf. For example, even though DID user 510 is now an adult, he or she may still want his or her parents to act on his or her behalf. Therefore, DID user 510 can provide notification 511 to delegation module 520, which specifies that DID user 510 is delegating authority to use DID 515 to DID owner 201. Therefore, DID owner 201 is able to use DID 515 on behalf of DID user 515. However, this delegation is not based on a legal relationship or legal agreement, but is based on the explicit delegation of DID user 510.

[0112] In some embodiments, indication 525 may be provided by delegation module 520 to distributed ledger 220. Indication 525 may specify that DID owner 201 no longer has authorization to use DID 515 on behalf of DID user 510. This may provide entities 560 and 570 with notice that DID owner 201 should attempt to continue using DID 515 when authority has been revoked.

[0113] As a second example, assume that DID owner 201 and DID user 510 have previously been married and therefore DID owner 201 has been able to use delegated DID 515 on behalf of DID user 510 in the manner previously described. Also assume that at a later time, DID owner 210 again attempts to use delegated DID 515 on behalf of DID user 510. However, at a later time, assume that DID user 510 has divorced DID owner 201 or has died. In this case, event module 550 can determine that events 551-553 have occurred, which in this example are divorce or death. Therefore, the legal relationship specified by legal relationship information 531-533 will no longer be valid, and DID owner 201 will no longer have automatic authorization to use DID 515 on behalf of DID user 510.

[0114] Thus, the delegation module 520 can automatically revoke the authorization so that the DID owner 201 can no longer use the DID 515 on behalf of the DID user 510 in the manner previously described. In the event of divorce, the DID user 510 can be given full control over any DID-related data, as previously described. In the event of death, control over the DID-related data can be determined by the will of the DID user 510, etc. In either case, the DID owner 201 can no longer use the DID 515 on behalf of the DID user 510 unless the DID user explicitly authorizes in the manner previously described.

[0115] In a third specific example, assume that DID owner 201 and DID user 510 have entered into legal agreements 541-543, such as employment contracts, which give DID owner 201 authorization to use delegated DID 515 on behalf of DID user 510. Thus, when legal agreements 541-543 are valid, DID owner 201 can act on behalf of DID user 510 in the manner previously described. That is, legal agreement module 540 can verify that the legal agreements are still valid, and therefore delegation module 520 can allow delegated use of DID 515.

[0116] However, assume that at a later time, the legal agreement 541-543 is terminated by the DID user 510. In the case of an employment contract, this event may be that the DID user 510 has fired the DID owner 201 or otherwise terminated the employment of the DID owner 201. When the DID owner 201 again attempts to use the delegated DID 515 on behalf of the DID user 510, the event module 550 may determine that events 551-553 have occurred, which in this example is the termination of the legal agreement. As a result, the DID owner 201 will no longer have authorization to use the DID 515 on behalf of the DID user 510. Therefore, the delegation module 520 may automatically revoke the delegation of authority so that the DID owner 201 can no longer use the DID 515 on behalf of the DID user 510 in the manner previously described.

[0117] It should be noted that in some embodiments, such as when the DID user reaches the age of majority, the event module 550 may be able to automatically determine that an event has occurred. In other words, because the event module 550 knows information about the DID user 510, such as his or her age and the legal relationship between the DID owner 201 and the DID user 510, the event module is able to automatically determine that an event has occurred (i.e., the DID user 510 has reached the age of majority).

[0118] In some other embodiments, DID user 510 may notify event module 550 that events 551-553 have occurred, as shown at 512. For example, if DID user 510 terminates legal agreement 541-543 or divorces, he or she may notify event module 550 that such an event has occurred so that the event can be determined when DID owner 201 later attempts to use delegated DID 515 on behalf of DID user 510.

[0119] 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.

[0120] Figure 6 A flow chart of an example method 600 for event-based DID delegated authority transfer is illustrated. The method 600 is related to the previously discussed Figure 1-Figure 5 is described in one or more figures.

[0121] Method 600 includes the following actions: receiving an indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of a second DID user, the first DID user having previously been delegated authority to use the delegated DID by operating one or more of a legal relationship or a legal agreement between the first DID user and the second DID user that provides delegation authority (action 610). For example, as previously described, DID owner 201, who may be the first DID user, may be given delegation authority to use a delegated DID 515 on behalf of DID user 510, who may be the second DID user. Such delegation authority may be based on legal relationships 531-533 or legal agreements 541-543. Delegation module 520 may receive an indication that DID owner 201 is attempting to use a delegated DID 515.

[0122] Method 600 includes the following actions: Determine whether an event has occurred that changes the legal relationship or legal agreement between the first DID user and the second DID user (action 620). For example, as previously described, event module 550 can determine whether events 551-553 that change the legal relationship 531-533 or legal agreement 541-543 have occurred.

[0123] If an event has occurred, method 600 includes the following actions: automatically revoking the delegation of the right to use the delegated DID so that the first DID user can no longer use the delegated DID on behalf of the second DID user (action 630). For example, as previously described, if events 551-553 have occurred, delegation module 520 can automatically revoke the delegation of the right of DID owner 201 to use delegated DID 515 on behalf of DID user 510.

[0124] If the event has not occurred, the method 600 includes the following actions: allowing the first DID user to continue to use the delegated DID on behalf of the second DID user (action 640). For example, as previously described, if events 551-553 have not occurred, the delegation module 520 can continue to allow the DID owner 201 to use the delegated DID 515 on behalf of the DID user 510.

[0125] 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.

[0126] 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 implemented in a decentralized network implementing a distributed ledger, the distributed ledger configured to support one or more decentralized identities (DIDs) for one or more users of the computing system, the computing system comprising: one or more processors; as well as One or more computer-readable hardware storage devices storing instructions executable by the one or more processors to cause the computing system to: receiving an indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of the second DID user, by operating one or more of a legal relationship or a legal agreement between the first DID user and the second DID user that provides delegated authority to use the delegated DID, the first DID user having previously been delegated the authority, wherein the delegated DID is a globally unique identifier, (i) the globally unique identifier is managed independently of any centralized authority, (ii) the globally unique identifier is operable to identify the second DID user to an identity system, and (iii) even though the delegated DID uniquely identifies the second DID user, the globally unique identifier is currently under the control of the first DID user, and wherein the delegated DID is associated with a DID document describing how to allow the use of the delegated DID, wherein the DID document includes authorization information for providing the delegated authority to the first DID user, and wherein the DID document includes personally identifiable information (PII) for the first DID user, wherein the PII includes one or more of name, address, occupation, family member, or age; determining whether an event has occurred that has changed the legal relationship or the legal agreement between the first DID user and the second DID user; If an event has occurred, automatically revoking the delegation of authority to use the delegated DID, and recording an indicator in the distributed ledger, wherein the indicator indicates that the first DID user's delegation authority to use the delegated DID has been revoked, and wherein the first DID user can no longer use the delegated DID on behalf of the second DID user; as well as If no event occurs, the first DID user is allowed to continue to use the delegated DID on behalf of the second DID user.

2. The computing system of claim 1 , wherein the computer executable instructions when executed further cause the computing system to: If an event has occurred, causing the first DID user to return control of all DID-related data associated with the delegated DID to the second DID user.

3. The computing system of claim 1 , wherein the legal relationship is that the first DID user is the parent or other legal guardian of the second DID user, and the event is that the second DID user has reached adulthood or legal guardianship has been terminated, whereby the second DID user has become legally independent of the first DID user.

4. The computing system of claim 1, wherein the legal relationship is that the first DID user is married to the second DID user, and the event is that the second DID user has divorced the first DID user.

5. The computing system of claim 1, wherein the legal relationship is that the first DID user is married to the second DID user, and the event is that the second DID user has died.

6. The computing system of claim 1, wherein the legal agreement is an employment contract stating that the first DID user is an employee of the second DID user, and the event is that the second DID user has terminated employment of the first DID user.

7. The computing system of claim 1, wherein the legal agreement is an agreement stating that the first DID user can act on behalf of the second DID user, and the event is that the second DID user has terminated the agreement.

8. The computing system of claim 1 , wherein determining whether the event has occurred comprises: An input is received from the second DID user notifying that the event has occurred.

9. The computing system of claim 1 , wherein determining whether the event has occurred comprises: It is automatically determined based on the legal relationship that the event has occurred.

10. A method for event-based decentralized identity (DID) delegation authority transfer, the method being implemented in a computing system, the computing system being implemented in a decentralized network implementing a distributed ledger, the distributed ledger being configured to support one or more DIDs for one or more users of the computing system, the method comprising: receiving an indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of the second DID user, by operating one or more of a legal relationship or a legal agreement between the first DID user and the second DID user that provides delegated authority to use the delegated DID, the first DID user having previously been delegated the authority, wherein the delegated DID is a globally unique identifier, (i) the globally unique identifier is managed independently of any centralized authority, and (ii) the globally unique identifier is operable to identify the second DID user to an identity system, and (iii) even if the delegated DID uniquely identifies the second DID user, the globally unique identifier is currently under the control of the first DID user, and wherein the delegated DID is associated with a DID document describing how to allow the use of the delegated DID, wherein the DID document includes authorization information for providing the delegated authority to the first DID user, and wherein the DID document includes personally identifiable information (PII) for the first DID user, wherein the PII includes one or more of name, address, occupation, family member, or age; determining whether an event has occurred that has changed the legal relationship or the legal agreement between the first DID user and the second DID user; If an event has occurred, automatically revoking the delegation of authority to use the delegated DID, and recording an indicator in the distributed ledger, wherein the indicator indicates that the first DID user's delegation authority to use the delegated DID has been revoked, and wherein the first DID user can no longer use the delegated DID on behalf of the second DID user; as well as If no event occurs, the first DID user is allowed to continue to use the delegated DID on behalf of the second DID user.

11. The method according to claim 10, further comprising: If an event has occurred, causing the first DID user to return control of all DID-related data associated with the delegated DID to the second DID user.

12. The method of claim 10, wherein the legal relationship is that the first DID user is the parent or other legal guardian of the second DID user, and the event is that the second DID user has reached adulthood or legal guardianship has been terminated, whereby the second DID user has become legally independent of the first DID user.

13. The method of claim 10, wherein the legal relationship is that the first DID user is married to the second DID user, and the event is that the second DID user has divorced the first DID user.

14. The method of claim 10, wherein the legal relationship is that the first DID user is married to the second DID user, and the event is that the second DID user has died.

15. The method of claim 10, wherein the legal agreement is an employment contract stating that the first DID user is an employee of the second DID user, and the event is that the second DID user has terminated employment of the first DID user.

16. The method of claim 10, wherein the legal agreement is an agreement stating that the first DID user can act on behalf of the second DID user, and the event is that the second DID user has terminated the agreement.

17. The method of claim 10, wherein determining whether the event has occurred comprises one of: receiving an input from the second DID user notifying that the event has occurred, or It is automatically determined based on the legal relationship that the event has occurred.

18. A computer system configured to operate in a decentralized network implementing a distributed ledger, the distributed ledger configured to support one or more decentralized identities (DIDs) for one or more users of the computer system, the computer system comprising: one or more processors; as well as One or more computer-readable hardware storage devices storing instructions executable by the one or more processors to cause the computer system to: receiving an indication that a first DID user is attempting to use a delegated DID associated with a second DID user on behalf of the second DID user, by operating one or more of a legal relationship or a legal agreement between the first DID user and the second DID user that provides delegated authority to use the delegated DID, the first DID user having previously been delegated the authority, wherein the delegated DID is a globally unique identifier, (i) the globally unique identifier is managed independently of any centralized authority, (ii) the globally unique identifier is operable to identify the second DID user to an identity system, and (iii) even though the delegated DID uniquely identifies the second DID user, the globally unique identifier is currently under the control of the first DID user, and wherein the delegated DID is associated with a DID document describing how to allow the use of the delegated DID, wherein the DID document includes authorization information for providing the delegated authority to the first DID user, and wherein the DID document includes personally identifiable information (PII) for the first DID user, wherein the PII includes one or more of name, address, occupation, family member, or age; Determining that the first DID user is associated with an identity hub, wherein the identity hub has multiple instances storing data, and wherein the identity hub is controlled by the first DID user; determining that DID-related data belonging to the second DID user is stored in one or more instances of the identity hub; determining whether an event has occurred that has changed the legal relationship or the legal agreement between the first DID user and the second DID user; If an event has occurred, (i) automatically revoke the delegation of authority to use the delegated DID, wherein the first DID user is no longer able to use the delegated DID on behalf of the second DID user, (ii) issue a command to cause the DID-related data to be removed from the one or more instances of the identity hub, and (iii) record an indicator in the distributed ledger, wherein the indicator indicates that the first DID user's delegation authority to use the delegated DID has been revoked, and wherein the first DID user loses control of the DID-related data; as well as If no event occurs, the first DID user is allowed to continue to use the delegated DID on behalf of the second DID user.

Images