associating a decentralized identifier with one or more devices

Abstract

A decentralized identifier (DID) is generated and associated with a group of related devices. First, a device group DID is generated by generating a private key of the device group DID based on a seed and a first hardware identifier of at least one device in the group of devices. The device group DID is associated with the group of related devices. For each device in the group of related devices, a device DID is derived by generating a private key of the device DID based on the seed, a second hardware identifier of the corresponding device, and the device group DID. The device DID is then associated with the corresponding device. Further, a permission scope is granted to the device group DID, and each device DID in the group is granted a subset of the permission scope.

Description

BACKGROUND

[0001] Most identity-attesting documents or records currently in use are issued by a central organization such as a government, school, employer, or other service center or regulatory organization. These organizations often 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 permissions. Centralized identity management systems are considered secure because they often use professionally maintained hardware and software. Typically, the identity-issuing organization sets the terms and requirements for persons to register 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 to verify and / or authenticate the other party’s identity.

[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 some portion of the ledger cannot be changed retroactively without changing all subsequent portions of the ledger, which provides a fairly secure platform. In such a decentralized environment, the owner of each DID typically has control over his / her own data using his / her DID. The DID owner accesses data stored in a personal store associated with the DID via a DID management module, which is a mobile application, personal computer, 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 technical background is provided only as an example of one exemplary technology area where some embodiments described herein can be practiced. SUMMARY

[0004] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

[0005] The prior art often associates a decentralized identifier with user or personally identifiable information. For example, a DID is often associated with a user’s driver’s license. A user can use the DID (when the DID is associated with his or her driver’s license) to prove that he / she is authorized to drive. People want to keep the public keys of people’s DIDs safe and private. Thus, the public keys of such DIDs are generally not propagated onto a public blockchain, and the potential range of use of such DIDs is greatly limited.

[0006] In various examples described herein, there are techniques for associating a DID with a device and / or a group of devices, rather than personally identifiable information, such that the DID (i.e., the device group DID and the device DID) itself is not considered to contain any personally identifiable information, and the public keys of the device group DID or the device DID are not considered personally identifiable information. As such, the public keys of the device group DID and the device DID can be used in many services and propagated onto publicly accessible ledgers. Associating a DID with a device and / or a group of devices is not straightforwardly simple, and examples of techniques to accomplish this are described herein.

[0007] In particular, the principles described herein allow a user to not only use publicly accessible ledgers to manage multiple devices as a group, but also allow the user to use these publicly accessible ledgers to manage one device via another device within the group without publicly exposing the user’s personally identifiable information. Allowing a user to manage devices in a decentralized manner using publicly available ledgers is advantageous because the user will not rely on a particular centralized service to perform various management functions on a group of devices or a particular device. The user’s personally identifiable information is protected not only from the public, but also from the central service provider.

[0008] Further, when public keys are considered personally identifiable information (PII), the use of publicly available ledgers is greatly limited because many services that can be provided via a decentralized system using public keys containing PII must be implemented via a private ledger that is available and maintained by a private entity. The principles described herein remove the personally identifiable information from the public keys, thereby expanding the types of services that can be implemented by publicly accessible ledgers while still protecting the privacy of the user.

[0009] The embodiments disclosed herein relate to generating and associating Distributed Identifiers (DIDs) for groups of one or more related devices. First, a device group DID is generated. The device group DID is associated with a group of one or more related devices. Subsequently, for each of the groups of one or more related devices, a device DID is generated and associated with the corresponding device. A scope of permission is granted to the device group DID. In response to granting a scope of permission to the device group DID, a subset of the scope is granted to each device DID within the group. In this way, an efficient process for generating DIDs and associating them with groups of one or more related devices is provided. Even when dealing with groups of devices, the scope of permission is carefully controlled in a manner that enhances security and privacy.

[0010] In some embodiments, the permission to add a new device to a group or remove an existing device from a group is a subset of the permission scope granted to the device group DID. At least one of the device DIDs is granted permission to add a new device to a device group or remove an existing device from a device group.

[0011] In some embodiments, a new device is added to an existing group of one or more devices. When an instruction to add a new device to a group of one or more devices is received, the new device is verified using at least one licensed existing device in the group of one or more devices. In response to verification using at least one licensed existing device, the new device is added to the group of one or more devices. The action of adding a new device to a group of one or more devices includes deriving the new device's DID and associating the new device's DID with the new device.

[0012] In some embodiments, a device is removed from an existing group of one or more devices. When a specific device in a group of devices is instructed to be removed, the removal of that specific device is verified using at least one licensed existing device that is not in the group of devices. In response to verification using at least one licensed existing device, the specific device is removed from the group of devices. The action of removing the specific device from the group of devices includes revoking all license scopes that have been granted to the device DID and deactivating the device DID associated with that specific device.

[0013] In some embodiments, the act of adding or removing a specific device is recorded in a distributed ledger.

[0014] In some embodiments, the scope of the license includes permission to access a storage device at an identity hub. The identity hub is an attribute storage device, including keys and metadata, under the control of the DID holder. The license includes permission to perform at least one of the following: (1) read a dataset stored at the storage device, (2) write a dataset to the storage device, (3) copy a dataset stored at the storage device, and (4) delete a dataset stored at the storage device.

[0015] In some embodiments, when a specific device in a group of devices requests access to a dataset stored at an ID center, both the device DID corresponding to the specific device and the device group DID corresponding to the group of devices are verified.

[0016] Additional features and advantages will be set forth in the following description and will be apparent in part from the description or learned through the practice taught herein. Attached Figure Description

[0017] To describe how the above and other advantages and features can be obtained, the subject matter briefly described above will be described in more detail with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only typical embodiments and therefore should not be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein:

[0018] Figure 1 The illustration shows an example computing system in which the principles described in this paper are employed;

[0019] Figure 2 The illustration shows an example environment for creating distributed identifiers (DIDs);

[0020] Figure 3 The illustration shows an example environment in which a DID is associated with a device or a group of devices;

[0021] Figure 4 The diagram illustrates an example environment in which various DID management operations and services are performed;

[0022] Figure 5A The illustration shows a sample user interface that displays a list of groups associated with a device;

[0023] Figure 5B The illustration shows a sample user interface that displays a list of devices within a specific group;

[0024] Figure 6 The illustration shows an example embodiment for generating a device group DID using a seed and a hardware identifier;

[0025] Figure 7 The diagram illustrates the process of generating [something]. Figure 6 Example embodiment of the seed of the device group DID;

[0026] Figure 8 The illustration shows an example embodiment for generating a device DID for each device;

[0027] Figure 9 The illustration shows an example environment in which device group DID and device DID are utilized;

[0028] Figure 10 The diagram illustrates a flowchart of an example method for generating a DID and associating it with a group of related devices;

[0029] Figure 11 The flowchart illustrates an example method 1100 for adding a device to a group; and

[0030] Figure 12 The diagram illustrates a flowchart of an example method 1200 for removing a device DID from a group. Detailed Implementation

[0031] The embodiments disclosed herein relate to generating and associating Distributed Identifiers (DIDs) for groups of one or more related devices. First, a device group DID is generated. The device group DID is associated with a group of one or more related devices. Subsequently, for each of the groups of one or more related devices, a device DID is generated and associated with the corresponding device. A license scope is granted to the device group DID. In response to granting a license scope to the device group DID, a subset of the license scope is granted to each device DID within the group.

[0032] In some cases, the permission to add a new device to a group or remove an existing device from a group is a subset of the permission scope granted to the device group DID. At least one of the device DIDs is granted permission to add a new device to a device group or remove an existing device from a device group.

[0033] In some embodiments, a new device is added to an existing group of one or more devices. When an instruction to add a new device to a group of one or more devices is received, the new device is verified using at least one licensed existing device in the group of one or more devices. In response to verification using at least one licensed existing device, the new device is added to the group of one or more devices. The action of adding a new device to a group of one or more devices includes deriving the new device's DID and associating the new device's DID with the new device.

[0034] In some embodiments, a device is removed from an existing group of one or more devices. When a specific device in a group of devices is instructed to be removed, the removal of that specific device is verified using at least one licensed existing device that is not in the group of devices. In response to the verification using at least one licensed existing device, the specific device is removed from the group of devices. The action of removing the specific device from the group of devices includes revoking all license scopes granted to the device DID and deactivating the device DID associated with that specific device.

[0035] In some embodiments, the act of adding or removing a specific device is recorded in a distributed ledger.

[0036] In some embodiments, the scope of the license includes permission to access a storage device at the identity center. The identity center is an attribute storage device, including keys and metadata, under the control of the DID holder. In some cases, the license includes permission to perform at least one of the following: (1) read a dataset stored at the storage device, (2) write a dataset to the storage device, (3) copy a dataset stored at the storage device, and (4) delete a dataset stored at the storage device.

[0037] In some embodiments, when a specific device in a group of devices requests access to a dataset stored at an ID center, both the device DID corresponding to the specific device and the device group DID corresponding to the group of devices are verified.

[0038] Existing implementations often associate decentralized identifiers (DIDs) with user or personally identifiable information. For example, a DID is often associated with a user's driver's license. A user can use the DID to prove that he / she is authorized to drive. It is desirable to keep the public key of such DIDs private. Therefore, the public key of such DIDs is generally not propagated to public blockchains, and the potential use of such DIDs is greatly limited. The principles described herein involve associating DIDs with devices and / or groups of devices, rather than with personally identifiable information, such that the DID (i.e., device group DID and device DID) itself is not considered to contain any personally identifiable information, and the public key of the device group DID or device DID is not considered personally identifiable information. In this way, the device group DID and the public key of the device DID can be used in many services and propagated to public blockchains.

[0039] Meanwhile, personally identifiable information can still be stored in the identity center and / or presented as a verifiable claim along with the device DID or device group DID. For example, pairwise claims can be issued to a predetermined list of one or more verifiable entities. Thus, because the personally identifiable information is only included in the verifiable claim, rather than the DID, it is difficult to trace any specific user using the public key of the device DID.

[0040] Furthermore, to provide additional privacy for DID users, some existing embodiments allow users to generate and use different DIDs to address different entities, so that each DID is used only between a pair of users. This type of DID is sometimes referred to as "paired" DIDs. In some other existing embodiments, separate DIDs are generated using different roles. While paired DIDs and DIDs for different roles improve user privacy, over time, such embodiments require users or their devices to manage and maintain a very large number of DIDs. The principles described herein also alleviate the complexity caused by each user having to manage a large number of DIDs, as associating DIDs with groups and devices reduces the need to frequently generate new DIDs to address third-party entities. Moreover, the information contained in these paired DIDs is packaged in a claim, and the claim is transmitted between the two devices via secure communication, so the information contained in the claim does not need to be propagated to the public blockchain except by the two devices and / or their owners.

[0041] Because the principles described in this article are executed within the context of a computing system, they will be discussed in detail below. Figure 1 This section provides an introductory discussion of the computational system. The description then returns to the principles of the DID platform with respect to the remaining figures.

[0042] Computing systems are increasingly taking on various forms. These include, for example, handheld devices, electronic devices, laptops, desktop computers, mainframes, distributed computing systems, data centers, or even devices not traditionally considered computing systems, such as wearable devices (e.g., glasses). In this specification, the term "computing system" is broadly defined to include any device or system (or combination thereof) comprising at least one physical and tangible processor and physical and tangible memory capable of having computer-executable instructions executable by the processor thereon. The memory can take any form and can depend on the nature and form of the computing system. Computing systems can be distributed in a networked environment and can comprise multiple component computing systems.

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

[0044] The computing system 100 also has several structures thereon, often referred to as “executable components.” For example, the memory 104 of the computing system 100 is illustrated to include an executable component 106. The term “executable component” is a name for a structure well understood by those skilled in the art in computing; it can be software, hardware, or a combination thereof. For example, when implemented in software, those skilled in the art will understand that the structure of an executable component includes software objects, routines, methods, etc., that execute on the computing system, regardless of whether such an executable component exists in the heap of the computing system or on a computer-readable storage medium.

[0045] In this context, those skilled in the art will recognize that the structure of an executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by processor threads), it enables the computing system to perform functions. This structure is likely to be directly readable by the processor on the computer (as if the executable component were binary). Alternatively, the structure is configured to be interpretable and / or compileable (whether in a single stage or in multiple stages) to generate such a binary file that is directly interpretable by the processor. This understanding of the exemplary structure of an executable component, when used with the term "executable component," is entirely within the comprehension of those skilled in the art of computing.

