Decentralized identities anchored by decentralized identifiers

Abstract

Generate a self-published statement anchored by a DID and use the self-published statement as a self-identification. The computing system generates one or more statements, each of which includes at least information related to the following: (1) the DID, (2) attributes of a subject entity, which is the owner of the DID, and (3) values ​​corresponding to the attributes. For each of the one or more statements, the computing system generates a cryptographic signature by signing the statement with a private key associated with the corresponding DID. The cryptographic signature proves that the statement is a self-published statement, which is issued by the owner of the corresponding DID and is related to the owner of the corresponding DID. A portion of the data related to the self-published statement is then propagated to the distributed ledger.

Description

Background Art

[0001] Most documents or records that prove identity in use today 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 to organize and manage the issued identities, their 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 registering people with the organization. In addition, when one party needs to verify the identity of another party, the verifying party often needs to obtain information to verify and / or authenticate the identity of the other party through a centralized identity management system.

[0002] A decentralized identifier (DID) is a new type of identifier that is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) provides an opportunity to use fully decentralized identifiers. Distributed ledger technology uses a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in one part of the distributed ledger cannot be retroactively changed without changing all subsequent parts of the distributed ledger, which provides a fairly secure platform. In such a decentralized environment, the owner of each DID typically uses his / her DID to control his / her own data. The DID owner accesses data stored in a personal storage device associated with the DID via a DID management module, which is a mobile application (e.g., a wallet application), a personal computer, a browser, etc.

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

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

[0005] In a centralized environment, a user's personal information (e.g., name, phone number, email address) is typically recorded in a centralized system's database. When two parties perform a transaction, they can typically identify the other party based on the information registered in the centralized system. For example, a social media account will automatically display a user's name or profile picture when a user tries to contact another user.

[0006] Unlike centralized environments, decentralized environments are maintained on distributed ledgers. In such decentralized environments, users can use decentralized identifiers (DIDs) to perform various transactions. However, DIDs are usually unintelligible sequences of numbers and / or letters that do not contain personally identifiable information. For example, on some platforms, users generate keys using wallets, and the keys are used to perform transactions. The transactions are then recorded on the distributed ledger. Since the keys do not contain personally identifiable information, it is difficult to link any particular transaction to a specific person. Therefore, any two parties to a transaction often do not know and cannot find out who the other party is. However, many users of decentralized platforms want to know who they are dealing with, and these users do not mind providing each other with some of their own personal information as long as the information is kept confidential within the parties involved.

[0007] The embodiments described herein relate to decentralized identification anchored by a decentralized identifier (DID), which allows users to securely identify themselves to dependent entities and allows dependent entities to verify identification via data and cryptographic signatures propagated to distributed ledgers. Some embodiments described herein may be implemented at a computing system associated with a principal entity, the principal entity is the owner of the DID, and the computing system is such as a management module (e.g., wallet), user agent, and / or ID center of the principal entity. Some embodiments described herein are implemented at a computing system associated with a dependent entity. When the dependent entity is also the owner of the DID, the computing system may be a management module (e.g., wallet), user agent, and / or ID center of the dependent entity. In the following, a computing system associated with a principal entity (including a management module, wallet, user agent, and / or ID center) is also referred to as a computing system of the principal entity; and a computing system associated with a dependent entity (including a management module, wallet, user agent, and / or ID center) is also referred to as a computing system of a dependent entity. In many cases, when two entities communicate with each other, mutual identification is performed. In this case, each of these entities is both a dependent entity and a principal entity.

[0008] In particular, the computing system of the subject entity is configured to generate one or more statements, each of which includes at least information related to the following (1) DID, (2) attributes of the subject entity, the subject entity being the owner of the DID, and (3) values ​​corresponding to the attributes. The statement is then signed with a private key associated with the corresponding DID to generate a cryptographic signature. The cryptographic signature proves that the statement was issued by the owner of the corresponding DID. Since the statement is issued by the subject entity and is about the subject entity, the statement is called a self-issued statement. A portion of the data related to the self-issued statement is then propagated to the distributed ledger.

[0009] In some cases, a computing system of a subject entity generates one or more self-published statements based on a user instruction. For example, the computing system receives a user instruction from an owner of a DID to generate a self-published statement. The user instruction includes at least specifying (1) a decentralized identifier, (2) an attribute of the owner of the DID, and (3) a value of the attribute. The computing system generates the self-published statement based on the user instruction.

[0010] In some embodiments, the computing system also records at least one self-published statement and additional related data as metadata. The additional related data includes, but is not limited to, (1) a unique identifier that identifies the corresponding self-published statement, (2) one or more conditions for accessing the self-published statement, or (3) one or more revocation mechanisms for revoking the corresponding self-published statement. The one or more conditions for accessing the self-published statement include, but are not limited to, (1) requiring the relying entity to provide identification information, (2) requiring the relying entity to provide one or more verifiable statements, (3) requiring the relying entity to grant permission to access a portion of the data, and / or (4) requiring the relying entity to provide a specific service.

[0011] The one or more revocation mechanisms include, but are not limited to, (1) an expiration time of the corresponding self-published statement, (2) a predetermined number of times the corresponding self-published statement can be accessed, (3) an automatic revocation mechanism that automatically revokes the statement in response to changes in data contained in the DID document of the corresponding DID or personal data of the subject entity, and / or (4) a manual revocation mechanism that allows the subject entity to manually revoke the self-published statement.

[0012] In some cases, the computing system receives a request from a relying entity for self-identification of the owner of the DID. In response to the request, the computing system selects at least one self-published statement of the subject entity and generates identification data including the at least one self-published statement. The generated identification data is then sent to the relying entity. Upon receiving the identification data, the relying entity is caused to verify the identification data via data associated with the at least one self-published statement propagated to the distributed ledger.

[0013] In some embodiments, the computing system generates a self-published statement based on a request from a dependent entity. For example, the request from the dependent entity includes a request for a value of a specific attribute of the owner of the DID. In response to the request, the computing system accesses the personal data of the subject entity or the DID document of the DID to obtain the value of the specific attribute of the subject entity. The computing system then generates a self-published statement including the value of the acquired specific attribute, and generates identification data including the self-published statement.

[0014] In some embodiments, the computing system also receives a public key of the relying entity and further encrypts the identification data using the public key of the relying entity. The encrypted identification data is then sent to the relying entity, so that the data contained in the self-published statement of the principal entity is further protected and can only be accessed by the relying entity.

