Delegation using pairs of decentralized identifiers

Abstract

Delegating a scope of permissions between a pair of DIDs. First, the computing system determines a relationship between a first DID and a second DID. The first DID and the second DID are a pair of DIDs. Based on the relationship, the computing system delegates a scope of permissions owned by the first DID to the second DID. Specifically, the computing system defines the scope of permissions, and grants the scope of permissions to a public key of the second DID. The delegation of the defined scope of permissions is signed by a private key of the first DID, such that the signature is proof of the delegation. Data pertaining to the delegation is then propagated onto a distributed ledger.

Description

BACKGROUND

[0001] Most of the identity-attesting documents or records currently in use are issued by a centralized organization, such as a government, a school, an employer, or other service center or regulatory body. These organizations typically 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, identity authentication, authorization, roles, and privileges. Centralized identity management systems have been considered secure because they often use professionally maintained hardware and software. Typically, the identity-issuing organization will have terms and requirements for persons registered with the organization. Finally, when a party needs to verify the identity of another party, the verifying party often needs to go through the centralized identity management system to obtain information verifying and / or authenticating the identity of the other party.

[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 a blockchain, provides an opportunity for using a fully decentralized identifier. Distributed ledger technology uses a globally distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in the segment of the distributed ledger cannot be retroactively changed without changing all subsequent segments of the distributed ledger, which provides a fairly secure platform. In such a decentralized environment, the owner of each DID can typically use his / her DID to control the data he / she owns. The DID owner accesses the data stored in the personal memory associated with the DID through a DID management module, which is a mobile application, a personal computer, a browser, etc.

[0003] The subject matter claimed herein is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided only to illustrate one example technology area where some embodiments described in the present disclosure can be practiced. SUMMARY

[0004] The summary is provided to introduce a selection of concepts that are further described in the detailed description. This summary is not intended to identify key 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 described in this disclosure relate to delegating permission scopes between pairs of decentralized identifiers (DIDs). In a decentralized environment, one DID owner can generate and use many different DIDs to communicate with other DID owners. A pair of DIDs is referred to as a pair of DIDs that is used only for communication between two entities. For example, a first DID owner has a first DID, and a second DID owner has a second DID. When the first DID and the second DID are a pair of DIDs, the first DID and the second DID are used only between the first DID owner and the second DID owner. When the first owner communicates with a third DID owner, a third DID is generated and used. Likewise, when the second DID owner wants to communicate with a third DID owner, a fourth DID is generated.

[0006] Because a pair of DIDs is used only between two owners, the relationship between the two owners can often be clearly identified, such as a parent-child relationship, an employer-employee relationship, a customer-service relationship, and the like. When a certain relationship exists, one DID owner can want to delegate a permission scope to the other DID owner. For example, a child can want to delegate a permission scope to his / her parent to allow the parent to act on behalf of the child.

[0007] In a centralized environment, this type of delegation is typically performed manually by executing and presenting a written agreement to the other party, which is both cumbersome and susceptible to fraud. The principles described in this disclosure allow the use of computing systems and cryptography to execute and validate various delegations securely and automatically in a decentralized environment.

[0008] When the first DID owner delegates a permission scope to the second DID owner, the first DID owner is the delegating party, and the second DID owner is the delegated party. The delegation of the permission scope from the delegating party to the delegated party is likely performed by a computing system associated with the delegating party (e.g., a management module (e.g., a wallet application), a user agent, and / or an ID hub of the delegating party). The computing system first determines the relationship between the owners of the pair of DIDs. Based on the relationship, the computing system then delegates the permission scope owned by the delegating DID to the delegated DID. Specifically, the computing system defines the permission scope and grants the defined permission scope to the public key of the second DID. The computing system then generates a signature by the private key of the first DID. The signature proves the delegation of the defined permission scope to the public key of the second DID. The data related to the delegation is then propagated to a distributed ledger.

[0009] In some embodiments, the computing system further maps the plurality of relationships to a plurality of permission scopes. The mapping data is recorded in a storage accessible by the computing system. Based on the mapping data, the computing system determines a permission scope corresponding to a relationship between a pair of DID owners. The mapping of the plurality of relationships to the plurality of permission scopes is based on (1) data recorded in the DID documents, (2) data propagated onto the distributed ledger, and / or (3) user input.

[0010] In some embodiments, the computing system receives user input for generating, updating, or deleting a mapping pair of a particular permission scope and a particular relationship. Based on the user input, the computing system updates the mapping data recorded in the storage. In some cases, in response to the user indication, the computing system also updates the delegation(s) between the pair of DIDs with the particular relationship affected by the user input.

[0011] The plurality of relationships includes, but is not limited to: (1) a child-parent relationship, where the owner of one pair of DIDs is a minor child of the owner of the other pair of DIDs; (2) a spouse relationship, where the owners of the pair of DIDs are spouses; (3) an employee-employer relationship, where the owner of one pair of DIDs is an employee of the owner of the other pair of DIDs; (4) a customer-service relationship, where the owner of one pair of DIDs is a customer of the owner of the other pair of DIDs; or (5) a contractual relationship, where the owners of the pair of DIDs are parties to a contract agreed upon by both.

[0012] Since certain relationships between DID owners can change in various circumstances, in some embodiments, the computing system is caused to automatically update the delegation in response to a change in the relationship. In some cases, in response to a request from a second DID owner of a second DID for access to a permission scope, the computing system determines whether a particular relationship still exists. Alternatively or additionally, the computing system periodically checks whether a particular relationship between a pair of DIDs still exists. In some cases, in response to user input that changes information related to a first DID or information related to a second DID, the computing system determines whether a particular relationship still exists. In response to determining that a particular relationship no longer exists, the computing system revokes the delegation to the corresponding permission scope and propagates data related to the permission revocation to the distributed ledger.

[0013] In some embodiments, defining the scope of permissions includes defining one or more restrictions, and propagating the portion of data related to the delegation includes propagating the one or more restrictions to the distributed ledger. The one or more restrictions include, but are not limited to: (1) an expiration time of the delegation, (2) a predetermined number of times the delegatee is allowed to access the portion of data or service, or (3) a restriction limiting access to the portion of data, such as (i) read permission, (ii) write permission, (iii) delete permission, or (iv) delegation permission. In some embodiments, the one or more restrictions include one or more conditions that the delegatee needs to satisfy each time the delegatee requests access to the delegated permission. The one or more conditions include, but are not limited to, (i) requiring the delegatee DID to pay a predetermined amount of cryptocurrency, (ii) requiring the delegatee DID to provide one or more verifiable claims, or (iii) requiring the delegatee DID to provide specific personal data, such as (a) email address, (b) phone number, (c) location, (d) name of the delegatee, (e) IP address, or (f) device identifier.

[0014] In some embodiments, in response to receiving a request to access the scope of permissions from a second DID owner of a second DID, the computing system requests the second DID (i.e., the computing system associated with the second DID, including the management module, the user agent, or the ID hub of the second DID) for proof of the delegation of the scope of permissions. The second DID then generates a proof code and sends the proof code to the computing system. The proof code is configured to prove that the second DID has been delegated to the requested scope of permissions. The computing system then receives and verifies the proof code. Based on the verification result, the computing system grants or denies the request from the second DID.

[0015] In some embodiments, in response to receiving a request to access the scope of permissions from a second DID owner of a second DID, the computing system requests the second DID (i.e., the computing system associated with the second DID, including the management module, the user agent, or the ID hub of the second DID) for proof of the delegation of the scope of permissions. The second DID then generates a proof code and sends the proof code to the computing system. The proof code is configured to prove that the second DID has been delegated to the requested scope of permissions. The computing system then receives and verifies the proof code. Based on the verification result, the computing system grants or denies the request from the second DID.

[0016] Accordingly, the principles described herein allow a user (i.e., a DID owner) to delegate a scope of permissions to one another or to substantially immediately revoke a previous delegation. Once a scope of permissions is delegated, the delegatee can also substantially immediately access the delegated data. Accordingly, it is advantageous for the delegation to be created and executed by the DID owner’s computing system because the traditional requirement for a mediating or centralized entity to record or execute the delegation is eliminated. Moreover, because there is no centralized entity to record all data related to the delegation between the DID owners, and each pairwise DID is only used to communicate with another DID, the privacy of the DID owners is further protected.

[0017] Additional features and advantages will be set forth in the description that follows, and in part will be apparent from the description, or can be learned by practice of the disclosure. The features and advantages of the present application will be realized and attained by the means and combinations BRIEF DESCRIPTION OF DRAWINGS

[0018] To describe the manner in which the above-recited and other advantages and features can be obtained, a brief description of the figures can be helpful. Thereafter, a more detailed description of the subject matter can be set forth in the detailed description section below, after a brief description of the drawings. The subject matter will be described with additional specificity and detail in the following description of the drawings.

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

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

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

[0022] Figure 4 An example decentralized personal memory or identity hub is shown;

[0023] Figure 5 An example environment in which DID owners communicate with one another using pairwise DIDs is shown;

[0024] Figure 6A An example data structure that records relationships of pairwise DIDs is shown;

[0025] Figure 6B An example data structure that records mapping data that maps multiple relationships to multiple scopes of permissions is shown;

[0026] Figure 6C An example user interface of a management module that allows a user to manually input or update relationships and permission scopes corresponding to a pair DID is shown;

[0027] Figure 7 An example delegation attestation for delegating a permission scope from Alice to Bob is shown;

[0028] Figure 8 An example communication pattern that occurs when a delegatee requests access to a delegated permission scope is shown;

[0029] Figure 9 A flowchart of an example method for delegating a permission scope between two pair DIDs is shown;

[0030] Figure 10 A flowchart of an example method for determining a relationship between DID owners of a pair DID is shown; and

[0031] Figure 11 A flowchart of an example method for allowing a delegatee to access a delegated permission scope in response to the delegatee attesting that the delegation is valid is shown. DETAILED DESCRIPTION

[0032] Embodiments described in this disclosure relate to delegating permission scopes between pair decentralized identifiers (DIDs). Because the principles described herein are performed in the context of a computing system, reference will be made to a computing system 100 as shown in FIG. 1. Figure 1 Some introductory discussion of computing systems is described. Then, the specification will return to the principles of DID platforms with reference to the other figures.

[0033] Computing systems are now increasingly taking a wide variety of forms. Computing systems may be hand-held, laptop computers, desktop computers, mainframes, distributed computing systems, data centers, or even devices that have not conventionally been considered a computing system such as wearables, for example. In this description and in the claims, the term "computing system" is defined broadly to include any device or system (or combination thereof) that includes at least one physical and tangible processor, and physical and tangible memory capable of having computer-executable instructions stored thereon for execution by the processor. The processor can be implemented as a single-chip processor or chips having multiple cores, as or multiple cores of a multi-core processor. The memory can be implemented using any memory technology, whether now known or developed in the future, and is considered a computer-readable medium. The computing system can include, or be implemented within, a mobile device such as a mobile phone, a wearable device, a tablet computer, a laptop computer, a desktop computer, a personal digital assistant (PDA), a netbook, a smart speaker, a smart television, a server, a distributed computing system, or any other device that includes at least one physical and tangible processor and physical and tangible memory capable of having computer-executable instructions stored thereon for execution by the processor.

[0034] As Figure 1As shown, in its most basic configuration, computing system 100 typically includes at least one hardware processing unit 102 and memory 104. The processing unit 102 includes a general purpose processor and also includes an application specific integrated circuit (ASIC) or any other special purpose circuit. The memory 104 is a physical system memory, which is volatile, non-volatile, or some combination of the two. The term "memory" in this disclosure also is used to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and / or storage capability is also distributed.

[0035] Computing system 100 also has further structure on it, generally referred to as "executable components." For example, memory 104 of computing system 100 is shown to include executable component 106. The term "executable component" is a name for structure that those of ordinary skill in the computing arts well understand to be software, hardware, or a combination thereof. For example, when implemented in software, those of ordinary skill in the art will understand that the structure of the executable component includes software objects, threads of execution, procedures, functions, etc. that execute on the computing system, whether such an executable component exists in the heap of the computing system, or whether the executable component exists on a computer-readable storage medium.

[0036] In this case, those of ordinary skill in the art will recognize the structure of the executable component exists on a computer-readable medium, such that when it is illustrated by one or more processors of the computing system (e.g., by a processor thread), the computing system is caused to perform a function. This structure is directly readable by the processor on the computer (as is the case when the executable component is binary). Alternatively, the structure is structured to be illustratable and / or compiled (whether in a single stage or in multiple stages) in order to generate such a binary that is directly illustratable by the processor. This understanding of example structure of an executable component is well within the understanding of one of ordinary skill in the computing arts when using the term "executable component."

[0037] The term "executable component" is also well understood by those of ordinary skill in the computing arts to include structures such as hard-coded or hard-wired logic gates, which are implemented only in hardware or almost entirely in hardware, e.g., within an FPGA, an ASIC, or any other special-purpose circuit. Thus, the term "executable component" is a term of art to those of ordinary skill in the computing arts for structures that are well understood in the computing arts, whether implemented in software, hardware, or a combination. In this specification, the terms "component," "agent," "manager," "service," "engine," "module," "virtual machine," or similar can also be used. As used in this specification and claims, these terms are intended to be synonymous with the term "executable component," and are also thus of structures that are well understood by those of ordinary skill in the computing arts.

[0038] In the description below, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions constituting an executable component. For example, such computer-executable instructions are embodied on one or more computer-readable media that form part of a computer program product. An example of such an operation involves the manipulation of data. If such acts are implemented solely or almost solely in hardware, e.g., within an FPGA or ASIC, then the computer-executable instructions are hard-coded or hard-wired logic gates. The computer-executable instructions (and data) are stored in the memory 104 of the computing system 100. The computing system 100 also contains communication channels 108 that allow the computing system 100 to communicate with other computing systems over, for example, the network 110.

[0039] While not all computing systems require a user interface, in some embodiments, the computing system 100 includes a user interface system 112 for interaction with a user. The user interface system 112 includes output mechanisms 112A as well as input mechanisms 112B. The principles described herein are not limited to precise output mechanisms 112A or input mechanisms 112B as these will depend on the nature of the device. However, output mechanisms 112A can include, for example, speakers, displays, tactile outputs, holograms, and so on. Examples of input mechanisms 112B can include, for example, microphones, touchscreens, holograms, cameras, keyboards, mouse or other pointer input, any type of sensor, and so on.

[0040] The embodiments described herein include or utilize special-purpose or general-purpose computing systems that include computer hardware, such as one or more processors and system memory, as discussed in greater detail below. Embodiments described in this disclosure 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 is accessible by a general -purpose or special -purpose computing system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the application can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.

[0041] 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 and tangible storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general -purpose or special -purpose computing system.

[0042] A "network" is defined as one or more data links that enable the transport of electronic data between computing systems and / or modules and / or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computing system, the computing system properly views the connection as a transmission medium. Transmission media can include a network and / or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general -purpose or special -purpose computing system. Combinations of the above should also be included within the scope of computer-readable media.

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

[0044] Computer-executable instructions include, for example, instructions and data which, when executed at a processor, cause a general purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions. Alternatively, or in addition, the computer-executable instructions configure the computing system to perform a certain function or group of functions. Computer-executable instructions can be, for example, binaries or even instructions that are interpreted or compiled, such as assembly language instructions, for execution at a processor, or source code.

[0045] 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 described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0046] Those skilled in the art will appreciate that the application is practiced in a network computing environment with many types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, datacenters, wearables (such as glasses), and the like. In some cases, the application can also be practiced in distributed system environments where local and remote computing systems both perform tasks. In a distributed system environment, program modules are located in both local and remote memory storage devices.