[0046] The term "executable component" is also well understood by those skilled in the art to include structures such as hard-coded or hard-wired logic gates, implemented entirely or almost entirely in hardware, such as in field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any other special-purpose circuitry. Therefore, the term "executable component" is a term for structures well understood by those skilled in the art of computing, whether implemented in software, hardware, or a combination thereof. In this specification, the terms "component," "agent," "manager," "service," "engine," "module," "virtual machine," etc., may also be used. As used in this specification and in the examples, these terms (with or without modifications) are also intended to be synonymous with the term "executable component" and therefore also have structures well understood by those skilled in the art of computing.

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

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

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

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

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

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

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

[0054] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the embodiments of this disclosure is not necessarily limited to the features or actions described above. Rather, the described features and actions are disclosed as examples of implementing embodiments.

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

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

[0057] The remaining figures discuss various computing systems corresponding to the previously described computing system 100. The computing systems in the remaining figures include various components or functional blocks implementing the various embodiments disclosed herein, as will be explained. These various components or functional blocks are implemented on a local computing system or on a distributed computing system, including elements residing in the cloud or aspects implementing 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 those illustrated in the figures, and some components are combined where circumstances permit. Although not necessarily illustrated, the various components of the computing system access and / or utilize processors and memories, such as processor 102 and memory 104, as needed to perform their various functions.

[0058] Now regarding Figure 2 This section provides an introductory discussion of Distributed Identifiers (DIDs) and the environments in which they are created and reside. Figure 2 As illustrated, device or device group 201 is associated with DID 205, which represents the identity of device or device group 201 (hereinafter also referred to as DID device). DID device 201 is configured to register its DID using the creation and registration service, which will be explained in more detail below.

[0059] DID device 201 includes any entity that can benefit from a DID. For example, DID device 201 includes a machine, system, or device, or a collection of machines, devices, and / or systems. In other embodiments, DID device 201 is a sub-part of a machine, system, or device. For example, the device may be a printed circuit board, wherein a sub-part of the circuit board is an individual component of the circuit board. In such embodiments, the machine or device has a DID and each sub-part also has a DID. DID device 201 may also be a software component, such as those described above. Figure 1 The executable component 106 is described. An example of a complex executable component 106 could be artificial intelligence. In some embodiments, artificial intelligence is also associated with DID.

[0060] Furthermore, although DID device 201 is shown as having a single DID 205, this need not be the case, as any number of DIDs may be associated with DID device 201 when circumstances permit.

[0061] DID device 201 is used by a human or human organization. Such organizations may include companies, departments, governments, agencies, or any other organization or group of organizations. In the following, such human users and / or organizational users are referred to as users. In some embodiments, each individual human user has a DID, and the organization to which each person belongs may also have a DID.

[0062] As mentioned, DID device 201 is configured to create and register DID 205. DID 205 is an identifier associated with DID device 201. Preferably, this identifier is unique to DID device 201, at least within the scope in which the DID is expected to be used. In some cases, the identifier is locally unique, and it may be more desirable to be a globally unique identifier for an identity system expected to operate globally. In some embodiments, DID 205 is a Uniform Resource Identifier (URI) (such as a Uniform Resource Locator (URL)) or another pointer that associates DID device 201 with a mechanism participating in trusted interactions with DID device 201.