[0015] In some embodiments, a computing system maps multiple self-published statements to multiple dependent entities. The mapping between the multiple self-published statements and the multiple dependent entities is recorded as mapping data. In response to receiving a request for self-identification from a specific dependent entity, the computing system accesses the mapping data to obtain one or more self-published statements mapped to the specific dependent entity, and generates identification data including the one or more self-published statements. In some cases, the mapping data is manually input and / or updated by user input. For example, the computing system receives user input from a subject entity to generate or update mapping data. The user input indicates that one or more specific self-published statements are mapped to one or more specific dependent entities. The computing system then updates the mapping data based on the user input.

[0016] In some cases, in response to receiving a request for self-identification from a dependent entity, the computing system further determines whether metadata associated with at least one declaration includes one or more conditions and whether the one or more conditions are satisfied. In response to determining that the one or more conditions are satisfied, the computing system generates identification data. On the other hand, in response to determining that the one or more conditions are not satisfied, the computing system rejects the request from the dependent entity and generates a notification to notify the subject entity.

[0017] In some embodiments, in response to a change in the value of a property associated with a self-published statement, the computing system revokes the self-published statement including the value of the property or updates the self-published statement with the changed value of the property.

[0018] As described above, on the other hand, some embodiments described herein are implemented at a computing system of a dependent entity. The computing system of the dependent entity is configured to send a request for self-identification to a device of a subject entity, the subject entity being the owner of the DID. The computing system of the dependent entity then receives identification data from the subject entity. The identification data includes at least one self-published statement, the at least one self-published statement including a cryptographic signature proving that the subject entity is the publisher of the self-published statement. The computing system of the dependent entity extracts at least one self-published statement from the identification data and decrypts the cryptographic signature with a public key associated with the DID of the subject entity. The computing system of the dependent entity also obtains data related to at least one self-published statement from a distributed ledger, and verifies the decrypted cryptographic signature based on the data obtained from the distributed ledger.

[0019] In some cases, a public key associated with the DID is propagated to a distributed ledger. In this case, the computing system of the relying entity obtains the public key from the distributed ledger. Alternatively or additionally, a hash of the public key or a hash of at least one self-published statement is propagated to the distributed ledger. In this case, the computing system receives the public key associated with the DID from a device of the subject entity. The computing system also obtains the hash of the public key or the hash of at least one self-published statement from the distributed ledger and verifies the self-published statement based on the hash of the public key or the hash of at least one self-published statement.

[0020] In some cases, the computing system of the relying entity also sends its own public key to the device of the principal entity and causes the device of the principal entity to encrypt the identification data with the public key of the relying entity. In response to receiving the encrypted identification data, the computing system decrypts the encrypted identification data using its own private key corresponding to the public key.

[0021] In some cases, the computing system of the relying entity further determines that at least one of the self-published statements includes one or more conditions. In response to verifying the self-published statement, the computing system performs an action to satisfy the one or more conditions. The one or more conditions include, but are not limited to: (1) requiring the relying entity to provide identification information of the user, (2) requiring the relying entity to provide one or more verifiable statements of the user, (3) requiring the relying entity to grant permission to access a portion of the access data, and / or (4) requiring the relying entity to provide a specific service.

[0022] Thus, the claimed embodiments allow entities to securely self-identify themselves to each other, and also allow entities to verify the self-identification data of other entities. Furthermore, the self-identification data is presented only to the intended dependent entities as needed, so that the privacy of the user is protected not only from unrelated entities, but also from centralized service providers.

[0023] Additional features and advantages will be set forth in the following description, and in part will be apparent from the description, or may be learned through the practice of the teachings herein. The features and advantages of the present invention may be realized and obtained through the tools and combinations particularly pointed out in the appended claims. The features of the present invention will become more apparent from the following description and the appended claims, or may be learned through the practice of the present invention as described below. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0028] Figure 4 An example decentralized personal storage or identity center is shown;

[0029] Figure 5 An example environment is shown in which the principles described herein are implemented;

[0030] Fig. 6A An example declaration is shown;

[0031] Figure 6B An example self-release statement is shown;

[0032] Fig. 7A An example user interface for a management module that receives user input for generating a self-publishing statement is shown;

[0033] Figure 7B An example user interface of a management module is shown that receives mapping data for updating mapping of one or more dependent entities to one or more self-published declarations;

[0034] Figure 8 An example data structure of mapping data that maps one or more dependent entities to one or more self-published declarations is shown;

[0035] Fig. 9 An example communication pattern between a principal entity and a dependent entity for requesting and verifying self-identification data is shown;

[0036] Fig. 10A An example request for self-identification of a dependent entity for a principal entity is shown;

[0037] Fig. 10B An example response including identification data of a subject entity is shown;

[0038] Fig.11 A flowchart illustrating an example method for generating one or more self-publishing statements;

[0039] Fig.12 A flowchart illustrating an example method for generating and sending, by a computing system of a subject entity, identification data including one or more self-issued statements; and

[0040] Fig.13 A flow chart of an example method for receiving and verifying identification data by a computing system of a relying entity is shown. DETAILED DESCRIPTION

[0041] Embodiments described herein relate to decentralized identities anchored by decentralized identifiers (DIDs) that allow users to securely identify themselves to relying entities and allow relying entities to verify identities via cryptographic signatures and data propagated to distributed ledgers. Some embodiments described herein are implemented at a computing system of a principal entity. Some embodiments described herein are implemented at a computing system of a relying entity.

[0042] Because the principles described herein are implemented in the context of a computing system, reference will be made to Figure 1 Some introductory discussion describing the computing system.Then, the description will return to the principles of the DID platform with reference to the remaining figures.

[0043] Computing systems now increasingly take a variety of forms. For example, a computing system may be a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device that is not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include: any device or system (or combination thereof) including at least one processor that is physical and tangible, and a physical and tangible memory on which computer executable instructions executed by the processor can be located. The memory takes any form and depends on the nature and form of the computing system. The computing system is distributed in a network environment and includes multiple constituent computing systems.

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

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

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

[0047] The term "executable component" is also well understood by those of ordinary skill to include structures that are implemented exclusively or almost exclusively in hardware, such as hard-coded or hard-wired logic gates, such as field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any other special circuit structures. Therefore, whether implemented in software, hardware, or a combination thereof, the term "executable component" is a term for a structure that is well understood by those of ordinary skill in the field of computing. In this specification, the terms "component", "agent", "manager", "service", "engine", "module", "virtual machine", etc. are also used. As used in this specification and the case, these terms (whether or not with modified terms) are also intended to be synonymous with the term "executable component", and therefore also have structures that are well known to those of ordinary skill in the field of computing.