[0047] Those skilled in the art will also appreciate that the application is practiced in a cloud computing environment. A cloud computing environment is a distributed one, although this is not required. When the cloud computing environment is distributed, cloud computing environment components are distributed across international jurisdictions and / or have components owned in common by multiple organizations. In this description 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, applications, and services). The definition of “cloud computing” is not limited to any of the numerous advantages that can be obtained from properly deploying the described models in this manner.

[0048] The remaining figures discuss various computing systems that correspond to the previously described computing system 100. The computing systems of the remaining figures include various components or functional blocks that implement various embodiments of the present disclosure, as will be explained. The various components or functional blocks are implemented on a local computing system or on a distributed computing system that includes elements that reside in the cloud or implement aspects of cloud computing. The various components or functional blocks are implemented as software, hardware, or a combination of software and hardware. The computing systems in the remaining figures include more or fewer components than shown in the figures, and certain components are combined in cases where the situation calls for it. Although not necessarily shown, the various components of the computing systems access and / or utilize processors and memory, such as the processor 102 and the memory 104, as needed to perform their various functions.

[0049] No discussion will be presented regarding Figure 2 Some introductory discussion will be presented regarding decentralized identifiers (DIDs) and the environment in which they are created and reside. As Figure 2 shown, a DID owner 201 owns or controls a DID 205 that represents the identity of the DID owner 201. The DID owner 201 registers the DID using a creation and registration service, which will be explained in more detail below.