[0063] 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 device 201. This differs from traditional centralized IDs, which are based on trust in a centralized authority and remain under the control of a corporate directory service, certificate authority, domain name registry, or other centralized authority (collectively referred to herein as “centralized authority”). Therefore, DID 205 is any identifier under the control of DID device 201 and independent of any centralized authority.

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

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

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

[0067] Figure 2 The diagram also illustrates a DID document 210 associated with DID 205. As will be explained in more detail below, DID document 210 is sometimes generated when DID 205 is created. In its simplest form, DID document 210 describes how DID 205 is used. Therefore, DID document 210 includes a reference to DID 205, which is the DID described by DID document 210. In some embodiments, DID document 210 is implemented according to a method specified by distributed ledger 220, which will be used to store a representation of DID 205, as will be explained in more detail below. Therefore, depending on the specific distributed ledger, DID document 210 often has different methods.

[0068] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID device 201. Public key 207 is used by a third-party entity that has been granted permission by DID device 201 to access information and data owned by DID device 201. In some cases, public key 207 is used to verify that DID device 201 is actually associated with or controls DID 205.

[0069] In some cases, DID document 210 also includes authentication information 211. Authentication information 211 specifies one or more mechanisms by which DID device 201 can prove that DID device 201 is associated with DID 205. In other words, the mechanism of authentication information 211 demonstrates proof of binding between DID 205 (and therefore DID device 201) and DID document 210. In one embodiment, authentication information 211 specifies that public key 207 is used in a signing operation to prove ownership and / or association of DID 205. Alternatively or additionally, authentication information 211 specifies that public key 207 is used in a biometric operation to prove ownership and / or association of DID 205. Therefore, authentication information 211 can include any number of mechanisms by which DID device 201 can prove that DID device 201 is associated with DID 205.

[0070] In some cases, DID document 210 also includes authorization information 212. Authorization information 212 allows DID device 201 to authorize a third-party entity to modify DID document 210 or certain portions thereof, without granting the third party the right to prove ownership and / or association with DID 205. For example, authorization information 212 allows a third party to use any specified update mechanism to update any specified set of one or more fields in DID document 210. Alternatively, authorization information 212 allows a third-party device to restrict DID device 201's use of DID 205 for a specified period. This is useful when DID device 201 is a device belonging to a minor child and the third-party device is the device of the child's parent or guardian. Authorization information 212 allows the parent or guardian's device to restrict the use of DID 201 until the child is no longer a minor.

[0071] In some cases, authorization information 212 also specifies one or more mechanisms that third parties will need to follow to prove they are authorized to modify DID document 210. In some embodiments, these mechanisms are similar to those discussed earlier with respect to authentication information 211.

[0072] In some cases, DID document 210 also includes one or more service endpoints 213. Service endpoints include network addresses that operate on behalf of DID device 201. Examples of specific services include discovery services, social networks, file storage services such as identity servers or centers, and verifiable claims repository services. Therefore, service endpoints 213 operate as pointers to services that operate on behalf of DID device 201. In some cases, these pointers are used by DID device 201 or devices of third-party entities to access services that operate on behalf of DID device 201. Specific examples of service endpoints 213 will be explained in more detail later.

[0073] In some cases, 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 further embodiments, the other information 216 includes additional information specified by a particular method of implementing the DID document or expected by the DID device 201.

[0074] Figure 2 The diagram also illustrates a distributed ledger or blockchain 220. Distributed ledger 220 includes any decentralized distributed network comprising various computing systems communicating with each other. For example, 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 illustrated by ellipsis 260.

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

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

[0077] In one embodiment, when DID device 201 creates DID 205 and the associated DID document 210, DID hashes 231, 241, and 251 are written to a distributed ledger or blockchain 220. The distributed ledger or blockchain 220 thus records that DID 205 now exists. Because the distributed ledger or blockchain 220 is decentralized, DID 205 is not controlled by any entity other than DID device 201. In some cases, DID hashes 231, 241, and 251, in addition to pointers to DID document 210, include a record or timestamp specifying when DID 205 was created. In some cases, a later date on which DID document 210 is modified is also recorded in DID hashes 231, 241, and 251. In some cases, DID hash 231, DID hash 241, and DID hash 251 also include a copy of public key 207, so that DID 205 is cryptographically bound to DID document 210.

[0078] Furthermore, unlike most existing DID implementations, such as Figure 2 As illustrated in the diagram, the principle described herein introduces a direct association between DID 205 and DID device 201, rather than with any specific user. This prevents a user's personally identifiable information from being publicly traced to DID 205 and provides the user with additional privacy.

[0079] For example, in some existing embodiments, when a DID is associated with a user (hereinafter referred to as a user DID), the DID document corresponding to the user DID often includes personally identifiable information in its identification information. This identification information includes personally identifiable information about the DID user, such as name, address, occupation, family members, age, hobbies, interests, etc. When such a DID is reused, even if the user DID does not include the user's exact identity, a third party can still associate the user DID with a specific user or narrow down the user to a small number of users.

[0080] Unlike user DID, the device DID 201 described herein addresses the aforementioned problem by associating the DID with the device rather than with the user, such that the DID includes only device information and not user information.

[0081] Furthermore, some government regulations prohibit organizations from publicly disclosing personally identifiable information. Such regulations prohibit decentralized service providers from recording user DIDs on public blockchains and / or publishing transactions including user DIDs. However, since device DID 201 typically does not contain any personally identifiable information, such device DID 201 is unlikely to be subject to such government regulations. Thus, implementing device DID 201 allows decentralized service providers to offer users a wider range of services.

[0082] Additionally, the principles described herein simplify distributed systems by reducing the number of DIDs that need to be generated and managed for each user. For example, in some existing embodiments, separate DIDs are generated for different parties to further protect user identity; that is, each DID is used only between a pair of users. This type of DID is sometimes referred to as “paired” DIDs. In some other existing embodiments, separate DIDs are generated using different roles. Paired DIDs and DIDs for different roles improve user privacy. However, over time, such embodiments require users or their devices to manage and maintain a very large number of DIDs.

[0083] The principles described in this article also aim to address the problems caused by the massive increase in DIDs. Since device DID 205 generally does not include personally identifiable information, it is not necessary to generate a new DID for each different device, and the same device DID 205 can be reused to communicate with multiple other devices while still protecting user privacy. However, please note that each device does not necessarily have only one DID. Each device can still have multiple DIDs. The following is about... Figure 3 Further details on how a device is associated with one or more DIDs.

[0084] Figure 3 The illustration shows an example environment 300, where a DID is associated with a device or a group of devices. Environment 300 includes multiple device groups, including device group 310, device group 320, and device group 330, each device group being associated with a DID (hereinafter referred to as device group DID). Device group 310 is associated with device group DID 317, device group 320 is associated with device group DID 327, and device group 330 is associated with device group DID 333. The ellipsis 340 indicates that any number of additional device groups can exist in environment 300.

[0085] Each device group is used by a corresponding user or user group. For example, device group 310 is used and / or owned by user / user group 318, device group 320 is used and / or owned by user / user group 328, and device group 330 is used and / or owned by user / user group 334. (See also: ...) Figure 2 In this brief discussion, "users" refers to either individuals or organizations. Organizations include groups of people, companies, departments, governments, agencies, or any other organization or group of organizations.

[0086] Each device group includes multiple associated devices. For example, group 310 includes device A311, device B312, and device C313, each of which is associated with a device DID. For example, device A311 is associated with device DID 314, device B312 with device DID 315, and device C313 with device DID 316. User 318 can be the person who owns device group 310. User 318 owns various different devices. For example, device A311 can be a mobile phone or other mobile device, device B312 can be a laptop computer, and device C313 can be a personal computer.