[0048] 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 relevant computing system performing the actions) direct the operation of the computing system in response to having executed the computer executable instructions constituting the executable components. For example, such computer executable instructions are embodied on one or more computer readable media forming a computer program product. Examples of such operations involve operations on data. If these actions are implemented only or almost only in hardware, such as in an FPGA or ASIC, the computer executable instructions are hard-coded or hard-wired logic gates. The computer executable instructions (and processed data) are stored in a memory 104 of the computing system 100. The computing system 100 also includes a communication channel 108 that allows the computing system 100 to communicate with other computing systems via, for example, a network 110.

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

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

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

[0052] A "network" is defined as one or more data links capable of transmitting electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computing system appropriately treats the connection as a transmission medium. The transmission medium may include a network and / or a data link, which may be used to carry the required program code means in the form of computer executable instructions or data structures and may be accessed by a general or special computing system. Combinations of the above should also be included within the scope of computer-readable media.

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

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

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

[0056] Those skilled in the art will appreciate that the present invention is implemented in a network computing environment with various types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (e.g., glasses), etc. In some cases, the present invention is also practiced in a distributed system environment, where local and remote computing systems are linked via a network (via a hardwired data link, a wireless data link, or a combination of a hardwired and wireless data link), both of which perform tasks. In a distributed system environment, program modules are located in local and remote memory storage devices.

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

[0058] The remaining figures discuss various computing systems corresponding to the computing system 100 described previously. The computing systems of the remaining figures include various components or functional blocks that implement various embodiments disclosed herein as will be explained. The various components or functional blocks are implemented on a local computing system or on a distributed computing system, which includes elements residing in the cloud or elements that implement various aspects of cloud computing. The various components or functional blocks are implemented as software, hardware, or a combination of software and hardware. The computing systems in the remaining figures include more or fewer components than shown in the figures, and certain components are combined when circumstances permit. Although not necessarily shown, 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.

[0059] Some introductory discussion about decentralized identities (DIDs) and the environments in which they are created and reside will not be referenced Figure 2 Given. Figure 2 As shown, DID owner 201 owns or controls DID 205 that represents the identity of DID owner 201. DID owner 201 registers a DID using a creation and registration service, which will be explained in more detail below.

[0060] DID owner 201 is any entity that can benefit from a DID. For example, DID owner 201 is a human or an organization of humans. Such an organization may include a company, department, government, institution, or any other organization or group of organizations. Each person may have a DID, and the organization(s) to which each person belongs may also have a DID.

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

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

[0063] As mentioned, DID owner 201 creates and registers DID 205. DID 205 is any identifier associated with DID owner 201. Preferably, the identifier is unique to the DID owner 201, at least in the scope in which the DID is expected to be used. As an example, the identifier is a locally unique identifier, and may be more ideally a globally unique identifier for an identity system that is expected to operate globally. In some embodiments, DID 205 is a uniform resource identifier (URI) (such as a uniform resource locator (URL)) or other pointer that associates DID owner 201 with a mechanism for participating in a trusted interaction with DID owner 1001.

[0064] DID 205 is "decentralized" because it does not require a centralized third-party management system to generate, manage, or use. Therefore, DID 205 remains under the control of DID owner 201. This is different from traditional centralized IDs, which are based on trust in centralized institutions and are under the control of corporate directory services, certificate authorities, domain name registries, or other centralized institutions (collectively referred to as "centralized institutions" in this article). Therefore, DID 205 is any identifier that is under the control of DID owner 201 and independent of any centralized institution.

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

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

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

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

[0069] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 is used by third-party entities to which DID owner 201 gives permission to access information and data owned by DID owner 201. Public key 207 can also be used by verifying that DID owner 201 actually owns or controls DID 205.

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

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

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

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

[0074] The DID document 210 also includes identification information 214. The identification information 214 includes personally identifiable information, such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Therefore, the identification information 214 listed in the DID document 210 represents different roles of the DID owner 201 for different purposes. For example, the roles are pseudo-anonymous, for example, when identifying the DID owner 201 as the author of an article published on a blog, he or she can include a pseudonym in the DID document; the roles are completely anonymous, for example, the DID owner 201 only wants to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.) in the DID document without disclosing his or her name; and the roles are specific to the DID owner 201 as an individual, for example, the DID owner 201 includes information identifying him or her as a volunteer of a specific charity organization, an employee of a specific company, a winner of a specific award, etc.

[0075] DID document 210 also includes credential information 215, which is also referred to herein as proof. Credential information 215 is any information associated with the background of DID owner 201. For example, credential information 215 is (but is not limited to) qualifications, achievements, government IDs, government rights such as passports or driver's licenses, digital asset providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of DID owner 201.

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

[0077] Figure 2 Also shown is a distributed ledger or blockchain 220. Distributed ledger 220 is any decentralized, distributed network that includes various computing systems that communicate 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 represented by ellipsis 260. Distributed ledger or blockchain 220 operates according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers corresponding to distributed ledger or blockchain 220 include, but are not limited to, virtual resources.

[0078] 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 store (not shown) associated with distributed ledger or blockchain 220.

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

[0080] In one embodiment, when DID owner 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger or blockchain 220. Distributed ledger or blockchain 220 thus records that DID 205 now exists. Because distributed ledger or blockchain 220 is decentralized, DID 205 is not controlled by any entity other than DID owner 201. In addition to a pointer to DID document 210, DID hash 231, DID hash 241, DID hash 251 also include a record or timestamp specifying when DID 205 was created. Subsequently, when DID document 210 is modified, this is also recorded in DID hash 231, DID hash 241, and DID hash 251. 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 .

[0081] Already referenced Figure 2 Having described DIDs and how they generally operate, specific embodiments of DIDs will now be explained. Figure 3 , the environment 300 will now be explained, which is used to perform various DID lifecycle management operations and services. It should be understood that for ease of explanation, Figure 3 The environment needs to refer to the Figure 2 elements.

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

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