[0050] The DID owner 201 is any entity that can benefit from a DID. For example, the DID owner 201 is a human or an organization of humans. Such organizations can include a company, a department, a government, an agency, or any other organization or group of organizations. Each person can own a DID, and each person’s organization can likewise own a DID.

[0051] Alternatively, the DID owner 201 is a machine, system, or device, or a collection of machines, devices, and / or systems. In other embodiments, the DID owner 201 is a sub-portion of a machine, system, or device. For example, a device can be a printed circuit board, where the sub-portions of the circuit board are individual components of the circuit board. In such embodiments, the machine or device has a DID and each sub-portion also has a DID. The DID owner can also be a software component, such as the executable component 106 described above in connection with Figure 1 The executable component 106 described above in connection with

[0052] Accordingly, the DID owner 201 is any reasonable entity, human or non-human, that is capable of creating a DID 205 or at least has a DID 205 created for it and associated with it. Although the DID owner 201 is shown as having a single DID 205, this is not necessarily the case, as there are any number of DIDs associated with the DID owner 201 as the situation calls for it.

[0053] As described above, DID owner 201 creates and registers DID 205. DID 205 is any identifier associated with DID owner 201. Preferably, this identifier is unique to DID owner 201, at least within the scope of where the DID is intended to be used. As an example, the identifier is locally unique, and for an identity system intended to operate globally, it may be more desirable to be globally unique. In some embodiments, DID 205 is a Uniform Resource Identifier (URI) (e.g., a Uniform Resource Locator (URL)) or other pointer to a mechanism that associates DID owner 201 with trusted interactions with DID owner 201.

[0054] DID 205 is "decentralized" because it does not require a centralized third-party management system to generate, manage, or use it. Therefore, DID 205 remains under the control of DID owner 201. This differs from traditional centralized IDs based on trust in a centralized authority, which remains under the control of a corporate directory service, certificate authority, domain name registry, or other centralized authority (collectively referred to in this disclosure as "centralized authority"). Therefore, DID 205 is any identifier under the control of DID owner 201 and independent of any centralized authority.

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

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

[0057] As will be described in more detail below, private key 206 and public key 207 are generated on a device controlled by DID owner 201. Private key 206 and public key 207 should not be generated on a server controlled by any centralized authority, as this would result in private key 206 and public key 207 never being fully under the control of DID owner 201. Although Figure 2While this specification describes private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms can be used as appropriate.

[0058] Figure 2 A DID document 210 associated with the DID 205 is also shown. As will be explained in greater detail below, the DID document 210 is generated when the DID 205 is created. In its simplest form, the DID document 210 describes how to use the DID 205. Thus, the DID document 210 includes a reference to the DID 205, which is the DID that is described by the DID document 210. In some embodiments, the DID document 210 is implemented according to methods specific to the distributed ledger 220 that will be used to store a representation of the DID 205, as will be explained in greater detail below. Thus, the DID document 210 has different methods depending on the specific distributed ledger.

[0059] The DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by the DID owner 201. The public key 207 is used by third party entities to which the DID owner 201 grants permission to access information and data owned by the DID owner 201. The public key 207 can also be used to verify that the DID owner 201 is being used, that is, to verify that the DID owner 201 owns or controls the DID 205.

[0060] The DID document 210 also includes authentication information 211. The authentication information 211 specifies one or more mechanisms by which the DID owner 201 can prove that the DID owner 201 owns the DID 205. In other words, the mechanisms of the authentication information 211 show proof of a binding between the DID 205 (and thus its DID owner 201) and the DID document 210. In one embodiment, the authentication information 211 specifies that the public key 207 is used for a signing operation to prove ownership of the DID 205. Alternatively, or additionally, the authentication information 211 specifies that the public key 207 is used for a biometric operation to prove ownership of the DID 205. Thus, the authentication information 211 includes any number of mechanisms by which the DID owner 201 can prove that the DID owner 201 owns the DID 205.

[0061] The DID document 210 also includes authorization information 212. The authorization information 212 allows the DID owner 201 to authorize third party entities the right to modify the DID document 210 or certain portions of the document without giving the third party the right to prove ownership of the DID 205. For example, the authorization information 212 allows a 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 allows a third party to limit the use of the DID 205 by the DID owner 201 to a specified time period. This is useful when the DID owner 201 is a minor child and the third party is the parent or guardian of the child. The authorization information 212 allows the parent or guardian to limit the use of the DID 201 until the child is no longer a minor.

[0062] The authorization information 212 also specifies one or more mechanisms that the third party will need to follow to prove that it is authorized to modify the DID document 210. In some embodiments, the mechanisms are similar to those discussed previously in connection with the authentication information 211.

[0063] The DID document 210 also includes one or more service endpoints 213. The service endpoints include network addresses of services that operate on behalf of the DID owner 201. Examples of particular services include a discovery service, a social network, a file storage service such as an identity server or hub, and a verifiable claims repository service. Thus, the service endpoints 213 serve as pointers to services that operate on behalf of the DID owner 201. These pointers are used by the DID owner 201 or a third party entity to access the services that operate on behalf of the DID owner 201. Particular instances of the service endpoints 213 are explained in more detail below.

[0064] The DID document 210 also includes identity information 214. The identity information 214 includes personal identity information such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Thus, the identity information 214 listed in the DID document 210 represents different roles of the DID owner 201 for different purposes. For example, the role is pseudonymous, e.g., for the DID owner 201, a pen name is included in the DID document when he or she is identified as the author of a post on a blog; the role is fully anonymous, e.g., the DID owner 201 only wants to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years of age, etc.) but not his or her name in the DID document; and the role is specific to the DID owner 201 as an individual, e.g., the DID owner 201 includes information that identifies him or her as a volunteer for a particular charitable organization, an employee of a particular company, a recipient of a particular award, etc.

[0065] The DID document 210 also includes credential information 215, which is also referred to as attestation in this disclosure. The credential information 215 is any information associated with the background of the DID owner 201. For example, the credential information 215 is, but is not limited to, qualifications, achievements, government IDs, government rights such as a passport or driver's license, digital asset providers or bank accounts, university degrees or other education history, employment status and history, or any other information about the background of the DID owner 201.

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