[0087] As another example, group 320 includes device D 321 and device E 322, each of which is also associated with device DID. Device D 321 is associated with device DID 324, while device E 322 is associated with device DID 325. The ellipsis 323 indicates that any number of additional devices can exist in group 320. User 328 can be an organization that owns multiple devices, including device D 321 and device E 322.

[0088] Furthermore, in some embodiments, the device is included in more than one group and associated with more than one device DID. For example, such as Figure 3As illustrated, group 330 includes devices C 313 and D 321, each of which also belongs to another group. Specifically, device C 313 belongs to both group 310 and group 330, and is associated with both device DID 316 and device DID 331. Specifically, one device DID of device C 313 (i.e., device DID 316) belongs to group 310, and another device DID of device C 313 (i.e., device DID 331) belongs to group 330. Similarly, device D 321 belongs to both group 320 and group 330, and is associated with both device DID 324 and device DID 332. Specifically, one device DID of device D (i.e., device DID 324) belongs to group 320, and another device DID of device D (i.e., device DID 332) belongs to group 330. In this context, group 334 is a team of members working together on the same project. Each of the users of device C 313 and device D 321 is a team member of user group 334.

[0089] Each device in environment 300 (e.g., device A 311, device B 312, device C 313, device D 321, and device E 322) corresponds to Figure 2 The DID of device 201, and each device DID (e.g., device DID 314, 315, 316, 324, 325) corresponds to Figure 2 DID 205.

[0090] Already referred to Figure 2 and Figure 3 Having described device DIDs and how they are typically associated with devices, we will now explain specific embodiments of devices associated with their DIDs. (Go to...) Figure 4 The environment 400 used to perform various DID lifecycle management operations and services will now be explained. It should be understood that, for ease of explanation, Figure 4 The environment needs to be referenced Figure 2 and Figure 3 The elements in.

[0091] like Figure 4 As shown, environment 400 includes various devices and computing systems owned or otherwise controlled by various users. These include device 401. Device 401 corresponds to... Figure 2 Equipment 201 and / or Figure 3Device 401 is any one of devices 311, 312, 313, 321, and 322. Device 401 includes, but is not limited to, mobile devices such as smartphones, computing devices such as laptops, or any device such as automobiles or appliances that include computing capabilities. Device 401 also includes a web browser running on the device and an operating system running on the device. More broadly, device 401 or any part of device 401 (including, but not limited to, a web browser, operating system, and any particular application) is considered DID device 201 and associated with DID 205.

[0092] Device 401 includes a DID lifecycle management module 420. It should be noted that in operation, the DID lifecycle management module 420 resides on and is executed by the operating system of device 401 and / or is installed on and by a specific application on device 401. In some embodiments, the DID lifecycle management module 420 is hosted on a remote service or cloud service. A web browser installed on device 401 or a web application implemented on device 401 allows the user to interact with the remote service. Therefore, for ease of explanation, the DID lifecycle management module 420 is shown as independent.

[0093] like Figure 4 As shown, the DID lifecycle management module 420 includes a DID creation module 430. Device 401 uses the DID creation module 430 to create device group DID 517 and device DID 516, or any number of additional group DIDs or device DIDs.

[0094] For example, device 401 corresponds to Figure 3 Device C 313. When a device group is generated for the first time, the device that generates the device group is likely to be the first device to be included in the group. As an example, device C 313 is the device that generates device group 310. To generate device group 310, DID lifecycle management module 420 first generates device group DID 317, and then associates device DID 317 with the group. After generating device group 310, DID lifecycle management module 420 then generates device DID 416 and associates device DID 416 with the device.

[0095] Later, the user may sometimes want to add device C 313 to another group (e.g., a workgroup). For example, group 330 is a workgroup that includes several colleague devices. Group 330 is created by device D 321, and device group DID 333 has already been generated by the management module of device D 321. To join group 330, device D 321 needs to approve the join request from device C 313. Once device D 321 approves the request from device C 313, device D 321 sends device group DID 333 to device C 313, and device C 313's DID creation module 430 then uses the received device group DID 333 to generate a new device DID 316. Device DID 316 is then associated with device C and used to access data or services associated with group 330.

[0096] In one embodiment, the DID creation module 430 also includes, or is otherwise accessible, a user interface (UI) element 435 that instructs the device 401 to create device group DID 417 and / or device DID 416. The DID creation module 430 has one or more drivers configured to work with a specific distributed ledger (such as distributed ledger 220) such that DID 417 and / or 416 conform to the underlying methodology of that distributed ledger 220.

[0097] The DID creation module 430 also includes a key generation module 450. The key generation module generates the previously described private key 206 and public key 207 pair. The DID creation module 430 then uses the group DID 417 and / or device DID 516 and the corresponding private and public key pairs to generate a DID document 480 (in some cases, which corresponds to...) Figure 2 (DID document 210).

[0098] In operation, the DID creation module 430 accesses the registrar 410, which is configured to record a specific distributed ledger of transactions associated with DID 417 and / or DID 416. The DID creation module 430 uses the registrar 410 to record the DID hash in the distributed ledger as described above, and to store the DID document 480 as described above.

[0099] In some embodiments, the DID lifecycle management module 420 includes an ownership module 440. The ownership module 440 provides a mechanism to ensure that device 401 is aware of the separate control of DID 417 and / or DID 416. In this way, the provider of the DID lifecycle management module 420 can ensure that the provider does not control DID 417 and / or 416, but only provides management services.

[0100] As previously discussed, key generation module 450 generates a private key and public key pair 408 for device group DID 417. The public key of device group DID 408 is recorded in DID document 480. Similarly, key generation module 450 also generates a private key and public key pair 409 for device DID 416. The public key of device DID 409 is also recorded in DID document 480.

[0101] When device 401 wishes to join a new group or create a new group, device 401 again executes DID creation module 430 to generate a new group DID and a new device DID associated with that group. DID creation module 430 then uses registrar 410 to update the same DID document 480 or a different DID document (not shown) to reflect the association of the new group DID and the new device DID with device 401, and this is also reflected in the update transactions on distributed ledger 220, as previously described.

[0102] In some embodiments, it is advantageous to have only one group DID and one device DID associated with a specific device. A group DID is used to identify a specific user's personal device, giving the user complete control over each of his / her personal devices. In some embodiments, it is advantageous to generate multiple group DIDs and multiple device DIDs for various purposes. For example, a user adds their devices to various groups, such as personal device groups and work device groups. In work device groups, colleagues or teams can collaborate with each other. Within each group, a permission scope is granted to the group DID. Once a permission scope is granted to the group DID, each device DID within the group will be granted a subset of the permission scope.

[0103] In other embodiments, the DID lifecycle management module 420 includes a recovery module 460 for recovering lost private keys 206. In operation, the recovery module 460 allows device 401 to select one or more recovery mechanisms when DID 417 or 416 is created, which are later used to recover the lost private keys. The DID lifecycle management module 420 also includes an undo module 470, which is used to undo or disconnect the device from group DID 417 or device DID 416.

[0104] As briefly described above, the DID lifecycle management module 420 also includes a user interface (UI) 435, and the functions of different modules are executed by interfacing with the UI 435. For example, the UI 435 allows the device 401 to provide the necessary information required by one or more recovery mechanisms when implementing a recovery mechanism. The recovery module 460 is then run to recover any of the DIDs generated by the DID creation module 430.

[0105] In operation, the revocation module also uses UI element 435, which allows device 401 to indicate that it wishes to remove the device from the list associated with DID 417 or 416. In one embodiment, the revocation module accesses DID document 480 and causes all references to the device to be removed from DID document 480. Alternatively, public keys 408 and 409 for the device are removed. This change in DID document 580 is then reflected as an update transaction on distributed ledger 220, as previously described.