[0084] like Figure 3 As shown, DID lifecycle management module 320 includes DID creation module 330. DID creation module 330 is used by DID owner 201 to create DID 205 or any number of additional DIDs, such as DID 331. In one embodiment, DID creation module includes or otherwise accesses user interface (UI) elements 335 that guide DID owner 201 to create DID 205. DID creation module 330 has one or more drivers that are configured to work with a specific distributed ledger, such as distributed ledger 220, so that DID 205 conforms to the underlying methods of the distributed ledger.

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

[0086] The DID creation module also includes a key generation module 350. The key generation module generates the previously described private key 206 and public key 207 pair. The DID creation module 330 then generates a DID document 210 using the DID 205 and the private and public key pair.

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

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

[0089] As previously discussed, the key generation module 350 generates a private key 206 and a public key 207 pair, and then records the public key 207 in the DID document 210. The public key 207 is therefore used by all devices associated with the DID owner 201 and all third parties that wish to provide services to the DID owner 201. Thus, when the DID owner 201 wishes to associate a new device with the DID 205, the DID owner 201 executes the DID creation module 330 on the new device. The DID creation module 330 then uses the registrar 310 to update the DID document 210 to reflect that the new device is now associated with the DID 205, and as previously discussed, this will be reflected in the updated transaction on the distributed ledger 220.

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

[0091] In those embodiments where the additional public keys 208 and 209 are associated with different devices, the additional public keys 208 and 209 are recorded in the DID document 210 as being associated with those devices. Figure 3 It should be understood that except Figure 3 In addition to the information shown in Figure 2 If the DID document 210 already exists before the device-specific public key is generated, the creation module 330 will update the DID document 210 via the registrar 310, and this will be reflected in the updated transaction on the distributed ledger 220.

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

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

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

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

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

[0097] Figure 4 An embodiment of an environment 400 is shown in which a DID such as DID 205 is used. Specifically, environment 400 will be used to describe the use of DID 205 in connection with one or more decentralized personal storage or identity centers. An identity center is a storage device for characteristics, including keys and metadata under the control of the holder of the DID. It should be noted that Figure 4 Including first about Figure 2 or Figure 3 Reference to the elements discussed therefore uses the same reference numerals for ease of explanation.

[0098] In one embodiment, identity centers 410 are multiple instances of the same identity center. This is represented by line 410A. Therefore, various identity centers 410 include at least some of the same data and services. Therefore, if any changes are made to one of identity centers 410, the changes are reflected in the remaining identity centers. For example, first identity center 411 and second identity center 412 are implemented in cloud storage and are therefore able to save a large amount of data. Therefore, a complete set of data is stored in these identity centers. However, identity centers 412 and 413 have less storage space. Therefore, in these identity centers, descriptors of the data stored in the first and second identity centers are included. Alternatively, a record of changes made to the data in other identity centers is included. Therefore, changes in one of identity centers 410 are fully replicated in other identity centers, or at least a record or descriptor of the data is recorded in other identity centers.

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

[0100] In one embodiment, the stored data has different authentication and privacy settings 421 associated with the stored data. For example, a first subset of data has a setting 421 that allows the data to be made public, but does not include any authentication of the DID owner 201. This type of data is used for relatively unimportant data, such as color schemes, etc. A second subset of data has a setting 421 that allows the data to be made public and includes authentication of the DID owner 201. A third subset of data has a setting 421 that encrypts a subset of the data using a private key 206, and a public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data will require a party to have access to the public key 207 (or some other associated public key) to decrypt the data. This process also includes authentication of the DID owner 201. A fourth subset of data has a setting 421 that restricts the data to a subset of third parties. This requires the use of a public key associated with the subset of third parties to decrypt the data. For example, the DID owner 201 has the setting 421 specify that only a public key associated with a friend of the DID owner 201 decrypts the data. .

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

[0102] Identity center 411 also includes a message service module 440. In operation, the message service module allows the identity center to receive requests such as from various parties (such as third parties 401 and 402) to access the data and services of the identity center. In addition, the message service module 440 allows the identity center 411 to respond to messages from third parties and also communicate with the DID resolver 450. This will be explained in more detail later. The ellipsis 416 indicates that the identity center 411 can have additional services when the situation permits.

[0103] In one embodiment, the DID owner 201 wishes to authenticate the new device 301 using the identity center 411 that is already associated with the DID 205 in the manner previously described. Therefore, the DID owner 201 uses the DID management module 320 associated with the new user device 301 to send a message to the identity center 411, which asserts that the new user device is associated with the DID 205 of the DID owner 201.

[0104] However, identity center 411 does not initially recognize the new device as owned by DID owner 201. Therefore, identity center 411 contacts DID resolver 450 using messaging service module 440. The message sent to DID resolver 450 includes DID 205.

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

[0106] As previously described, the DID document 210 includes a public key 208 or 209 associated with the new user device 301. In order to verify that the new user device is owned by the DID owner 201, the identity center 411 uses the message service module 440 to provide a cryptographic challenge to the new user device 301. The cryptographic challenge will be constructed so that only devices with access to the private key 206 will be able to successfully answer the challenge.

[0107] In an embodiment, the challenge is answered successfully because the new user device is owned by DID owner 201 and thus has access to private key 206. Identity center 411 then records in permission 430 that the new user device 301 can access the data and services of identity center 411 and the rest of identity center 410.

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

[0109] In another example embodiment, DID owner 201 provides DID 205 to third-party entity 401, enabling the third party to access data or services stored on identity center 411. For example, DID owner 201 is a human attending a scientific conference who wishes to allow third party 401, also a human, to access his or her research data. Therefore, DID owner 201 provides DID 205 to third party 401.

[0110] Once third party 401 has access to DID 205, he or she accesses DID resolver 450 to access DID document 210. As previously described, DID document 210 includes endpoint 213, which is an address or pointer to identity center 411. The third party then uses the address or pointer to access identity center 411.

[0111] Third party 401 sends a message to message service module 440 to request permission to access the research data. Message service module 440 then sends a message to DID owner 201 asking whether third party 401 should be given access to the research data. Because the DID owner wishes to provide access to the data, DID owner 201 allows third party 401 permission and the permission is recorded in permission 430.

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

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

[0114] As briefly discussed above, the identity center 411 is hosted in a cloud service. Service providers can access data stored in each user's identity center 411. In addition, service providers can also access certain activities of DID owners. For example, entities with which the DID owner shares his / her data are stored in the identity center 411. As another example, a user has multiple DIDs and shares data between multiple DIDs, alternatively, the user uses different DID management modules to access the same data. Based on the data sharing activities, the service provider of the identity center 411 associates the relationships of different DIDs and finds that two DIDs are related or owned by the same owner. Therefore, the user's privacy is compromised.