[0067] Figure 2 A distributed ledger or blockchain 220 is also shown. The distributed ledger 220 is any decentralized distributed network of various computing systems that communicate with each other. For example, the distributed ledger 220 includes 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 ellipses 260. The ledger or blockchain 220 operates according to any known standard or method of a distributed ledger. Examples of conventional distributed ledgers corresponding to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

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

[0069] As already mentioned, the representation of the DID 205 is stored on each of the distributed computing systems of the distributed ledger or blockchain 220. For example, in Figure 2 The DID hash 231, the DID hash 241, the DID hash 251, ideally, are identical copies of the same DID. The DID hash 231, the DID hash 241, and the DID hash 251 then point to the location of the DID document 210. The distributed ledger or blockchain 220 also stores many other representations of other DIDs as shown by references 232, 233, 234, 242, 243, 244, 252, 253, and 254.

[0070] In one embodiment, when the DID user 201 creates the DID 205 and the associated DID document 210, the DID hash 231, the DID hash 241, and the DID hash 251 are written to the distributed ledger or blockchain 220. The distributed ledger or blockchain 220 thus records that the DID 205 now exists. Since the distributed ledger or blockchain 220 is decentralized, the DID 205 is not under the control of any entity other than the DID owner 201. The DID hash 231, the DID hash 241, the DID hash 251 include, in addition to the pointer to the DID document 210, a record or timestamp specifying when the DID 205 was created. When modifications are made to the DID document 210 later, this is also recorded in the DID hash 231, the DID hash 241, the DID hash 251. The DID hash 231, the DID hash 241, and the DID hash 252 also include the public key 207 so as to cryptographically bind the DID 205 to the DID document 210.

[0071] Reference has been made to Figure 2 DIDs and how they generally operate, particular embodiments of DIDs will now be described. Turning to Figure 3 The environment 300 for performing various DID lifecycle management operations and services will now be described. It should be understood that, for ease of illustration, Figure 3 The environment of Figure 2 refers to elements from

[0072] As Figure 3 shown, the environment 300 includes various devices and computing systems that are owned or controlled by the DID owner 201. These include a user device 301. In some cases, the user device 301 is a mobile device, such as a smartphone, a laptop computer, or any device with computing capabilities, such as a car or an appliance. The device 301 includes a web browser 302 running on the device and an operating system 303 running the device. More generally, the dashed line 304 indicates that all of these devices are owned or controlled by the DID owner 201.

[0073] The environment 300 also includes a DID lifecycle management module 320. At times, the DID lifecycle management module 320 is also referred to as a wallet or agent. It should be noted that, in operation, the DID lifecycle management module 320 resides on and is executed by one or more of the user device 301, the web browser 302, and the operating system 303, as indicated by the lines 301a, 302a, and 303a. Thus, for ease of illustration, the DID lifecycle management module 320 is shown as being separate.

[0074] As Figure 3As shown, the DID lifecycle management module 320 includes a DID creation module 330. The DID owner 201 uses the DID creation module 330 to create the DID 205 or any number of additional DIDs, such as DID 331. In embodiments, the DID creation module includes or otherwise has access to user interface (UI) elements 335 used to guide the DID owner 201 in creating the DID 205. The DID creation module 330 has one or more drivers configured to work with a particular distributed ledger, such as the distributed ledger 220, so that the DID 205 is compliant with the underlying methods of that distributed ledger.

[0075] A specific embodiment will now be described. For example, the UI 335 prompts the user to enter a user name or some other human-identifiable name. This name is used as the display name for the DID 205 that will be generated. As described above, the DID 205 is a long string of random numbers and letters, so it is advantageous to have a human-identifiable name for the display name. The DID creation module 330 then generates the DID 205. In embodiments with the UI 335, the DID 205 is displayed in a list of identities and is associated with the human-identifiable name.

[0076] The DID creation module also includes a key generation module 350. The key generation module generates the private key 206 and public key 207 pair described previously. The DID creation module 330 uses the DID 205 and the private and public key pair to generate the DID document 210 thereafter.

[0077] In operation, the DID creation module 330 accesses the registrar 310 of the particular distributed ledger configured to record transactions related to the DID 205. The DID creation module 330 uses the registrar 310 to record the DID hash 231, the DID hash 241, and the DID hash 251 in the distributed ledger in the manner described previously and to store the DID document 210 in the manner described previously. This process uses the public key 207 in the hash generation.

[0078] In some embodiments, the DID lifecycle management module 320 includes an ownership module 340. The ownership module 340 provides a mechanism to ensure that the DID owner 201 knows that the DID owner 201 alone controls the DID 205. In this way, the provider of the DID lifecycle management module 320 is able to ensure that the provider does not control the DID 205, but only provides the management service.

[0079] As previously described, the key generation module 350 generates a private key 206 and public key 207 pair, and then records the public key 207 in the DID document 210. Thus, all devices associated with the DID owner 201, as well as all third parties wishing to provide services to the DID owner 201, use the public key 207. Thus, when the DID owner 201 wishes to associate a new device with the DID 205, the DID owner 201 executes the DID creation module 330 on the new device. The DID creation module 330 then uses the registrar 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 an updated transaction on the distributed ledger 220 as previously described.

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

[0081] In those embodiments where the additional public keys 208 and 209 are associated with different devices, the additional public keys 208 and 209 are recorded in the DID document 210 as being associated with those devices. This is shown in Figure 3 It will be appreciated that, in addition to the information shown in Figure 3 the DID document 210 includes the information previously described in connection with Figure 2 If the DID document 210 exists prior to the generation of the device specific public keys, the creation module 330 will update the DID document 210 through the registrar 310, which will be reflected in an updated transaction on the distributed ledger 220.

[0082] In some embodiments, the DID owner 201 can keep the association of a device with a public key, or even with the DID 205, secret. Thus, the DID creation module 330 causes such data to be shown in the DID document 210 in secret.

[0083] As described so far, the DID 205 has been associated with all devices under the control of the DID owner 201, even if these devices have their own public keys. However, in some embodiments, it is useful for each device to have their own DID for each device or a certain subset of devices under the control of the DID owner 201. Thus, in some embodiments, the DID creation module 330 generates an additional DID for each device, such as DID 331. The creation module will then generate a private key and public key pair and a DID document for each of the devices and record them on the distributed ledger 220 in the manner previously described. Such embodiments are advantageous for devices that change ownership, as it is possible to associate a particular device DID to a new owner of the device by granting new owner authorization rights in the DID document and revoking such rights from the old owner.

[0084] As already mentioned, in order to ensure that the private key is entirely under the control of the DID owner 201, the private key is created on a user device 301, browser 302, or operating system 303 owned or controlled by the DID owner 201 executing the DID management module 320. In this way, the likelihood of a third party, especially the provider of the DID life cycle management module 320, gaining control of the private key 206 is small. However, the device storing the private key 206 can be lost by the DID owner 201, which results in the DID owner 201 losing access to the DID 205. Thus, in some embodiments, the UI 335 includes an option 305 to allow the DID owner 201 to export the private key 206 to a secure database outside of the control of the DID owner 201. In some embodiments, the private key 206 is stored as a QR code scanned by the DID owner 201.

[0085] In other embodiments, the DID life cycle management module 320 includes a recovery module 360 for recovering a lost private key 206. In operation, the recovery module 360 allows the DID owner 201 to select one or more recovery mechanisms 365 at the time of creation of the DID 205 that are later used to recover a lost private key. In those embodiments with a UI 335, the UI 335 allows the DID owner 201 to provide the required information that the one or more recovery mechanisms 365 will need when implementing the recovery mechanism. The recovery module then runs on any device associated with the DID 205.