[0106] Some example embodiments of UI 435 will now be described. For example, UI 435 prompts the user to enter a username or some other human-recognizable name. This name is used as the display name for the group DID 417 and / or device DID 416 to be generated. As previously mentioned, group DID 417 and / or device DID 416 are long strings of random numbers and letters, and therefore having a human-recognizable name for the display name is advantageous. In some embodiments, UI 435 is able to present the public key of each group DID or device DID as an encoded image, such as a barcode or QR code. In some embodiments, UI 435 presents group DID 417 or device DID 416 in a list of identities (e.g., device identities) and associates it with a human-recognizable name (e.g., a user's name or workgroup name).

[0107] Figure 5A The illustration shows a sample device group list user interface 500A displayed to the user. (Reference) Figure 5A The user interface 500A includes a title bar 510 that displays the subject title of the user interface 500A. For example, the title bar 510 simply displays "Group List".

[0108] The 500A user interface workspace includes a table or list showing all the groups to which a device belongs. The device corresponds to... Figure 4 Device 401. In some embodiments, the list is as simple as listing only the group name 511. In some embodiments, additional attributes and details for each group are listed. For example, a brief description of the group is included as a column (e.g., group description column 512), a list of devices belonging to that group is also included in the table (e.g., device column 513), and the public key for each group is also included in the table (e.g., public key column 514). The complete DID (including the private key) for each group is also included in the table. However, since private keys usually need to be kept confidential, it is best not to store private keys on the device or display them on the user interface 500A.

[0109] Figure 5AExample table 520A illustrates the groups to which devices belong. For example, a device (running the DID lifecycle management module 420) belongs to group I 515 and group II 519. Group I 515 includes multiple personal devices owned by the user (e.g., device A, device B, and device C 517), and the public key for group I is 123abc 518. Group II 519 is the workgroup 520 to which the user belongs. Workgroup 520 includes device C, device D, and device E 521, and the public key for group II is 456def 522. The ellipsis 523 indicates any number of groups to which the user belongs. In some cases, a device belongs to only one group (e.g., personal device group 516). In some cases, a device belongs to many different groups, depending on the purpose of the device.

[0110] At the bottom of the device group UI 500A, there are one or more buttons or links that users can click to activate additional functions provided by the DID lifecycle management module 420. For example, the "Create New Group" button 524 allows users to create a new group. When the user clicks button 524, a pop-up window (not shown) or other UI elements are generated to prompt the user to enter a new group name and group description. In some embodiments, when a group is created for the first time, only the device that created the group is included in the group by default. In some embodiments, the pop-up window also prompts the user to enter the devices to be added to the group. The user enters the physical identifier (e.g., MAC address) of each device to add the device to the group. Thereafter, the key generation module 450 automatically generates a public and private key pair for the newly created group.

[0111] In addition, the user clicks the "Join Group" button 525 to join an existing group. When the user clicks button 525, another pop-up window is generated for the user to enter information about the existing group. For example, the user enters the group's public key, group name, or the physical identifier (e.g., the device's MAC address) of a device that already belongs to the group.

[0112] Additionally, the "Leave Group" button 526 allows a device to leave a group. When a user clicks button 526, a pop-up window is generated for the user to select one or more groups they wish to leave. After the user confirms the leave group action, the reversal module 470 updates the DID document 480 to remove the corresponding device public key 408 and device group public key 409. The reversal transaction is also recorded in the distributed ledger 220 or the registrar 410.

[0113] Finally, the "Restore Group DID" button 527 allows the user to restore the group DID. In some embodiments, the group DID is required for other purposes or by another device that is about to join the group. When the user clicks button 527, the user is prompted to select the group whose DID they want to restore.

[0114] In some embodiments, each group name 515, 519 is also a clickable link. When a user clicks a specific group name 515 or 519, the device group user interface is displayed. The device group user interface includes additional details about the specific group.

[0115] Figure 5B The illustration shows a sample device group user interface 500B, which displays information for a specific group. Figure 5B As illustrated, the device group UI 500B includes a title bar displaying the group name 530. The workspace of the user interface 500B displays a table or list 530A of the devices included in the group. In some embodiments, the workspace is as simple as the list of device names 531. In some embodiments, additional information is displayed. For example, a brief description of each device is displayed on table 530A (e.g., device description column 532). The physical identifier 533 of each device is also displayed on the table. The physical identifier of a device includes (but is not limited to) a MAC address 537 or a serial number 541. The public key 534 of each device is also displayed.

[0116] For example, such as Figure 5B As illustrated, the selected group includes device A 535 and device B 539. The ellipsis 543 indicates that any number of additional devices exist in group 530. Device A is a mobile phone 536, and device B is a laptop computer 540. The MAC address 537 of device A is listed as a hardware identifier, and the serial number 541 of device B is also listed as a hardware identifier. Additionally, the public key of device A is 789ghi, and the public key of device B is abc321, which are also listed in the table.

[0117] In addition, supplementary information is included and recorded in Table 530A. For example, certain activities of each device are also recorded and displayed. When the group is a group of personal devices, the same user is using every device included in the group. In this case, it would be advantageous for the user to view the activity of each device. If there is any abnormal activity, the user can see it, or the system allows for the automatic removal or suspension of devices with abnormal activity from the group.

[0118] At the bottom of the user interface 500B, there are numerous buttons or clickable links that allow users to perform various functions provided by the DID management module 430. For example, the "Add Device" button 544 allows users to add a device to a group. When the user clicks button 544, the user is prompted to enter information about the new device (e.g., physical identifier). Once the user confirms adding the new device to the group, the new device receives an invitation to join the group.

[0119] The "Remove Device" button 545 allows the user to remove a device. For example, when the user clicks button 545, they are prompted to select one or more devices from a list to be removed. Once the user confirms the removal, the revocation module 470 performs certain operations, including removing the corresponding device public key from the DID document 480 and / or recording the removal transaction at the distributed ledger 220 or the registrar 410. Additionally, in some cases, the removed device also receives a notification that it has been removed from the group. The management module installed on the removed device also performs the removal operation, removing not only the information associated with the device DID but also the information associated with the group DID. The removal operation is very useful when a device is lost or otherwise damaged.

[0120] In addition, in some cases, a device within a group can also be allowed to restore the device DID of another device. The "Restore Device DID" button 546 allows a device to select another device in the group and restore that other device's DID if needed.

[0121] In some embodiments, for added security, more than one device is required to perform certain operations. For example, when adding a new device to a group, the user may be configured to require confirmation from two different existing devices within the group or from any number of devices within the group. One device initiates the addition of the new device to the group. Once the addition operation is initiated, each other device in the group or another specific device receives a notification. At least one other device that receives the notification must confirm and approve the addition operation for the new device to be finally added to the group.

[0122] User interfaces 500A and 500B are merely examples of UI 435 implemented at the DID lifecycle management module 420. Additional user interface elements or layouts are implemented to perform the same or additional functions.

[0123] Return to reference Figure 4 The DID lifecycle management module 420 includes a DID creation module 430. Example embodiments of the DID creation module 430 will be described below. Figures 6-8 Further discussion. Theoretically, each group or device DID can be randomly generated, and there doesn't necessarily need to be any relationship between two device DIDs. However, since devices within a group are often owned by the same user or used by the same group of users, it would be advantageous to systematically generate and manage the DIDs of all related devices within the same group. In this way, a DID generated by one device can be recovered from another device.

[0124] Figure 6 An example embodiment 600 for generating a device group DID is illustrated. Embodiment 600 corresponds to... Figure 4 The DID generation module 430. (For example...) Figure 6As illustrated, seed 601 and hardware identifier 602 are used as two inputs 605 and 606 to function 604 to generate output 608. Output 608 is then used as the private key 610 for device group DID. The private key 610 for device group DID is then used to generate the public key 611 for device group DID. The private key 610 and the public key 611 for group DID are then used as the key pair for device group DID 609.