[0115] The principles described herein will address these potential privacy issues for DID owners by encrypting personal data stored in the identity center 411. The identity center 411 does not store or have access to encryption / decryption keys, so DID owners not only have great control over their data from other DID owners or users, but also have their privacy protected from service providers.

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

[0117] In another example embodiment, a verifiable statement is issued and stored at the identity center 411. For example, a verifiable statement associated with the DID owner 201 is issued by a statement issuing entity, and the issued verifiable statement is stored in the identity center 411 associated with the DID owner 201. When another entity needs to verify the credentials of the DID owner, the DID owner 201 sends the verifiable statement to the other entity. For example, the DID owner 201 is a person holding a driver's license, and the statement issuing entity is the DMV that has issued the DID owner's driver's license. The DMV issues a verifiable statement that verifies that the DID owner 201 holds a valid driver's license. The DID owner 201 stores the verifiable statement in the identity center 411. The other entity is a car rental company, which requires the DID owner 201 to prove that he / she has a valid driver's license. The DID owner then sends the verifiable statement stored in the identity center 411 to the car rental company.

[0118] Already referenced Figures 2 to 4 Having described DIDs and how they generally operate, specific embodiments of decentralized identification will now be explained. Figure 5 , a decentralized environment 500 will now be explained that allows a DID owner to access services and perform transactions with other DID owners while identifying themselves. It should be understood that for ease of explanation, Figure 5 Reference as needed Figures 2 to 4 Components in .

[0119] like Figure 5 As shown, decentralized environment 500 includes a device associated with service provider 510, and wallet applications 521 and 522 of users 520 and 530 (e.g., DID owners). Ellipsis 540 indicates that there may be any number of devices associated with any number of service providers and / or users in decentralized environment 500. Each of the (multiple) service providers and users 520, 530 corresponds to Figure 2 DID owner 201. Wallet application 521 or 531 corresponds to Figure 3 DID management module 320. ID center 522 or ID center 532 corresponds to Figure 4 ID Center 411.

[0120] User 520 uses wallet application 521 to manage his / her DID, and user 520 uses wallet application 531 to manage his / her DID. Wallet application 521 or 531 is connected to the corresponding ID center 522 or 531. Each of the service provider's device 510 and wallet applications 521, 531 can access the distributed ledger via a computer network 550. In some embodiments, wallet application 521 or 531 indirectly accesses the distributed ledger via ID center 522 or 532. In some embodiments, wallet application 521 or 531 is configured to store a complete copy of the distributed ledger, or directly access the distributed ledger 550 via a computer network.

[0121] The device of the service provider 510 and each wallet application 521, 531 and / or the ID center 522, 532 can communicate with each other through various communication channels, including but not limited to a local area network, a wide area network, a BLE beacon signal and / or a near field communication (NFC). Communication can also be performed by generating a barcode or QR code by one wallet application 521 and scanning the barcode or QR code by another wallet application 531 or a device of the service provider 510. The barcode or QR code includes identification information related to the user 520, such as a DID associated with the user 520.

[0122] In some embodiments, user 520 may request access to services provided by service provider 510 through wallet application 521. In the request, wallet application 321 may or may not include the user's identification information. When the request does not include the user's identification information, service 510 may request the user's wallet application 521 to provide such information. Wallet application 521 will then send the user's DID and / or additional identification data (e.g., self-publishing statement) to service provider 510.

[0123] In some embodiments, in order to further verify that the user is the real owner of the DID or the device on which the wallet application 521 is installed, the wallet application 521 also requires the user to enter some input to prove that the user is the real owner of the device. For example, in some cases, the user needs to enter a device password and / or biometric data (including but not limited to fingerprint and iris scan) before the wallet application 521 generates identification data. Once the service 510 receives the DID and identification data, the service 510 then obtains relevant data related to the DID from the distributed ledger and uses the obtained data to verify the identification data received from the wallet application 521.

[0124] A similar process may also occur between two users' wallet applications 521, 522 to allow two users 520 and 530 to communicate or transact with each other. For example, a communication or transaction may be initiated by wallet application 521 and transmitted to wallet application 531. When wallet application 531 receives the DID of user 520, wallet application 531 generates and sends a self-identification request to wallet application 521. After receiving the self-identification request, wallet application 521 then generates its identification data and sends it to wallet application 531. Wallet application 531 then determines the validity of the identification data based on the data propagated on the distributed ledger.

[0125] The identification data includes one or more self-published statements. A statement is typically a statement about a subject (e.g., the owner of a DID). In some embodiments, a statement is expressed using attribute-value pairs. Fig. 6A An example data structure representing a statement 610 is shown. Statement 610 includes a subject 611, an attribute 612, and a value 613. For example, subject 611 corresponds to the owner of the DID, and the DID is recorded as subject 611. Attribute 612 can be any attribute of the owner of the DID, such as name, phone number, email address, etc. Value 613 is the value of the corresponding attribute 612. For example, when the attribute is "name", the value will be the name of the DID owner, such as John Doe; when the attribute is "phone number", the value will be the phone number of the DID owner, such as 1-800-123-4567.

[0126] Since a declaration is merely a statement, an entity can present any statement to any relying entity. When an entity merely presents a declaration, the relying entity also has no proof that the statement was issued by the principal entity, and therefore the relying entity cannot hold the principal entity responsible for the presented statement. This problem is solved by attaching the principal entity's cryptographic signature to the declaration. When a declaration is signed by the principal entity's private key, the declaration becomes a "self-issued declaration" because the signature proves that the statement was issued by the principal entity.

[0127] Figure 6B An example data structure of a self-published statement 600B is shown. The self-published statement 600B includes a statement 610 corresponding to Fig. 6AThe self-published statement 600B also includes a signature 630, which is generated by signing the statement 610 with the private key (e.g., DID) of the subject entity. Once the self-published statement is generated, at least a portion of the data related to the self-published statement is propagated to the distributed ledger so that the relying entity can verify the self-published statement using the portion of the data propagated to the distributed ledger. In some embodiments, a public key corresponding to the private key of the subject entity is propagated to the distributed ledger. In some embodiments, a hash of the public key or a hash of the self-published statement is propagated to the distributed ledger.