[0086] The DID lifecycle management module 320 also includes a revocation module 370 that is used to revoke or sever a device from a DID 205. In operation, the revocation module uses the UI element 335 that allows the DID owner 201 to indicate that it is desired to remove a device from association with the DID 205. In one embodiment, the revocation module accesses the DID document 210 and causes all references to the device to be removed from the DID document. Alternatively, the public key for the device is removed. This change in the DID document 210 is reflected as an updated transaction on the distributed ledger 220 as previously described.

[0087] Figure 4 Embodiments of an environment 400 are shown in which a DID such as the DID 205 is used. In particular, the environment 400 will be used to describe the use of a DID 205 in relation to one or more decentralized personal storage or identity hubs. An identity hub is a store of attributes, including keys and metadata under the control of the DID holder. It should be noted that, Figure 4 including the first regarding Figure 2 or Figure 3 Reference is made to the elements discussed above, and therefore the same reference numerals are used to facilitate explanation.

[0088] In one embodiment, the identity hubs 410 are multiple instances of the same identity hub. This is indicated by the line 410A. Thus, the various identity hubs 410 include at least some of the same data and services. Thus, if any change is made to one of the identity hubs 410, the change is reflected in the remaining identity hubs. For example, the first identity hub 411 and the second identity hub 412 are implemented in cloud storage, and thus are able to hold a large amount of data. Thus, a complete set of data is stored in these identity hubs. However, the identity hubs 412 and 413 have less memory space. Thus, a descriptor of the data stored in the first and second identity hubs is included in these identity hubs. Alternatively, a record of the changes made to the data in the other identity hubs is also included. Thus, a change in one of the identity hubs 410 is either completely replicated in the other identity hubs, or at least one record or descriptor of that data is recorded in the other identity hubs.

[0089] Because the identity hubs are multiple instances of the same identity hub, only a full description of the first identity hub 411 will be provided as the description also applies to identity hubs 412-415. As shown, the identity hub 411 includes a data store 420. The data store 420 is used to store any type of data associated with the DID owner 201. In one embodiment, the data is a collection 422 of a particular type of data corresponding to a particular protocol. For example, in some cases, the collection 422 is medical record data corresponding to a particular protocol for medical data. In some other cases, the collection 422 is any other type of data.

[0090] In one embodiment, the stored data has different authentication and privacy settings 421 associated with the stored data. For example, a first subset of data has settings 421 that allow the data to be exposed publicly, but does not include any authentication of the DID owner 201. This type of data is used for relatively unimportant data, such as color schemes, etc. A second subset of data has settings 421 that allow the data to be exposed publicly and includes authentication of the DID owner 201. A third subset of data has settings 421 that encrypt the data subset using a private key 206 and public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data will require a party to have access to the public key 207 or some other associated public key in order to decrypt the data. The process also includes authentication of the DID owner 201. A fourth subset of data has settings 421 that restrict this data to a third party subset. This requires the use of a public key associated with the third party subset to decrypt the data. For example, the DID owner 201 has settings 421 that specify only public keys associated with the DID owner's 201 friends decrypt the data.

[0091] In some embodiments, the identity hub 411 has a permissions module 430 that allows the DID owner 201 to set specific authorizations or permissions for third parties, such as third parties 401 and 402, to access the identity hub. For example, the DID owner 201 provides access permissions to all data 420 to his or her spouse. Alternatively, the DID owner 201 allows access to his or her doctor for any medical records. It should be understood that the DID owner 201 allows any number of third parties to access subsets of the data 420. This will be explained in more detail later.

[0092] Identity hub 411 also has a message transmission module 440. In operation, the message transmission module allows the identity hub to receive messages, such as requests for access to the identity hub's data and services from parties such as third parties 401 and 402. In addition, message transmission module 440 allows identity hub 411 to respond to messages from third parties and also to communicate with DID resolver 450. This will be explained in more detail later. Ellipses 416 indicate that identity hub 411 has additional services as the situation allows.

[0093] In one embodiment, DID owner 201 wishes to authenticate new device 301 with identity hub 411 that has already been associated with DID 205 in the manner previously described. Accordingly, DID owner 201 sends a message to identity hub 411 with DID management module 320 associated with new user device 301 asserting that the new user device is associated with DID 205 of DID owner 201.

[0094] However, identity hub 411 initially does not recognize the new device as being owned by DID owner 201. Accordingly, identity hub 411 uses message transmission module 440 to contact DID resolver 450. The message sent to DID resolver 450 includes DID 205.

[0095] DID resolver 450 is a service, application or module configured to search, in operation, distributed ledger 220 for a DID document associated with a DID. Accordingly, in this embodiment, DID resolver 450 searches distributed ledger 220 using DID 205, which results in DID resolver 450 finding DID document 210. DID document 210 is then provided to identity hub 411.

[0096] As previously described, DID document 210 includes public key 208 or 209 associated with new user device 301. To verify that the new user device is owned by DID owner 201, identity hub 411 uses message transmission module 440 to provide a cryptographic challenge to new user device 301. The cryptographic challenge will be structured such that only a device with access to private key 206 can successfully answer the challenge.

[0097] In this embodiment, the challenge is successfully answered because the new user device is owned by DID owner 201 and therefore has access to private key 206. Identity hub 411 then records in permissions 430 that new user device 301 has access to identity hub 411 and the rest of identity hub 210's data and services.

[0098] It should be noted that the process of authenticating the new user device 301 is performed prior to having access to the identity hub 411 without the DID owner 201 having to provide any username, password, etc. to the provider of the identity hub 411 (i.e., the first cloud storage provider). Rather, 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 under the control of the DID owner 201, the provider of the identity hub 411 is not involved and thus does not know any personal information of the transaction or the DID owner 201.

[0099] In another example embodiment, the DID owner 201 provides the DID 205 to a third party entity 401 for the third party to access data or services stored on the identity hub 411. For example, the DID owner 201 is a person attending a scientific conference who wishes to allow a third party 401 (who is also a person) to access his or her research data. Accordingly, the DID owner 201 provides the DID 205 to the third party 401.

[0100] Once the third party 401 has access to the DID 205, he or she accesses the DID resolver 450 to access the DID document 210. As previously described, the DID document 210 includes the endpoint 213 pointing to the address or pointer of the identity hub 411. The third party 401 then uses the address or pointer to access the identity hub 411.

[0101] The third party 401 sends a message to the message transmission module 440 requesting permission to access the research data. The message transmission module 440 then sends a message to the DID owner 201 asking whether the third party 401 should be given access to the research data. Because the DID owner expects to provide access to the data, the DID owner 201 allows the permission to the third party 401 and the permission is recorded in the permissions 430.

[0102] The message transmission module 440 then sends a message to the third party 401 informing him or her that he or she has access to the research data. The identity hub 411 and the third party 401 then communicate directly for the third party to access the data. It should be noted that in many cases, it is the identity hub associated with the third party 401 that communicates with the identity hub 411. However, it is the device of the third party 401 that is doing the communicating.

[0103] Advantageously, the above-described process allows the identity hub 411 and the third party 401 to communicate and share data without the third party having to access the identity hub 411 in a conventional manner. Rather, the DID 205 and the DID document 210 are used to provide the communication in a decentralized manner. This advantageously allows the DID owner to have complete control over the process.

[0104] As briefly discussed above, the identity hub 411 is hosted in a cloud service. The service provider has access to the data stored in the identity hub 411 for each user. In addition, the service provider also has access to certain activities of the DID owner. For example, the DID owner shares his / her data stored in the identity hub 411 with an entity. As another example, the user has multiple DIDs and shares data among the multiple DIDs. Alternatively, the user uses different DID management modules to access the same data. Based on the data sharing activities, the service provider of the identity hub 411 correlates the relationships of different DIDs and discovers that two DIDs are related or belong to the same owner. Thus, the privacy of the user is compromised.