[0125] Function 604 is any deterministic function that can produce different results when different inputs are received, or only in very rare cases when different inputs lead to the same result. The probability of producing the same result based on different inputs is negligible because it is nearly impossible for someone to regenerate device group DID 609 without the correct two inputs 605 and 606. Furthermore, it is desirable that function 604 be a one-way function so that it is computationally difficult to deduce the two inputs from the result. For example, function 604 could be a hash function configured to generate a fixed-size code.

[0126] Hardware identifier 602 is any constant value associated with a hardware device. This constant value is a combination of more than one constant value. For example, device 501 has a serial number assigned by its manufacturer, which is used as hardware identifier 602. Alternatively, hardware identifier 602 is an identifier of the hardware at a service provider (e.g., identity center 911) to which the device's group has access. Alternatively or additionally, hardware identifier 602 is a combination of the service provider's identifier (e.g., the service provider's name, numeric identifier, etc.) and the identifier of device 501. As another example, hardware identifier 602 is a combination of the identifier of identity center 911 (to which the device's group has access) and the identifier of device 501. The constant value of hardware identifier 602 is (but is not limited to) a BIOS serial number, motherboard serial number, the MAC address of the network adapter, and the machine security identifier (SID) of device 501 and / or the service provider.

[0127] In some embodiments, multiple additional values ​​are input as inputs to function 604. For example, in some embodiments, the group index number is used as one of the inputs to function 604. When a new group DID is generated, the index number is incremented by one, so that even if the same function 604 is used to generate each group DID, different group DIDs are generated because different group indices are used as one of the inputs.

[0128] Seed 601 is input by the user, such as a passphrase. Alternatively, seed 601 is code generated based on the user-input passphrase. The following will discuss... Figure 7 Further details are described for an example embodiment used to generate seed 601.

[0129] Figure 7 The illustration shows an example embodiment 700 for generating seed 707, which corresponds to Figure 6 Seed 601 in [the database]. Reference. Figure 7 The passphrase 701 and hardware identifier 702 are used as two inputs to function 703 to generate output 706. Output 706 is then used as seed 707. Passphrase 701 is input from the user. In some embodiments, hardware identifier 702 here is the same as hardware identifier 602. Alternatively, hardware identifier 702 may be generated using different mechanisms or different constant values ​​associated with the same or different hardware blocks; therefore, they are not necessarily the same value. For example, hardware identifier 702 may use the BIOS serial number of device 501, and hardware identifier 602 may use the motherboard serial number of device 501.

[0130] Function 703 is any deterministic function that can produce different results when given different inputs 704 and 705, and the same result when given the same inputs 704 and 705. Alternatively, different inputs 704 and 705 may lead to the same result only in very rare cases. This potential risk is often ignored as long as the chance of producing the same result with different inputs is very small. Furthermore, it is desirable that function 703 is a one-way function so that it is computationally difficult to deduce the two inputs 701 and 702 using the output 706. For example, function 703 is a hash function configured to generate a fixed-size code. The generated fixed-size code is then used as a seed 707.

[0131] Then, seed 707 was used as Figure 6 One of the inputs to function 604 is used to generate group DID 609. Therefore, even if group DID 609 is long and complex (e.g., 4096 bits), the user or device associated with the DID does not need to remember or record it. Instead, the user or device only needs to remember the passphrase he / she initially entered. Each time the passphrase is received, the system will be able to regenerate seeds 707, 601. Based on the regenerated seeds 707, 601 and the retrieved hardware identifiers(s) 602, 702, device 501 can regenerate device group DID 609 at any time.

[0132] Different implementations for generating device DIDs can be achieved. Using, for example... Figure 6 and Figure 7 A similar implementation to the diagram is used to generate the device DID. For example, the user is prompted to use a different passphrase to generate the device DID. Alternatively or additionally, a device DID indicator is used as additional input in functions 604 and / or 703 to generate the device DID.

[0133] Figure 8An example embodiment 800 for generating device DID 809 is illustrated. Figure 8 As illustrated, seed 801, hardware identifier 802, and device DID indicator 803 are used as the three inputs 805, 806, and 807 to function 804. The output 808 is then used as the private key 810 for the device DID. The private key 810 is subsequently used to generate the public key 811 for the device DID. The private key 810 and the public key 810 are then used as the key pair for device DID 809. Function 804 is any deterministic function that can produce different results when different inputs are received, or only in very rare cases when different inputs lead to the same result. The probability of producing the same result based on different inputs is negligible because it is virtually impossible for someone to regenerate device DID 809 without the correct three inputs 805, 806, and 807. Furthermore, it is desirable that function 804 be a one-way function so that it is computationally difficult to deduce the two inputs from the result. For example, function 804 could be a hash function configured to generate a fixed-size code.

[0134] Similar to hardware identifier 602, hardware identifier 802 is any constant value associated with a hardware device. Similar to seed 601, seed 801 is generated via any deterministic one-way function 703. Device DID indicator 803 is any value that indicates that the DID is a device DID and not a group DID or any other type of DID. For example, specific natural numbers are used to indicate that the generated DID is a device DID. As an example, "1" is used as a device DID indicator to indicate that the generated DID is a device DID; "0" is used as a device group DID indicator to indicate that the generated DID is a group DID.

[0135] Including the hardware identifier 802 as part of the input to generate the device DID is advantageous because it is easy to verify whether the device DID matches the corresponding device when it is used. For example, if another user obtains the device DID and attempts to access data via another device using that device DID, the system can detect that the other device is not part of the group because the device DID cannot be regenerated using the identifier of that other device.

[0136] In some embodiments, additional inputs are added as inputs to function 805. For example, an index number is added as an additional input to function 805. The index is incremented by one each time a new device is added to the group. In some embodiments, the hardware identifier 803 is replaced by another input. For example, the index number is used instead of the hardware identifier as an input to function 805.

[0137] therefore, Figures 6 to 8Example embodiments for generating DIDs using various deterministic functions are provided. As long as the user remembers his / her passphrase, the device group DID and / or each device DID is recovered by any device management module 420 installed on any device included in the group. Furthermore, since the device DID is generated using constant values ​​associated with the device, it is possible to verify whether a device attempting to access certain data is truly associated with the device DID presented to the ID center 911.

[0138] Furthermore, as briefly described above, various services are provided by utilizing device DIDs in a distributed environment such as Environment 300. For example, a group of device DIDs is granted a scope of permission to access individual storage devices at an ID center. Once a group of device DIDs is granted a scope of permission, each device DID within the group is granted a subset of the scope of permission. The permission includes permission to perform at least one of the following: (1) read a dataset stored at a storage device, (2) write a dataset to a storage device, (3) copy a dataset stored at a storage device, and (4) delete a dataset stored at a storage device.

[0139] Figure 9 The illustration depicts an example environment 900 in which device group DID and device DID are used. Specifically, environment 900 will be used to describe the use of device group DID 317 and device DIDs 314 to DID 316 associated with one or more distributed personal storage devices or identity centers. It should be noted that... Figure 9 Including the first regarding Figure 2 or Figure 3 The elements discussed are referenced, and therefore the same reference numerals are used in the accompanying drawings for ease of explanation.

[0140] In one embodiment, identity center 910 is multiple instances of the same identity center. This is indicated by line 910A. Therefore, each identity center 910 includes at least some of the same data and services. Thus, if any change is made to one of the identity centers 910, that change is reflected in the remaining identity centers. For example, a first identity center 911 and a second identity center 912 are implemented in a cloud storage device and are therefore capable of storing large amounts of data. Therefore, the complete dataset is stored in these identity centers. However, in some cases, identity center 913 has less storage space. Therefore, in this identity center, descriptors of the data stored in the first and second identity centers are included. Alternatively, records of changes made to data in other identity centers are included. Thus, changes in one of the identity centers 910 are either completely copied in the other identity centers, or at least one record or descriptor of that data is recorded in the other identity centers.