[0128] In some embodiments, the self-published statement 600B also includes various metadata related to the self-published statement 600B. For example, the metadata includes, but is not limited to: (1) a unique identifier that identifies the corresponding self-published statement 621, (2) one or more conditions 622 for accessing the self-published statement, or (3) one or more revocation mechanisms 623 for revoking the corresponding self-published statement.

[0129] The one or more conditions 622 for accessing the self-published statement include, but are not limited to (1) requiring the relying entity to provide identification information, (2) requiring the relying entity to provide one or more verifiable statements, (3) requiring the relying entity to grant permission for accessing a portion of the data, and / or (4) requiring the relying entity to provide a specific service. The one or more revocation mechanisms 623 include, but are not limited to (1) an expiration time of the corresponding self-published statement, (2) a predetermined number of times the corresponding self-published statement can be accessed, (3) an automatic revocation mechanism that automatically revokes the statement in response to a change in the data contained in the DID document of the corresponding DID or the personal data of the subject entity, or (4) a manual revocation mechanism that allows the subject entity to manually revoke the self-published statement.

[0130] As described above, the computing system of the subject entity is configured to generate and store self-published statements. In some embodiments, the computing system of the subject entity is configured to obtain personal data from the DID document of the DID or personal data associated with the subject entity, and use the obtained data to automatically generate a self-published statement.

[0131] In some embodiments, the computing system receives user input and generates a self-publishing statement based on the user input. Fig. 7A An example user interface 700A of the management module of the principal entity is shown, which allows the user (owner of the DID) to manually generate a self-publishing statement. Fig. 7AAs shown, user interface 700A includes a selection menu 710A that allows the user to select a DID from a list of DIDs owned by the user. User interface 700A also includes an attribute menu 720A and a value menu 730A, which allow the user to select or enter an attribute-value pair. Once the user clicks the "Generate Self-Published Statement" button 740A, the selected or entered DID and attribute-value pair will be recorded in the self-published statement and signed by the private key of the selected DID.

[0132] When the computing system receives a request for self-identification from a dependent entity, the computing system selects one or more self-published statements and sends the selected one or more self-published statements to the dependent entity. In some embodiments, the selection is based on the request received from the dependent entity. Alternatively, the selection is based on user input immediately upon receiving the request.

[0133] In yet other embodiments, multiple self-published statements are mapped to multiple dependent entities, such that when a request is received from a particular dependent entity, the computing system automatically obtains the mapped one or more self-published statements and generates identification data, the identification data including the one or more self-published statements mapped to the dependent entity. Such mapping can be performed automatically by the computing system. Alternatively or additionally, the mapping can be manually input and / or updated by a user.

[0134] Figure 7B An example user interface 700B of the management module is shown, which allows a user to manually map one or more self-published declarations to one or more dependent entities. Figure 7B As shown, user interface 700B includes a dependent entity menu 710B, which allows the user to select and / or manually enter one or more dependent entities. When the dependent entity is also the owner of the DID, the DID of the dependent entity will be listed. User interface 700B also includes a self-published statement menu 720B, which allows the user to select one or more existing self-published statements or generate new self-published statements. Once the user clicks the confirmation button 730B, the selected / input dependent entities and self-published statements are mapped to each other. The mapped dependent entities and self-published statements are then recorded in the mapping data.

[0135] Figure 8An example data structure 800 of mapping data is shown. Data structure 800 includes table 810, which records dependent entities and corresponding subject entities and records their mapped statements via unique identifiers of corresponding statements. Data structure 800 also includes table 820, which records further details of each statement, including statement ID, DID, attributes and values. The statements recorded in table 820 are mapped to table 810. For example, when a computing system receives a request from a specific dependent entity (such as, DID J), the computing system obtains the statement ID (e.g., "A1" and "A2") from table 810, and the computing system then generates identification data based on the obtained statement ID, which includes the self-published statement recorded in table 820. For example, a statement with identifier "A1" includes the name of the subject entity, and a statement with identifier "A2" includes the email of the subject entity. Therefore, the identification data will include a self-published statement containing the name and email address of the subject entity.

[0136] Tables 810 and 820 are merely example data structures for recording mapping data. For example, in some embodiments, a single table may be used to record mapping data. Alternatively or additionally, additional data (e.g., conditions or revocation mechanisms) may also be recorded in each table 810 or 820.

[0137] Fig. 9 900 illustrates an example communication pattern that may occur between a subject entity's device(s) 910 and a dependent entity's device(s) 930 when a dependent entity 931 requests self-identification of a subject entity 911. The subject entity's device(s) 910 include one or more computing systems of the subject entity 911. The dependent entity's device(s) 930 include one or more computing systems of the dependent entity 931. Fig. 9 As shown, the principal entity 911 is the owner of the DID. The principal entity 911 uses various devices 910 to manage the DID. In many cases, the principal entity 911 may first initiate a request for a service or data. The computing system of the principal entity 910 then sends the request to the (multiple) devices 930 of the dependent entity, represented by arrow 921. Receiving the request from the computing system of the principal entity 910, the computing system of the dependent entity 930 wants to know who the requester is. Therefore, the computing system of the dependent entity 930 sends a request for self-identification to the device 910 of the principal entity, represented by arrow 922. In some embodiments, the request indicates what information the dependent entity wants to know, for example, name, email address, etc.

[0138] Upon receiving the request for self-identification, the computing system of the principal entity 910 then selects one or more self-published statements and generates identification data (including one or more self-published statements), represented by arrow 923. In some embodiments, the identification data or self-published statements also include one or more conditions. For example, a condition may repeat the request for a service or data and require the relying entity to provide the requested service or data when accessing valid identification data.

[0139] In some embodiments, one or more self-published claims are selected based on the request of the dependent entity. For example, when the request of the dependent entity indicates that a name and an email address are required, the computing system of the principal entity selects a name claim and an email address claim. In some embodiments, a device of the principal entity accesses mapping data that maps multiple dependent entities to multiple self-published claims. For example, Figure 8 An example data structure of mapping data is shown. In this case, the computing system of subject entity 910 selects one or more self-published statements based on the mapping data.

[0140] After generating the identification data, the computing system of the principal entity 910 sends it to the device 930 of the dependent entity, as represented by arrow 924. Upon receiving the identification data from the computing system of the principal entity, the device 930 of the dependent entity verifies the received identification data, as represented by arrow 925. The verification process includes at least extracting one or more self-issued statements from the received identification data, decrypting the signature of each of the one or more self-issued statements, and verifying the decrypted signature based on the data propagated on the distributed ledger 940. In response to the result of the verification, the device 930 of the dependent entity then provides or denies the requested service or data, as represented by arrow 926.