[0105] The principles described in this disclosure will address the potential privacy issues of these DID owners by encrypting the personal data stored in the identity hub 411. The identity hub 411 does not store or access the encryption / decryption keys, so the DID owners can not only have good control of the data from other DID owners or users, but also protect their privacy from the service provider.

[0106] There are many different objects stored in the identity hub 411. A data object is a file, a folder, or any portion of data stored in the identity hub 411. The entire identity hub 411 is encrypted as one object using one encryption / decryption key. Alternatively, different portions of data stored in the identity hub 411 are encrypted with different encryption / decryption keys.

[0107] In another example embodiment, verifiable claims are published and stored in the identity hub 411. For example, a verifiable claim associated with the DID owner 201 is published by a claim publishing entity, and the published verifiable claim is stored in the identity hub 411 associated with the DID owner 201. When another entity needs to verify the credentials of the DID owner, the DID owner 201 sends the verifiable claim to the other entity. For example, the DID owner 201 is a person who holds a driver’s license, and the claim issuing entity is the DMV that has issued the DID owner’s driver’s license. The DMV issues a verifiable claim that verifies that the DID owner 201 holds a valid driver’s license. The DID owner 201 stores the verifiable claim in the identity hub 411. The other entity is a car rental company that requires the DID owner 201 to prove that he / she has a valid driver’s license. The DID owner then sends the verifiable claim stored in the identity hub 411 to the car rental company.

[0108] As described above, when a DID owner uses a DID to communicate with many different entities, the DID owner’s personal identity information can be reconstructed from the communication correlation between the many different entities. To further protect the DID owner’s privacy, a pair of DIDs can be used. A pair of paired DIDs is a pair of DIDs that are used by two DID owners only for communicating with each other. Each DID owner can generate many pairs of paired DIDs, each pair of which is used only for communicating with another entity. Thus, even if the same DID owner is communicating with many different entities, each of the entities does not know about the communications involving the same DID owner using other paired DIDs. Thus, the DID owner’s privacy is further protected.

[0109] Figure 5 An example environment 500 is shown in which Alice 510, Bob 520, and service provider 530 are using paired DIDs to communicate with each other. Each of Alice 510, Bob 520, and service provider 530 corresponds to a DID owner 201 in Figure 2 For example, Alice 510 owns multiple paired DIDs, including DID A 511, DID B 512, and DID C 513. The ellipsis 514 indicates that Alice can own any number of paired DIDs or any number of unpaired DIDs. Similarly, Bob 520 also owns multiple paired DIDs, including DID E 521, DID F 522, and DID G 523. The ellipsis 524 indicates that Bob can own any number of paired DIDs or any number of unpaired DIDs. Service provider 530 also owns multiple paired DIDs, including DID H 531, DID F 532, and DID J 533. The ellipsis 534 indicates that service provider 530 can own any number of paired DIDs or any number of unpaired DIDs. As shown in Figure 5 DID A 511 owned by Alice 510 and DID E 521 owned by Bob 520 are a pair of paired DIDs. Thus, Alice 510 and Bob 520 only use DID A 511 and DID E 521 to communicate with each other, which is represented by arrow 541. Similarly, DID B 512 owned by Alice 510 and DID H 531 owned by service provider 530 are a pair of paired DIDs. Thus, Alice 510 and service provider 530 only use DID B 512 and DID H 531 to communicate with each other, which is represented by arrow 542. Also, similarly, DID F 522 owned by Bob 520 and DID I 532 owned by service provider 530 are a pair of paired DIDs, which are used only for communication between Bob 520 and service provider 530 (represented by arrow 543).

[0110] Since each pair of paired DIDs is used for communication between only two DID owners, in many cases, the relationship between the two DID owners can be explicitly defined. In some embodiments, the relationship between a pair of paired DIDs is recorded in the DID owner’s management module. In some embodiments, such relationship data is stored or recorded in the distributed ledger together with each paired DID (e.g., DID document). Alternatively or additionally, the relationship of each pair of paired DIDs is recorded in a data structure (e.g., table).

[0111] Figure 6A An example data structure 600A that records the relationships of the paired DIDs owned by Alice 510 is illustrated. For example, Alice’s DID A 511 is used for communication with Bob’s DID 521, and the relationship between Alice and Bob is child-parent, i.e., Alice is Bob’s daughter. As another example, Alice’s DID B 512 is used for communication with the service provider 530, and the relationship between Alice 510 and the service provider 530 is employee-employer, i.e., Alice 510 is an employee of the service provider 530. The ellipses 611A, 612A, 533A indicate that there can be any number of pairs of paired DIDs, and their relationships are recorded in the table 600A.

[0112] In some embodiments, based on the relationship between each pair of paired DIDs, Alice’s DID management module, user agent, and / or ID hub is configured to determine the scope of permissions to be delegated from Alice’s paired DID to the corresponding paired DID. In some embodiments, multiple relationships and multiple scopes of permissions are mapped to each other. The mapping data is recorded in the storage of Alice’s DID management module, user agent, and / or ID hub. Figure 6B An example data structure that stores the mapping data 600B is illustrated. As shown, the child-parent relationship 621B is mapped to the delegation scope X 631B; the employee-employer relationship 622B is mapped to the delegation scope Y 532B; and the customer-service relationship 623B is mapped to the delegation scope Z 633B. The ellipses 624B and 634B indicate that there can be any number of pairs of relationships and delegation scopes. Figure 6B

[0113] In some cases, a computing system (e.g., Alice’s management module or wallet application, user agent, or ID hub) is configured to compile the data structure 600A and / or 600B data automatically from the data recorded in the DID document or some other personal information of Alice. Alternatively or additionally, at least a portion of the data structure 600A and / or 600B is generated based on user (e.g., Alice’s) input. Figure 6A and 6B ​A simple example of how relationship data and delegation data can be stored is shown. Various other data structures can also be implemented to achieve similar purposes. For example, in some cases, data structures 600A and 600B can be stored in relation to each other. Alternatively or additionally, data structures 600A and 600B can be stored in the same data structure.

[0114] As noted above, in some cases, the DID owner is allowed to define relationships between pairs of DIDs and the scope of permissions to be delegated. Figure 6C An example user interface 600C of the management module is shown. User interface 600C includes a selection list 610C that allows the user (e.g., DID owner) to select one or more pairs of specific pair-DIDs. User interface 600C also includes a selection list 620C that allows the user to select one or more relationships to apply to the selected pair-DID pairs. User interface 600C also includes a menu 630C that allows the user to select or manually define the scope of permissions to be delegated to the corresponding DID. Once the user presses the confirm button 640C, the user input is recorded in a data structure (e.g., data structures 600A and / or 600B) that the computing system has access to.

[0115] Based on data structures 600A and 600B, the computing system is configured to automatically determine relationships between two DID owners and / or automatically delegate the scope of permissions to pair-DIDs. For example, the computing system accesses relationship data 600A to determine a specific pair-DID (e.g., DID A 511) and its corresponding pair-DID (e.g., DID E 521 owned by Bob 520). Based on the determined relationship (e.g., child-parent relationship), the computing system then accesses delegation data 600B to determine the scope of permissions (e.g., scope X 631) to be delegated to the corresponding pair-DID (e.g., DID E 521 owned by Bob 520). In response to the determination, the computing system delegates the scope of permissions (e.g., scope X 631) to the corresponding pair-DID (e.g., DID E 521 owned by Bob 520).

[0116] Many different mechanisms can be implemented to delegate the scope of permissions from one DID to another DID. Figure 7 and 8Some embodiments that can be implemented in the DID owner management module, user agent, and / or ID hub of the delegating party are shown. In some embodiments, when Alice’s DID 511 delegates a permission scope to Bob’s DID 521, Alice’s computing system (e.g., Alice’s management module, user agent, or ID hub) updates the DID document of Alice’s DID 511 or the DID document of Bob’s DID 521 to record the delegation of the permission scope. In some embodiments, a new DID is generated and the delegation of the permission scope is recorded in the DID document of the new DID. The data related to the delegation is then propagated, in part, onto the distributed ledger.