[0141] Because the identity center is multiple instances of the same identity center, only a complete description of the first identity center 911 will be provided, as this description also applies to identity centers 912 through 913. As illustrated, identity center 911 includes a data storage device 920. The data storage device 920 is used to store any type of data associated with device group DID 317.

[0142] In one embodiment, the data is a set 922 of data of a specific type corresponding to a specific protocol. For example, set 922 is medical record data corresponding to a specific medical data scheme. Set 922 can also be any other type of data.

[0143] In one embodiment, the stored data has different authentication and privacy settings 921 associated with the stored data. For example, a first subset of the data has a setting 921 that allows the data to be publicly exposed, but does not include any authentication for device group DID 317. This type of data is used for relatively unimportant data, such as color schemes, etc. A second subset of the data has a setting 921 that allows the data to be publicly exposed and includes authentication for device group DID 317.

[0144] The third subset of the data has setting 921, which encrypts the data subset using a private key 206 and public key 207 pair (or some other key pair) associated with device group DID 317. This type of data will require the device to have private key 207 or some other associated private key in order to decrypt the data. In some embodiments, the process also includes authentication of device group DID 317.

[0145] Because group DID 317 is associated with device group 310, which includes device A 311, device B 312, and device C 313, each corresponding DID 314, 315, or 316 associated with device A 311, device B 312, or device C 313 is granted access to a subset of the permitted scope, such as granting group DID 317 access to data storage device 920. In some embodiments, identity center 911 has a licensing module 930 that allows device group DID 317 to set specific authorizations or licenses for other devices to access identity center. For example, device group DID 317 grants access licenses to all devices included in group 310 to access all data 920.

[0146] In some embodiments, the identity center 911 also includes a messaging module 940. In operation, the messaging module allows the identity center 911 to receive messages such as requests from other devices, such as device A 311, device B 312, and device C 313, for accessing the data and services of the identity center 911. Furthermore, the messaging module 940 allows the identity center 911 to respond to messages from devices and also communicates with the DID resolver 950. This will be explained in more detail later. The ellipsis 916 indicates that the identity center 911 may have any number of additional services when circumstances permit.

[0147] In one embodiment, device A 311 wishes to add a new device 917 to group 310. (See also: Regarding...) Figure 4 The user interacts with the DID lifecycle management module 420 installed on device A 311 to initiate the addition of a new device to group 310. After device A 311 initiates the addition operation, the DID management module installed on the new device 917 receives a notification and generates a new DID 918. The new DID 918 is then associated with the new device 917 and added to group 310. Once the new device 917 is included in group 310, the new DID 918 is granted the same permissions as group DID 917. When the new device 917 associated with the new DID 918 is added to group 310 and granted access to the data storage device 920, the transaction of adding the new device 917 associated with the new DID 918 is recorded in the distributed ledger 220.

[0148] However, the identity center 911 initially did not recognize the new device 917 as associated with group 310. Therefore, the identity center 911 contacted the DID resolver 950 using the messaging module 940. The message sent to the DID resolver 950 included the DID 918 associated with the new device 917.

[0149] DID resolver 950 is a service, application, or module configured in operation to search the distributed ledger 220 for DID documents associated with a DID. In this case, DID resolver 950 searches the distributed ledger 220 using a new device DID 918, resulting in DID resolver 950 finding a DID document corresponding to the new DID 918. The DID document corresponds to... Figure 2 The DID document 210. The DID document is then provided to the identity center 911.

[0150] As previously discussed, DID document 210 includes the public key associated with the corresponding DID. To verify that the group has authorized the new device DID 317, identity center 911 uses messaging module 940 to provide a cryptographic challenge to the new device. This cryptographic challenge is constructed such that only devices with access to the key (e.g., private or public key) will be able to successfully answer the challenge.

[0151] It should be noted that the authentication process for the new device 918 does not require the user of the new device to provide any usernames, passwords, etc., to the provider of Identity Center 918 (i.e., the cloud storage provider) before access to Identity Center 918 is granted. Instead, access is determined in a decentralized manner based on DID 918, the DID document, and the associated public and private keys. Because these remain under the control of the new device 918, the provider of Identity Center 911 is not involved and therefore unaware of any personal information of the transaction or the user of device 918.

[0152] Once a new device is included in group 310, it accesses DID resolver 950 to access DID document 210. As previously discussed, DID document 210 includes endpoint 213, which is an address or pointer to identity center 911. The new device 918 then uses the address or pointer to access identity center 911.

[0153] Advantageously, the above process allows Identity Center 911 and multiple devices to communicate and share data without requiring users to access Identity Center 911 in a conventional manner. Instead, communication is provided in a decentralized manner using DIDs 314, 315, 316, and 918, along with DID documents. This advantageously allows users complete control over the process and over each individual device, while protecting each user's personally identifiable information.

[0154] Furthermore, the principle described herein differs from some existing implementations of ID centers, where an ID center grants a scope of permission to a DID associated with a specific user. Each user then uses the same DID to access data across multiple devices. Additionally, such existing ID centers allow one user's DID to grant a scope or subscope to a second user's DID. The second user's DID then grants the scope or subscope to a third user's DID. In such existing ID centers, a DID needs to be revoked if one of a user's devices is misplaced or stolen. Once a DID is revoked, all users lose control of the data associated with that DID. Unlike these existing implementations, the principle described herein provides a DID for each device. If a device is lost, there is no need to revoke the scope of permission granted to the group of devices owned by the user, because scopes are granted on a device-by-device basis, not on a user-by-user basis.

[0155] The following discussion now involves many methods and method actions. Although method actions are used in a specific order in the flowchart or are illustrated as occurring in a specific order, a specific order is not required unless specifically stated otherwise, or because a specific order is required because an action depends on another action being performed before that action is performed.

[0156] Figure 10 A flowchart illustrating an example method 1000 for generating a DID and associating it with an associated device group is shown. In some embodiments, method 1000 is implemented at a device management module. In other embodiments, the method is implemented at a remote server that the device has access to. In yet another embodiment, the method is implemented at an ID center. Method 1000 includes generating a device group DID (action 1001). The device group DID is then associated with a group of devices (action 1002). Figure 6 and Figure 7 An example embodiment for generating a device group DID is illustrated.

[0157] For each device in the group, generate a device DID (Action 1003). After generating the device DID, associate the device DID with the corresponding device (Action 1004). Figure 8 The illustration shows an example embodiment for generating a device DID for each device in a group of devices. Any other embodiment or algorithm may be implemented to generate a device DID, provided that the generated device DID is generally unique.

[0158] Method 1000 also includes granting a license scope to a device group DID (Action 1005). In response to granting a license scope to a device group DID, a subset of the license scope is granted to each device DID associated with a corresponding device within the group (Action 1006). The above is about... Figure 9 An example embodiment for granting license scopes to device group DIDs and device DIDs is described.

[0159] In some embodiments, method 1000 further includes adding the device to a group (action 1007). In some embodiments, method 1000 further includes removing the device from the group (action 1008). Reference Figure 4 , Figure 5A and Figure 5B Example implementations for adding and removing devices from a group are described.

[0160] Figure 11 The diagram illustrates a flowchart of an example method 1100 for adding a device to a group, which corresponds to... Figure 10Action 1007. In some embodiments, method 1100 is implemented at a DID lifecycle management module 420 installed at each device within the group. In other embodiments, method 1100 is implemented at a DID lifecycle management module 420 installed at a newly requested device. In yet another embodiment, method 1100 is implemented at a remote service accessible to each device within the group. In still some embodiments, method 1100 is implemented at a service provider platform (e.g., an ID center) accessible to each device within the group.