[0141] Various data structures may be used to send a request for self-identification and / or identification data. Fig. 10A An example request 1000A for self-identification is shown, and Fig. 10B An example response 1000B presenting identification data is shown. Each of the request 1000A and the response 100B is written in the JavaScript Object Notation (JSON) Web Token format, also known as JWT. Other structured languages ​​or data structures may also be implemented to achieve the same purpose of requesting self-identification and / or presenting identification data.

[0142] refer to Fig. 10A, the request token 1000A includes data 1010A and 1020A indicating the issuer of the token and the time when the token was issued. The request token 1000A also includes data 1030A indicating the requested identity. Here, the requested identity includes a self-publishing statement presenting the name of the principal entity 1031A and a self-publishing statement presenting the email of the principal entity 1032A.

[0143] The request token 1000A also includes a callback address "https: / / service.microsoft.com / ABCDEFGHIJK" 1040A, which is a URL indicating where the computing system of the principal entity needs to send its response. Finally, there is an expiration time 1050A, which indicates the expiration time of the request token 1000A, so the DID owner must respond to the request token 1000A before the expiration time. The ellipsis 1060A indicates that the request token 1000A may also include additional data related to the token issuer, the DID owner, or (multiple) identification mechanisms.

[0144] Fig. 10B An example response token 1000B is shown that presents identification data including a self-publishing statement to a relying entity. Response token 1000B also includes data 1010B indicating the time when token 1000B was published. Response token 1000B also includes data 1020B indicating the expiration time of token 1000B. In addition, response token 1000B also includes statement 1030B and corresponding proof 1040A. Statement 1030B provides the name of the subject entity (i.e., the owner of DID 12356789), and proof 1040B includes a cryptographic signature 1041A signed by the private key of DID 123456789 to prove that statement 1030B was issued by the owner of DID 123456789. Similarly, response token 1000B also includes statement 1050B and corresponding proof 1060B. Claim 1050B provides the email address of the principal entity (i.e., the owner of DID 123456789), and proof 1060B also includes a cryptographic signature signed by the private key of DID 123456789. Response token 1000B is merely an example format identification data for presentation. Various other formats and / or syntaxes may be implemented. For example, it is not necessary for each claim to include a separate signature. For example, in some embodiments, a single proof may be generated to prove more than one claim. Each claim may also include multiple attribute-value pairs.

[0145] The following discussion now involves a number of methods and method acts that can be performed. Although method acts may be discussed in a particular order or illustrated in a flowchart as occurring in a particular order, no particular ordering is required unless otherwise specified or because one act depends on another act being completed before the act can begin.

[0146] Fig.11 A flow chart of an example method 1100 for generating one or more self-published statements is shown. The method 1100 may be implemented in a computing system that is a principal entity that is a DID owner. The method 1100 includes receiving a user instruction to generate a self-published statement (1110). In response to the user instruction, the computing system generates one or more statements (1120). For each of the one or more statements, at least the corresponding DID 1121, attribute 1122, and attribute value 1123 are recorded in the statement. In some cases, metadata data 124, such as a unique identifier 1125 that identifies the statement, one or more conditions 1126 for accessing the self-published statement, and / or one or more revocation mechanisms 1127 are also recorded in at least some of the statements. The generated statement is then signed by a private key associated with the DID (1130). At least a portion of the data related to the self-published statement is then propagated to a distributed ledger (1140). In some embodiments, the public key of the DID (corresponding to the private key used to sign the statement) is propagated to the distributed ledger (1141). In some embodiments, a hash of the DID's public key or a hash of the self-publication statement is propagated to the distributed ledger (1142).

[0147] In some embodiments, in response to receiving a request for self-identification of a DID owner from a relying entity, a self-publishing statement is generated (1150). For example, the request indicates the attributes (e.g., name, email) that the relying entity needs to be identified. In response to the request, the computing system generates one or more self-publishing statements, including the required attributes and their corresponding values.

[0148] Fig.12A flowchart of an example method 1200 for generating identification data based on a request from a dependent entity is further shown. Method 1200 may also be performed by a computing system associated with a principal entity that is the owner of a DID. Method 1200 includes receiving a request for self-identification of a DID owner from a dependent entity (1210). The computing system then generates identification data based on the request (1220). Generating identification data includes generating one or more self-published statements (1221) and / or selecting one or more existing self-published statements (1222). In some embodiments, the computing system also receives a public key (1223) from the dependent entity and encrypts the identification data (1224) using the public key. The computing system then sends the generated identification data to the dependent entity (1230) and causes the dependent entity to verify the identification data (1240) via the data propagated to the distributed ledger.

[0149] Fig.13 A flow chart of an example method 1300 for verifying identification data received from a subject entity is shown. Method 1300 may be implemented at a computing system of a dependent entity. When the dependent entity is also a DID owner, the computing system may be a management module (e.g., a wallet), a user agent, and / or an ID center associated with the DID of the dependent entity. Method 1300 includes receiving identification data from a subject entity associated with the DID (1310). In some cases, the identification data is encrypted by a public key of the dependent entity. In this case, the computing system decrypts the encrypted identification data (1320) by a private key of the dependent entity.

[0150] The identification data includes at least one self-issued statement. The computing system verifies the identification data (1330). Verifying the identification data includes extracting at least one self-issued statement from the identification data (1331). At least one self-issued statement includes a signature signed by a private key of a subject entity. The computing system obtains a public key of the subject DID (1332) and decrypts the signature of each self-issued statement (1333). The computing system also obtains data related to each statement propagated to the distributed ledger (1334) and uses the obtained data to verify the decrypted signature (1335). In some embodiments, the public key of the subject entity is propagated to the distributed ledger, and the public key is obtained from the distributed ledger and used to decrypt the signature. In some embodiments, a hash of the public key or a hash of the self-issued statement is propagated to the distributed ledger. The computing system re-hashes the received public key or self-issued statement and compares the re-hashed data with the data propagated to the distributed ledger to determine whether the identification data is valid.