[0117] Figure 7 An example delegation record 700 for delegating a permission scope from Alice 510 to Bob 520 is shown. The delegation record 700 includes data 710 related to the type of record. Here, the type of record is “delegation” 710. The record 700 also includes data related to the delegating party 720. Here, the delegating party is “Alice’s DID” 720. The record 700 also includes data related to the “granted key.” Here, the granted key is the key associated with Bob’s DID.

[0118] The record 700 also needs to define the granted permission scope. In some embodiments, the definition of the permission scope includes one or more restrictions. As Figure 7 shown, the record 700 includes data 740 related to one or more restrictions. The one or more restrictions include, but are not limited to: (1) an expiration time of the delegation, (2) a predetermined number of times that the delegated party is allowed to access a portion of the data or service, or (3) a restriction that limits access to a portion of the data, such as (i) read permissions, (ii) write permissions, (iii) delete permissions, or (iv) delegation permissions. In some embodiments, the one or more restrictions include one or more conditions that the delegated party needs to satisfy each time the delegated party requests access to the delegated permissions. The one or more conditions include, but are not limited to, (i) requiring the delegated party DID to pay a predetermined amount of cryptocurrency, (ii) requiring the delegated party DID to provide one or more verifiable claims, or (iii) requiring the delegated party DID to provide specific personal data, such as (a) an email address, (b) a phone number, (c) a location, (d) the name of the delegated party, (e) an IP address, or (f) a device identifier. As Figure 7 shown, the one or more restrictions 740 indicate that Bob’s DID is restricted to only reading a portion of Alice’s personal data (i.e., Bob’s DID cannot modify Alice’s personal data).

[0119] Finally, the delegation data 710-740 is signed by a private key 754 associated with Alice's DID. The signature 750 includes a type of signature 751, a time of creation of the signature 752, a creator 753, and a signature value 754. Here, the type of signature is a Rsa signature, the creator is Alice's DID 753, and the signature 754 is generated by a private key associated with Alice's DID 753. In some embodiments, the delegation attestation is stored with the DID document of Alice's DID and / or the DID document of Bob's DID. In some embodiments, a new DID is produced and the delegation data is associated with the DID document of the new DID and stored. At least the portion of the data related to the delegation attestation is propagated onto the distributed ledger. In some embodiments, the full delegation attestation is propagated onto the distributed ledger. Alternatively, a transformed record (e.g., a hash, a URL, or an identifier of the delegation attestation) is propagated onto the distributed ledger.