[0161] Method 1100 includes receiving a request to add a new device to a group (action 1101). The request is then sent to at least one device within the group (action 1102). For example, a cloud service provider or ID center receives the request and forwards it to each device within the group. Alternatively, a user on one of the devices in the group initiates the request, and the request is then forwarded from one device in the group to every other device in the group. Alternatively, a user initiates the request using a new device, and the new device sends a request notification to at least another device in the group.

[0162] At least one device in the group approves the request. Once the at least one device approves the request, the requesting device sends a notification to the requesting device. Thus, the requesting device receives a notification from the at least one device indicating that the request has been approved (Action 1103).

[0163] Next, a new device DID (1105) is generated. Various embodiments are implemented to generate a new device DID. (The above refers to...) Figure 8 An example implementation for deriving the new device DID is discussed.

[0164] Finally, the new device DID is then associated with the new device (1106) and granted a subset of the permission scope possessed by the device group DID (at 1107). In some embodiments, the transaction of adding the new device DID is also recorded in the distributed ledger (action 1108) so that when the new device attempts to access the group data stored at ID center 911, the parser 950 can retrieve and verify the new device DID recorded at the distributed ledger.

[0165] Figure 12 The diagram illustrates a flowchart of an example method 1200 for removing a device DID from a group, which corresponds to... Figure 10Action 1008. Similar to method 1100, in some embodiments, method 1200 is implemented at the DID lifecycle management module 420 installed on each device within the group. In other embodiments, method 1200 is implemented at a remote service accessible to each device within the group. In still other embodiments, method 1200 is implemented at a service provider platform (e.g., an ID center) accessible to each device within the group.

[0166] Method 1200 includes receiving a request to remove an existing device from the group (action 1201). This request may be initiated by the device to be removed itself or by another device within the group. Once the request is initiated, it is sent to at least one other device within the group (action 1202). For example, when the device itself initiates the request, another device in the group is notified. When a device in the group requests the removal of another device within the group, the device to be removed is notified.

[0167] Once at least one other device in the group receives the request, that device approves it. Upon approval, the requesting device receives a notification from the approving device indicating that the request has been approved (Action 1203). In response to the receipt of approval, the permission scope previously granted to the device DID associated with the device to be removed is revoked (Action 1204). The device DID associated with the device to be removed is also removed from the group (Action 1205). For example, the DID document is updated to remove the device DID associated with the removed device. In some embodiments, the removal transaction is also recorded in a distributed ledger (Action 1207) so that when the removed device attempts to access the group data stored in ID center 911 again, DID resolver 950 retrieves the removal transaction from the distributed ledger and prevents the removed device from accessing the group data.

[0168] The operations performed in the processes and methods disclosed herein are implemented in different orders. Furthermore, the operations outlined are provided only as examples, and some of these operations are optional, may be combined into fewer steps and operations, may supplement other operations, or may be extended to additional operations without departing from the essence of the disclosed embodiments.

[0169] The invention is embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects as illustrative rather than limiting.

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 a method for generating and associating a decentralized identifier (DID) for a group of one or more related devices, the method comprising: generating a device group DID by generating a private key for the device group DID based on a seed and a first hardware identifier of at least one of the devices in the group and generating a device group DID document using a public key associated with the private key for the device group DID, the device group DID comprising a representation stored in a distributed ledger and pointing to the device group DID document; associating the device group DID with the group of one or more related devices; for each device of the one or more related devices, deriving a device DID by generating a private key for the device DID based on a seed and a second hardware identifier of the corresponding device and the device group DID and generating a device DID document using a public key associated with the private key for the device DID, the device DID comprising a representation stored in a distributed ledger and pointing to the device DID document; and associating the device DID with the corresponding device; granting a scope of permissions to the device group DID; and in response to granting the scope of permissions to the device group DID, granting a subset of the scope of permissions to each device DID, whereby the device group DID and each of the device DIDs are only linked to the device group or corresponding device and no personally identifiable information is directly associated with the device group DID or each device DID. adding a new device to the device group and removing a permission of an existing device from the device group, and 2. The computing system of claim 1, wherein the scope of permissions granted to the device group DID includes: at least one of the one or more device DIDs is granted a permission to add a new device to the device group or remove an existing device from the device group.

3. The computing system of claim 2, the method further comprising: receiving a request to add a new device to the group of one or more devices; verifying the new device with at least one permitted existing device within the group of devices; in response to the verification with the at least one permitted existing device, adding the new device to the group of one or more devices, adding the new device to the group of one or more devices comprising: deriving a new device DID; associating the new device DID with the new device; and granting a subset of the scope of permissions to the new device DID.

4. The computing system of claim 3, verifying the new device with at least one permitted existing device within the group of one or more devices comprising: causing the request to be sent to at least one device within the group of one or more devices; and receiving a notification from the at least one device indicating that the request is approved. ​ ​ 5. The computing system of claim 3 or claim 4, the method further comprising: recording, in a distributed ledger, a transaction associated with granting the subset of permission scopes to the new device DID.

6. The computing system of any one of claims 3-4, the method further comprising: receiving an indication to remove a particular device from the group of one or more devices; verifying the removal of the particular device with at least one existing device that is permitted within the group of devices that is not the particular device; in response to the verification with the at least one existing device that is permitted, removing the particular device from the group of one or more devices, removing the particular device comprising: revoking the permission scopes that have been granted to the device DID; and decommissioning the device DID associated with the particular device.

7. The computing system of claim 6, verifying the removal of the particular device with at least one existing device that is permitted within the group of one or more devices that is not the particular device comprising: causing the request to be sent to at least one existing device that is permitted; and receiving a notification from the at least one existing device that is permitted that the request is approved.

8. The computing system of claim 6, the method further comprising: recording, in a distributed ledger, a transaction associated with revoking the permission scopes that have been granted to the device DID.

9. The computing system of any one of claims 2-4, wherein the permission scopes comprise permission to access storage at an ID hub.

10. The computing system of claim 9, wherein the permission comprises permission to at least one of: (1) read a data set stored at the storage, (2) write a data set into the storage, (3) copy a data set stored at storage, and (4) delete a data set stored at storage.

11. The computing system of claim 10, wherein when a particular device within the group of one or more devices requests access to the data set stored at the ID hub, both the device DID corresponding to the particular device and the device group DID corresponding to the group of one or more devices are verified.

12. The computing system of any one of claims 2-4, generating a device group DID document or a device DID document comprising: receiving a pass phrase from a user; obtaining a constant value associated with the computing system; and generating the device group DID document or the device DID document using the pass phrase and the constant value as input to a hash function.

13. The computing system of claim 12, the constant value comprising one of: a BIOS serial number of the device, a motherboard serial number of the device, a MAC address of a network adapter of the device, a machine security identifier (SID) of the device. ​ ​ ​ 14. A method in a computing system implemented in a distributed network implementing a distributed ledger configured to support one or more decentralized identities (DIDs) for one or more users of the computing system, for generating and associating a decentralized identifier (DID) to a group of one or more related devices, the method comprising: generating a device group DID by generating a private key of the device group DID based on a seed and a first hardware identifier of at least one of the devices in the group and generating a device group DID document using a public key associated with the private key of the device group DID, the device group DID comprising a representation stored in the distributed ledger and pointing to the device group DID document; associating the device group DID with the group of one or more related devices; for each device of the plurality of related devices, deriving a device DID from the device group DID by generating a private key of the device DID based on a seed and a second hardware identifier of the corresponding device and the device group DID and generating a device DID document using a public key associated with the private key of the device DID, the device DID comprising a representation stored in the distributed ledger and pointing to the device DID document; associating the device DID with the corresponding device; granting a permission scope to the device group DID; and in response to granting the permission scope to the device group DID, granting a subset of the permission scope to each device DID. adding a new device to the device group and removing an existing device from the device group, 15. The method of claim 14, wherein the scope of permissions granted to the device group DID includes: at least one of the one or more device DID is granted a permission to add a new device to the device group or remove an existing device from the device group. ​

Images