[0151] In some cases, self-identification is performed mutually, i.e., each entity presents its identification data to the other entity. In this case, each entity is both a principal entity and a dependent entity. Thus, the claimed embodiments allow entities to securely self-identify themselves to each other, and also allow entities to verify the self-identification data of other entities. Furthermore, the self-identification data is presented only to the intended dependent entities as needed, so that the user's privacy is protected not only from unrelated entities, but also from centralized service providers.

[0152] For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in different orders. In addition, the operations outlined are provided only as examples, and some operations may be optional, may be combined into fewer steps and operations, supplement further operations, or expand into additional operations without departing from the essence of the disclosed embodiments.

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

Claims

1. A computing system comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions thereon, the computer-executable instructions being structured to, when executed by one or more processors, cause the computing system to: generating one or more statements, each of the one or more statements including at least information related to (1) a decentralized identifier (DID), the DID being generated by a DID creation module of the computing system, the DID creation module including one or more drivers, the one or more drivers being configured to work with a distributed ledger on which the DID is to be included, thereby ensuring that the DID complies with an underlying method of the distributed ledger, (2) attributes of a subject entity, the subject entity being an owner of the DID, and (3) a value corresponding to the attribute; For each of the one or more statements, generating a cryptographic signature by signing the statement with a private key associated with the corresponding DID, the private key being generated by a key generation module of the computing system, the key generation module also generating a public key paired with the private key, the cryptographic signature certifying that the statement is a self-issued statement, the self-issued statement being issued by and relating to the subject entity; as well as Propagate a portion of data associated with the self-published statement to the distributed ledger, the portion of data associated with the self-published statement comprising one of: the public key or a hash of the public key.

2. The computing system of claim 1 , further caused to: receiving a user instruction from the subject entity for generating a self-published statement, the user instruction including specifying at least (1) a DID, (2) an attribute of the subject entity, and (3) a value corresponding to the attribute; and A self-publishing statement is generated based on the user indication.

3. A computing system according to claim 1, wherein the computing system is also caused to record one of the following with at least one of the one or more self-published statements as metadata: (1) a unique identifier that identifies the corresponding self-published statement, (2) one or more conditions for accessing the corresponding self-published statement, or (3) one or more revocation mechanisms for revoking the corresponding self-published statement.

4. A computing system according to claim 3, wherein the one or more conditions include at least one of the following: (1) requiring the relying entity to provide identification information, (2) requiring the relying entity to provide one or more verifiable statements, (3) requiring the relying entity to grant permission for accessing a portion of the data, or (4) requiring the relying entity to provide a specific service.

5. The computing system of claim 3, wherein the one or more revocation mechanisms include at least one of: (1) an expiration time of the corresponding self-published statement, (2) a predetermined number of times the corresponding self-published statement can be accessed by a relying entity, (3) an automatic revocation mechanism that automatically revokes the corresponding self-published statement in response to a change in data contained in a DID document of the corresponding DID or personal data of the owner of the corresponding DID, or (4) a manual revocation mechanism that allows the owner of the corresponding DID to manually revoke the self-published statement.

6. The computing system of claim 1 , further caused to perform: receiving a request from a relying entity for a self-identification of the principal entity; and In response to the request, selecting at least one self-published statement of the subject entity; generating identification data comprising the at least one self-published statement; sending the generated identification data to the relying entity; as well as causing the identification data to be verified by the relying entity via data associated with the at least one self-issued statement propagated onto the distributed ledger.

7. The computing system of claim 6, wherein: The request from the dependent entity comprises a request for a value of a particular attribute of the principal entity, In response to the request, the computing system is caused to: Accessing the personal data of the subject entity or the DID document of the DID to obtain the value of the specific attribute of the subject entity; generating a self-publishing statement, the self-publishing statement including the obtained value of the specific attribute, and Identification data is generated that includes the self-publishing statement.

8. The computing system of claim 6, wherein the verifying the identification data comprises verifying each of the at least one self-published statement, wherein verifying each self-published statement comprises: extracting at least one self-published statement from the identification data; Obtaining the public key of the DID; decrypting the cryptographic signature of the at least one self-published statement using the public key of the DID; Retrieving data related to the at least one self-published statement from the distributed ledger; as well as Whether a result of the decryption is valid is determined based on the portion of data associated with the self-issued statement.

9. The computing system of claim 6, further caused to: receiving a public key of the relying entity; encrypting the identification data by means of the public key of the relying entity; and The encrypted identification data is sent to the relying entity.

10. The computing system of claim 6, further caused to: Map multiple self-publishing declarations to multiple dependent entities; recording the mapping between the plurality of self-published declarations and the plurality of dependent entities as mapping data; and In response to receiving a request for self-identification from a particular relying entity, accessing the mapping data to obtain one or more self-published declarations mapped to the specific dependent entity; and Identification data is generated that includes the one or more self-issued statements.

11. The computing system of claim 10, further caused to: receiving a user input from the subject entity to generate or update the mapping data, the user input indicating mapping of one or more specific self-published declarations to one or more specific dependent entities; The mapping data is updated based on the user input.

12. The computing system of claim 6, in response to receiving a request for self-identification from a relying entity, the computing system is further caused to: determining whether metadata associated with the at least one statement includes one or more conditions and whether the one or more conditions are satisfied; In response to determining that the one or more conditions are satisfied, generating the identification data; as well as In response to determining that the one or more conditions are not satisfied, the request from the dependent entity is denied and a notification is generated to notify the principal entity.

13. The computing system of claim 6, further caused to: In response to a change in a value of a property associated with a self-published declaration, the self-published declaration including the value of the property is revoked or the self-published declaration is updated with the changed value of the property.

14. A method for a computing system to publish and present self-published statements in a decentralized environment, the method comprising: Generate one or more statements, each of the one or more statements including at least information related to (1) a decentralized identifier (DID), the DID generated by a DID creation module of the computing system, the DID creation module including one or more drivers configured to work with a distributed ledger on which the DID is to be included, thereby ensuring that the DID complies with an underlying method of the distributed ledger, (2) attributes of a subject entity, the subject entity being an owner of the DID, and (3) values ​​corresponding to the attributes; For each of the one or more statements, generating a cryptographic signature by signing the statement with a private key associated with the corresponding DID, the private key generated by a key generation module of the computing system, the key generation module also generating a public key paired with the private key, the cryptographic signature certifying that the statement is a self-issued statement, the self-issued statement is issued by and related to the subject entity; and Propagate a portion of data associated with the self-published statement to the distributed ledger, the portion of data associated with the self-published statement comprising one of: the public key or a hash of the public key.

Images