[0120] Figure 8 An example communication pattern 800 is further illustrated when a delegatee (e.g., Bob 810) requests access to the delegated scope of permissions (e.g., Alice's data). As shown, Bob's device (e.g., Bob's management module, user agent, and / or ID hub) first requests access to Alice's data, which is represented by arrow 831. The request is sent to Alice's device 840 (e.g., Alice's management module, user agent, and / or ID hub). Upon receiving the request, Alice's device 840 then requests Bob's device 820 to attest that Bob 810 is delegated to access the scope of permissions of the requested Alice's data, which is represented by arrow 832. Bob's device 820 in turn generates attestation data, which is represented by arrow 833. The attestation data includes at least a signature (e.g., the signature 750) signed by Alice's private key. The attestation data is then packaged in a response and sent to Alice's device 840, as represented by arrow 834. Figure 8 Figure 7

[0121] ​​Upon receiving the attestation data, Alice's device 840 verifies the response using its key and / or the portion of the data related to the attestation delegation propagated onto the distributed ledger 860, as represented by arrow 835. For example, when a signature signed by Alice's device receives a private key, Alice's device 840 attempts to decrypt the signature using the corresponding public key. The decryption result (and / or a transformed decryption result) is then compared to the data propagated onto the distributed ledger 860 to determine whether the attestation data is valid. Alice's device 840 will also verify whether the requested scope of permission falls within one or more limitations and / or satisfies one or more conditions when the scope of permission includes one or more limitations or conditions. For example, if a condition requires Bob to pay a predetermined amount of cryptocurrency, the attestation data is required to show proof of payment. As another example, if a condition requires Bob to provide his email address, the attestation data needs to include Bob's email address. If the attestation data is valid, Alice's device 840 approves Bob's request, otherwise Alice's device 840 denies Bob's request, as represented by arrow 835.

[0122] The following discussion now will focus on a number of methods and method actions that can be performed. Although the method actions can be discussed in a certain order or illustrated as occurring in a certain order in a flowchart, no particular order is required, unless specifically stated, or where context would render order critical. Method actions can be performed in any order, magnitudes, or context, unless otherwise specified.

[0123] Figure 9 A flowchart illustrating an example method 900 for delegating a scope of permission between two pair-wised DIDs is shown. The DID that delegates the scope of permission is referred to as the delegating DID or simply the delegator, and the DID that receives the delegation is referred to as the delegated DID or simply the delegatee. The method 900 is performed by a computing system associated with the delegating DID (e.g., a management module, a user agent, and / or an ID hub). The method 900 includes determining a relationship of an owner of the pair-wised DID (910). Based on the determined relationship, the scope of permission is delegated from the delegator to the delegatee (920).

[0124] In some embodiments, the delegation includes a definition of a permission scope (921). For example, in some cases, the definition of the permission scope includes one or more restrictions (922) related to the permission scope. The one or more restrictions include, but are not limited to: (1) an expiration time of the delegation, (2) a predetermined number of times the delegatee is allowed to access a portion of data or service, or (3) a restriction limiting access to a portion of data, such as (i) read permission, (ii) write permission, (iii) delete permission, or (iv) delegate permission. In some embodiments, the one or more restrictions include one or more conditions that the delegatee needs to satisfy each time the delegatee requests access to the delegated permission. The one or more conditions include, but are not limited to, (i) requiring the delegatee DID to pay a predetermined amount of cryptocurrency, (ii) requiring the delegatee DID to provide one or more verifiable claims, or (iii) requiring the delegatee DID to provide specific personal data, such as (a) email address, (b) phone number, (c) location, (d) name of the delegatee, (e) IP address, or (f) device identifier.

[0125] In some embodiments, the delegation includes a delegation of a key permission scope to the delegatee (923). The delegation further includes generating a signature by the private key of the delegator (924) and recording data related to the delegation in a DID document (e.g., the DID document of the delegator, the DID document of the delegatee, and / or the file of the DID of the DID new) (925). Finally, at least a portion of the data related to the delegation is propagated onto a distributed ledger (930). In some embodiments, the complete delegation proof is propagated onto the distributed ledger. In some embodiments, a transformed delegation proof such as a hash, a URL of the DID document, or an identifier of the delegation proof is propagated onto the distributed ledger.

[0126] Figure 10 Further shown is a flowchart of an example method 1000 for determining a relationship between DID owners of a pair of paired DIDs, which corresponds to step 910 of Figure 9 . The method 1000 includes accessing mapping data that maps a plurality of relationships to a plurality of permission scopes for delegations (1010). Examples of the mapping data are explained in Figure 6A and 6B above.

[0127] In some embodiments, the mapping data is manually input by the user (1030, 1040). In some embodiments, the mapping data is generated based on the principal’s personal data, data recorded in the DID document, and / or data propagated onto the distributed ledger. In some embodiments, the user (e.g., the DID owner) is also allowed to manually update the automatically generated mapping data. For example, in some cases, the user is allowed to not only update the mapping data (1030), but also update the relationship between the owners of the pair of DIDs (1040). Based on the mapping data (1010) and / or the user’s input (1030, 1040), the computing system then determines the specific scope of permissions corresponding to the specific relationship (1020).

[0128] Upon receiving the delegation of the scope of permissions by the principal, the delegate will be allowed to access the delegated scope of permissions. Figure 11 A flowchart illustrating an example method 1100 for allowing a delegate to access a delegated scope of permissions in response to a proof of delegation being valid is shown. The method 1100 can also be implemented in a computing system associated with the DID of the principal. The method 1100 includes receiving a request for access to a scope of permissions from a delegate DID (1110). In response to the request, the computing system requests the delegate to provide a proof of delegation (1120). Upon receiving the proof code from the delegate (1130), the computing system verifies the proof code (1140).

[0129] In some embodiments, when the proof code includes a signature signed by the principal’s private key, the verification of the proof code includes decrypting the signature by the principal’s public key (1141). In some embodiments, the verification of the proof code also includes retrieving data related to the delegation in the distributed ledger (1142). The computing system then analyzes the decrypted signature and the delegation data retrieved from the distributed ledger to determine whether the proof data is valid (1143). The verification of the proof code also includes verifying whether the requested scope of permissions falls within the delegated scope (1144).

[0130] For example, when the delegated scope of permissions includes one or more restrictions, the computing system verifies that the requested scope of permissions does not fall within the restricted scope. In some embodiments, when the restriction includes one or more conditions for accessing the scope of permissions, the verification of the proof code also includes verifying that the one or more conditions are satisfied (1145). For example, when one condition requires the delegate to pay a predetermined amount of cryptocurrency, the delegate will need to further show proof of payment in the proof code. As another example, when the condition requires the delegate to provide an email address, the proof code needs to contain the email address. Finally, in response to a determination that the proof data is valid, the computing system grants the delegate’s request; otherwise, the computing system denies the delegate’s request (1150).

[0131] For the processes and methods disclosed by the present disclosure, the operations performed in the processes and methods can be implemented in different sequences. Furthermore, the outlined operations are provided as examples only and some of the operations can be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

[0132] The application can take other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the application is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning of equivalency of the claims are intended to be embraced within the scope of the claims.

Claims

1. A computing system comprising: one or more processors; and one or more computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the one or more processors, cause the computing system to perform the following: determining a relationship between a first decentralized identifier (DID) owner of a first DID and a second DID owner of a second DID, the first DID and the second DID being a pair of DIDs; and delegating a scope of permissions owned by the first DID to the second DID based on the relationship, including: defining the scope of permissions; granting a public key of the second DID to the defined scope of permissions; generating a signature by a private key of the first DID attesting to the delegation of the defined scope of permissions to the public key of the second DID; and propagating a portion of data related to the delegation onto a distributed ledger.

2. The computing system of claim 1, the computing system being further caused to: map a plurality of relationships to a plurality of scopes of permissions; record the mapped data in a memory accessible to the computing system; and determine, based on the mapped data, the scope of permissions corresponding to the relationship between the first DID owner and the second DID owner.

3. The computing system of claim 2, wherein mapping the plurality of relationships to the plurality of scopes of permissions is based on at least one of: (1) data recorded in at least one DID document, (2) data propagated onto the distributed ledger, or (3) user input.

4. The computing system of claim 2, wherein the plurality of relationships includes at least one of: (1) a child-parent relationship, (2) a spouse relationship, (3) an employee-employer relationship, (4) a customer-service relationship, or (5) a contractual relationship.

5. The computing system of claim 2, the computing system being further caused to: determine, in response to a request from the second DID owner of the second DID for access to a scope of permissions, whether a particular relationship still exists; and in response to determining that the particular relationship no longer exists, revoke the delegation of the corresponding scope of permissions, and propagate a portion of data related to the revocation of permissions onto the distributed ledger.

6. The computing system of claim 2, the computing system being further caused to: periodically check whether a particular relationship still exists; and in response to determining that the particular relationship no longer exists, revoke the delegation of the corresponding scope of permissions, and propagate data related to the revocation of permissions onto the distributed ledger.

7. The computing system of claim 2, the computing system being further caused to: in response to receiving user input to change information related to the first DID or information related to the second DID, determine whether a particular relationship still exists; and in response to determining that the particular relationship no longer exists, revoke the delegation of the corresponding scope of permissions, and propagate data related to the revocation of permissions onto the distributed ledger. in response to determining that the particular relationship no longer exists, revoking the delegation of the corresponding permission scope, and propagating data related to the revocation of the permission to the distributed ledger.

8. The computing system of claim 3, the computing system further caused to: receive user input for generating, updating, or deleting a mapped pair of a particular permission scope and a particular relationship, and update the data recorded in the storage that is mapped based on the user input.

9. The computing system of claim 8, the computing system further caused to: in response to the user input, update a delegation between a pair of DIDs that have the particular relationship affected by the user input.

10. The computing system of claim 1, wherein: the definition of the permission scope includes defining one or more restrictions; and the propagating data related to the delegation includes propagating the one or more restrictions to the distributed ledger.

11. The computing system of claim 10, wherein the one or more restrictions include an expiration time of the delegation.

12. The computing system of claim 10, wherein the one or more restrictions include a restriction limiting access to a data portion or a service to a predetermined number of times.

13. The computing system of claim 10, wherein the one or more restrictions include a restriction on access to a data portion, the restriction including at least one of: (1) a read permission, (2) a write permission, (3) a delete permission, or (4) a delegation permission.

14. The computing system of claim 10, wherein the one or more restrictions include one or more conditions, the one or more conditions including at least one of: (1) requiring the second DID to pay a predetermined amount of cryptocurrency, (2) requiring the second DID to provide particular personal data, or (3) requiring the second DID to provide one or more verifiable claims, wherein the particular personal data includes at least one of: (1) an email address, (2) a phone number, (3) a location, (4) a name of an owner of the second DID, (5) an IP address, or (6) a device identifier.

15. The computing system of claim 10, the computing system further caused to perform operations of: receiving a request from a device of the second DID owner to access a permission scope; requesting a delegation to prove the requested permission scope; receiving a proof code from the device of the second DID owner, the proof code configured to prove that the second DID has been delegated to the requested permission scope; verifying the proof code; and based on the verification of the proof code, granting or denying the request from the second DID.

16. The computing system of claim 15, wherein the proof code includes the signature signed by the private key of the first DID.

17. The computing system of claim 15, wherein the verifying the proof code includes: ​ decrypting the signature by a public key of the first DID; retrieving data related to the delegation from the distributed ledger; and analyzing the decrypted signature and the data related to the delegation to determine whether the proof code is valid.

18. The computing system of claim 15, wherein the verifying the proof code further comprises: verifying that the requested scope of permissions is within the delegated scope of permissions; and when the scope of permissions includes one or more conditions, determining whether the one or more conditions are satisfied.

19. A method implemented at a computing system for delegating a scope of permissions owned by a first decentralized identifier (DID) to a second DID, the first DID and the second DID being a pair of DIDs, comprising: determining a relationship between the first DID and a second DID, the first DID and the second DID being a pair of DIDs; and based on the relationship, delegating the scope of permissions owned by the first DID to the second DID, comprising: defining the scope of permissions; granting a public key of the second DID to the defined scope of permissions; generating a signature by a private key of the first DID proving the delegation of the defined scope of permissions to the public key of the second DID; and propagating a portion of data related to the delegation onto a distributed ledger.

20. A computer program product comprising one or more hardware storage devices having thereon computer-executable instructions that are structured such that, when executed by one or more processors of a computing system, the computer-executable instructions cause the computing system to perform at least: determining a relationship between a first decentralized identifier (DID) and a second DID, the first DID and the second DID being a pair of DIDs; and based on the relationship, delegating the scope of permissions owned by the first DID to the second DID, comprising: defining the scope of permissions; granting a public key of the second DID to the defined scope of permissions; generating a signature by a private key of the first DID proving the delegation of the defined scope of permissions to the public key of the second DID; and propagating a portion of data related to the delegation onto a distributed ledger.

Images