Binding decentralized identifiers to verified claims

Abstract

An associated data structure corresponding to a derived decentralized identifier of a subject entity is used to share a verified statement about the subject entity with one or more dependent entities. The decentralized identifier of the subject entity is derived from a source decentralized identifier of the subject entity. Next, an associated data structure is created using the derived decentralized identifier. The associated data structure is constructed to be interpretable by the dependent entity as proof that the verified statement is about the derived decentralized identifier. The dependent entity then causes the verified statement about the subject entity to be provided. The verified statement includes the associated data structure created using the derived decentralized identifier.

Description

Background Art

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

[0002] Decentralized identifiers (DIDs) are a new type of identifier that is independent of any centralized registry, identity provider, or credentialing authority. Distributed ledger technologies, such as blockchain, provide the opportunity to use fully decentralized identifiers. Distributed ledger technologies use a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in the ledger segment cannot be retroactively altered without changing all subsequent segments of the ledger, which provides a fairly secure platform.

[0003] In this decentralized environment, claims related to the owner of a DID can be verified by a claim issuing entity, and the owner of the DID can send such verified claims to any dependent entity. Each user can have multiple DIDs. Verified claims can be linked to multiple DIDs owned by the same user, allowing the claim issuing entity to find correlations between multiple DIDs.

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those 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

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

[0006] Embodiments disclosed herein relate to binding a decentralized identifier (DID) to a verified claim. The binding of a DID to a verified claim is implemented in a decentralized network that implements a distributed ledger. The distributed ledger is configured to back up one or more DIDs for one or more users of a computing system. First, a decentralized identifier is derived for a subject entity. Next, an associated data structure is created using the derived decentralized identifier. The associated data structure is constructed to be interpretable by a dependent entity as proof that the verified claim is about the derived decentralized identifier. The system then enables the dependent entity to be provided with a verified claim about a state entity. The verified claim includes an associated data structure created using the derived decentralized identifier.

[0007] In some embodiments, the associated data structure may be encoded data generated by the decentralized identifier using a one-way encoding, such that the claim issuing entity cannot reconstruct the derived decentralized identifier from the associated data structure. Therefore, even if the claim issuing entity issues a verified claim associated with the associated data structure, the claim issuing entity cannot correlate the derived DID with the source DID. Therefore, the privacy of the derived DID is further protected by the claim issuing entity.

[0008] Additional features and advantages will be set forth in the following description, and in part will become apparent from the description, or may be learned by practicing the teachings herein. The features and advantages of the present invention may be realized and obtained by means of the instruments 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 by the practice of the present invention as set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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 not therefore to be considered limiting in scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0010] Figure 1 illustrates an example computing system in which the principles described herein may be employed;

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

[0012] Figure 3 illustrates an example environment for various DID management operations and services;

[0013] Figure 4 illustrates an embodiment of an example environment in which verified claims related to a DID owner may be published;

[0014] Figure 5 An example verified claim is illustrated;

[0015] Figure 6 illustrates an example embodiment of how a source DID may be used to generate a derived DID;

[0016] Fig. 7A An example embodiment is illustrated wherein a derived claim may be generated from a source claim, the source claim being associated with a source DID, and the derived claim being associated with a derived DID;

[0017] Figure 7B An example embodiment is illustrated in which a derived claim may be generated using an associated data structure, the associated data structure corresponding to a derived DID;

[0018] Figure 8 illustrates a diagram illustrating an example embodiment of how an associative data structure may be generated;

[0019] Fig. 9 illustrates an example verified claim capable of preserving the privacy of a derived DID from a claim issuing entity;

[0020] Fig.10 A flow chart illustrating an example method for using an associated data structure corresponding to a derived decentralized identifier of a subject entity to share a verified claim about a subject entity to one or more dependent entities;

[0021] Fig.11 A flowchart illustrating an example method for causing verifiable claims to be provided to a relying entity; and

[0022] Fig.12 A flow chart of an example method is illustrated for using a message authentication code corresponding to a derived decentralized identifier of a subject entity to share authenticated claims about the subject entity to one or more relying entities. DETAILED DESCRIPTION

[0023] Embodiments disclosed herein relate to binding a decentralized identifier (DID) to a verified claim. The binding of a DID to a verified claim is implemented in a decentralized network that implements a distributed ledger. The distributed ledger is configured to back up one or more DIDs for one or more users of a computing system. First, a decentralized identifier is derived for a subject entity. Next, an associated data structure is created using the derived decentralized identifier. The associated data structure is constructed to be interpretable by a dependent entity as proof that the verified claim is about the derived decentralized identifier. The system then enables the dependent entity to be provided with a verified claim about a state entity. The verified claim includes an associated data structure created using the derived decentralized identifier.

[0024] In some embodiments, the associated data structure may be encoded data generated by the decentralized identifier using a one-way encoding, such that the claim issuing entity cannot reconstruct the derived decentralized identifier from the associated data structure. Therefore, even if the claim issuing entity issues a verified claim associated with the associated data structure, the claim issuing entity cannot correlate the derived DID with the source DID. Therefore, the privacy of the derived DID is further protected by the claim issuing entity.

[0025] Because the principles described herein can be implemented in the context of a computing system, some introductory discussion of computing systems will be relative to Figure 1 The description will then return to the principles of the DID platform relative to the remaining figures.

[0026] Computing systems now increasingly take various forms. For example, a computing system may be a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe computer, a distributed computing system, a data center, or even a device that is not conventionally considered to be a computing system, such as a wearable device (e.g., a watch). In this description and claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) that includes at least one physically tangible processor and a physically tangible memory capable of having computer executable instructions that can be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed over a network environment and may include multiple constituent computing systems.

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

[0028] 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 illustrated as including an executable component 106. The term "executable component" is a name for a structure that is well understood by one of ordinary skill in the computing arts, which structure can be software, hardware, or a combination thereof. For example, when implemented in software, one of ordinary skill in the art will understand that the structure of an executable component may include a software object, routine, method, etc. that can be executed on a computing system, whether or not such executable component is present in the stack of the computing system or whether or not the executable component is present on a computer-readable storage medium.

[0029] 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 a function. This structure can be directly computer-readable by the processor (if the executable component is binary, this is the case). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) to generate such a binary that can be directly interpreted by the processor. When the term "executable component" is used, this understanding of the example structure of the executable component is well within the understanding of one of ordinary skill in the computing arts.

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

[0031] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If such actions are implemented in software, one or more processors (of the associated computing system that performs the actions) direct the operation of the computing system in response to computer-executable instructions that have executed the component executable components. For example, such computer-executable instructions can be implemented on one or more computer-readable media forming a computer program product. Examples of such operations involve the manipulation of data. If such actions are implemented exclusively or almost exclusively in hardware, such as in an FPGA or ASIC, the computer-executable instructions can be hard-coded or hard-wired logic gates. The computer-executable instructions (and the manipulated data) can be stored in the memory 104 of the computing system 100. The computing system 100 can also include a communication channel 108, which allows the computing system 100 to communicate with other computing systems through, for example, a network 110.

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

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

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

[0035] "Network" is defined as one or more data links that allow electronic data to be transported 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 correctly treats the connection as a transmission medium. The transmission medium can include a network and / or a data link that can be used to carry a desired program code component in the form of a computer executable instruction or data structure and can be accessed by a general or special computing system. The above combination should also be included in the scope of computer-readable media.

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

[0037] For example, computer executable instructions include instructions and data that, when executed at a processor, cause a general-purpose computing system, a special-purpose computing system, or a special-purpose processing device to perform a specific function or group of functions. Alternatively or in addition, computer executable instructions can configure a computing system to perform a specific function or group of functions. For example, computer executable instructions can be binary or even instructions, such as intermediate format instructions (such as assembly language) or even source code, that undergo some conversion (such as compilation) before being directly executed by a processor.

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

[0039] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment using many types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, multiprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as watches), etc. The present invention can also be practiced in a distributed system environment, where local and remote computing systems linked by a network (by a hardwired data link, a wireless data link, or by a combination of hardwired and wireless data links) all perform tasks. In a distributed system environment, program modules can be located in local and remote memory storage devices.

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

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

[0042] Some introductory discussion of decentralized identities (DIDs) and the environments in which they are created and reside will not be relevant to Figure 2 Given. Figure 2 As illustrated, DID owner 201 may own or control DID 205, which represents the identity of DID owner 201. DID owner 201 may register a DID using a creation and registration service, which will be explained in more detail below.

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

[0044] DID owner 201 may alternatively be a machine, system or device or a collection of (multiple) machines, (multiple) devices and / or (multiple) systems. In other embodiments, DID owner 201 may be a sub-part of a machine, system or device. For example, a device can 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, a machine or device may have a DID, and each sub-part may also have a DID. A DID owner may also be a software component, such as the one described above with respect to Figure 1 An example of a complex executable component 106 may be an artificial intelligence. The artificial intelligence may also have a DID.

[0045] Thus, DID owner 201 may be any reasonable entity, human or non-human, that is capable of creating a DID 205, or at least has a DID 205 created for them and associated with them. 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, depending on the circumstances.

[0046] As mentioned, DID owner 201 can create and register DID 205. DID 205 can be any identifier that can be associated with DID owner 201. Preferably, the identifier is unique to the DID owner 201, at least within the scope of the DID's intended use. As an example, the identifier can be a locally unique identifier, and it may be more desirable to be a globally unique identifier for an identification system that is intended to operate globally. In some embodiments, DID 205 can be a uniform resource identifier (URI) (such as a uniform resource locator (URL)) or other pointer that associates DID owner 201 with a mechanism for participating in a trusted interaction with DID owner 201.

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

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

[0049] Also like Figure 2 As shown, DID owner 201 controls a private key 206 and a public key 207 pair associated with DID 205. Because DID 205 is independent of any centralized authority, private key 206 should be in full control of DID owner 201 at all times. 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.

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

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

[0052] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 can be used by a third-party entity that is granted permission by DID owner 201 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.

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

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

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

[0056] The DID document 210 may also include one or more service endpoints 213. A service endpoint may include 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 an identity server or center), and verifiable claim repository services. Thus, the service endpoints 213 operate as pointers to services that operate on behalf of the DID owner 201. These pointers may be used by the DID owner 201 or a third-party entity to access services that operate on behalf of the DID owner 201. Specific examples of service endpoints 213 are explained in more detail below.

[0057] The ID file 210 may also include identification information 214. The identification information 214 may include personally identifiable information, such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Thus, for different purposes, the identification information 214 listed in the DID document 210 may represent different roles of the DID owner 201. For example, the role may be pseudo-anonymous, such as when the DID owner 201 identifies him or her as the author of an article published on a blog, the DID owner 201 may include a pseudonym in the DID document; the role may be completely anonymous, such as the DID owner 201 may only want to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.), but not his or her name in the DID file; and the role may be specific to who the DID owner 201 is as an individual, such as the DID owner 201 may include information identifying him or her as a volunteer for a specific charity organization, an employee of a specific enterprise, a winner of a specific award, etc.

[0058] The DID document 210 may also include credential information 215, which may also be referred to herein as a witness. The credential information 215 may be any information associated with the background of the DID owner 201. For example, the credential information 215 may be (but is not limited to) qualifications, achievements, government IDs, government rights such as a passport or driver's license, payment providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of the DID owner 201.

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

[0060] Figure 2 A distributed ledger or blockchain 220 is also illustrated. The distributed ledger 220 may be any decentralized distributed network including various computing systems that communicate with each other. For example, the distributed ledger 220 may include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems, as illustrated by ellipsis 260. The distributed ledger or blockchain 220 may operate according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers that may correspond to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

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

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

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

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

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

[0066] Environment 300 also includes a DID lifecycle management module 320. It is noted that in operation, DID lifecycle management module 320 may reside on or be executed by one or more of user device 301, web browser 302, and operating system 303, as illustrated by lines 301a, 302a, and 303a. Therefore, for ease of explanation, DID lifecycle management module 320 is shown as being separate.

[0067] like Figure 3 As shown, DID lifecycle management module 320 includes DID creation module 330. DID creation module 330 can be 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 can include or otherwise access user interface (UI) element 335, which can guide DID owner 201 in creating DID 205. DID creation module 330 can have 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 method of the distributed ledger.

[0068] Specific embodiments will now be described. For example, the UI 335 may provide a prompt for the user to type in a username or some other human identifiable name. The name may be used as the display name of the DID 205 to be generated. As previously described, the DID 205 may be a long string of random numbers and letters, so it may be advantageous to have a human identifiable name for the display name. The DID creation module 330 may then generate the DID 205. In an embodiment with the UI 335, the DID 205 may be shown in an identification list and may be associated with a human identifiable name.

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

[0070] In operation, DID creation module 330 accesses register 310 of a specific distributed ledger configured to record transactions associated with DID 205. DID creation module 330 uses register 310 to record DID hash 231, DID hash 241, and DID hash 251 in the distributed ledger in the manner previously described, and stores DID document 210 in the manner previously described. This process may use public key 207 in hash generation.

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

[0072] As previously discussed, the key generation module 350 generates a pair of private key 206 and public key 207, and the public key 207 is then recorded in the DID document 210. Therefore, the public key 207 can be used by all third parties associated with the DID owner 201 and who wish to provide services to the DID owner 201. Therefore, when the DID owner 201 desires to associate a new device with the DID 205, the DID owner 201 can execute the DID creation module 330 on the new device. The DID creation module 330 can then use the registrar 310 to update the DID document 210 to reflect that the new device is now associated with the DID 205, and this will be reflected in the update transaction on the distributed ledger 220, as previously described.

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

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

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

[0076] 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 may be useful for each device, or some subset of devices under the control of DID owner 201, to have their own DID. Therefore, in some embodiments, DID creation module 330 may generate an additional DID, such as DID 331, for each device. The creation module would then generate a private and public key pair and a DID document for each of the devices and record them on distributed ledger 220 in the manner previously described. Such an embodiment may be advantageous for devices that may change ownership, because it may be possible to associate a specific device DID with a new owner of the device by granting authorization rights to the new owner in the DID document and revoking such rights from the old owner.

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

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

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

[0080] Applications using DIDs in a decentralized environment include publishing and presenting verifiable statements associated with DIDs. Claiming a verifiable statement may be simple, stating that you are over 21 years old, that you are authorized to drive, or that you have obtained a college degree. These statements can be verified by showing the ID or certificate issued by the statement issuing entity to the relying entity. For example, a driver's license can be used to prove that the holder has the ability to drive a motor vehicle, and the same driver's license can also be used to prove that the holder is over 21 years old. As another example, a college diploma can be used to prove that a person has graduated from college and obtained a college degree. These actual IDs and credentials can prove their authenticity because they have a unique appearance and are very difficult to forge. However, when two entities communicate over a computer network, claiming a verifiable statement is more complicated. DID provides users with a secure, private and verifiable mechanism to declare these statements on a computer network or between computing devices.

[0081] Figure 4 An example environment 400 is illustrated in which verified claims may be issued. Figure 4As illustrated, subject entity 401 is the DID owner. Subject entity 401 may request to issue a verified statement to statement issuing entity 403. Such a request may be sent by DID management module 402 of subject entity 401. One-way arrow 404 indicates that DID management module 402 sends a request to statement issuing entity 403. The request includes at least identification information of the subject entity, such as the DID of the subject entity. Statement issuing entity 403 receives a request including at least the DID of the subject entity from DID management module 402. The request may also include what type of statement is being requested, what (type of) information is to be verified, and / or what type of information is requested to be included in the verified statement.

[0082] Based on the received request to issue a verified statement, the statement issuing entity 403 verifies the identity of the subject entity. The verification process is completed on the statement issuing entity 403 side, which is represented by the loop arrow 405. The verification can be performed by comparing the received DID of the subject entity with the data stored in the data storage device. If some matching data associated with the received DID is found, the DID of the subject entity is verified to be valid. In addition, the information requested to be verified or the information requested to be included in the verified statement can also be verified based on the matching data associated with the DID. For example, if the subject entity 401 is a driver, and the statement issuing entity 403 is the DMV of country A, the information requested to be included in the verified statement is that the driver is authorized to drive, and the DMV will verify the data associated with the driver 401 at the computing system 403 of the DMV, and determine whether the driver 401 is authorized to drive. If the data of the DMV shows that the driver 401 has a valid driver's license, which indicates that the driver is authorized to drive, the driver's identity is further verified.

[0083] If the identity of the subject entity is verified, the claim issuing entity 403 generates a verified claim. The claim is generated by the claim issuing entity 403 at the computing system 403 of the claim issuing entity, which is represented by the one-way arrow 406. The verified claim typically includes a proof section to prove the authenticity of the claim. The proof section typically includes a signature generated by the secret private key of the claim issuing entity.

[0084] After the verified claim is generated, it is then published or sent to the principal entity 401 or the principal entity's DID management module 402, which is represented by a one-way arrow 407. After receiving the published verified claim, the DID management module 402 may store the verified claim 409 in a storage device (e.g., a claim repository storage device 408), which is represented by a one-way arrow 409. In some embodiments, the claim repository storage device 408 may be part of the DID management module 402, or a local storage device of the DID management module 402. Alternatively or additionally, the claim repository storage device 408 may be a cloud storage device associated with the principal entity's DID.

[0085] The purpose of having a verified statement is that the subject entity 401 can prove his / her credentials to the dependent entity. Therefore, ultimately, the verified statement is sent to the dependent entity. The verified statement can be sent directly from the statement issuing entity 403 to the dependent entity. Alternatively or in addition, the verified statement can be sent to the dependent entity from the DID management module 402 or the statement repository 408. The verified statement can also be directly controlled by the subject entity 401, and the subject entity 401 can determine how and to whom the verified statement will be sent. For example, the subject entity 401 (e.g., a driver) can send the verified statement to another entity (e.g., a car rental company) via email, SMS, printed paper, or other communication channels.

[0086] As briefly discussed above, a verified statement typically has a proof section that includes a signature signed by the secret private key of the statement-issuing entity. After receiving the verified statement, the relying entity can decode the statement-issuing entity's signature by using the statement-issuing entity's public key. If the decrypted signature matches the information contained in the asserted statement, the verified statement is proven to be true and correct; on the other hand, if the decrypted signature does not match the information contained in the asserted statement, the statement may have been tampered with or is false. Thus, the subject entity 401 is able to prove his / her credentials to the relying entity without having to show his / her actual ID or paperwork, or have a representative from the statement-issuing entity 403 on the phone.

[0087] Further, the process of requesting and publishing a verified statement can be automatically completed by the DID management module of the subject entity and the computing system of the statement issuing entity 403. In some embodiments, the computing system of the relying entity can generate a request to verify the credentials of the subject entity and send the request to the DID management module 402 of the subject entity, and then the DID management module 402 of the subject entity determines the identity of the relying entity. If the identity of the relying entity is verified as a valid entity for requesting the credentials of the subject entity, the DID management module 402 of the subject entity can then request the statement issuing entity 403 to issue a verified statement and cause the issued verified statement to be sent to the computing system of the relying entity.

[0088] Figure 5 An example verified statement 500 that may be issued by a statement issuing entity is illustrated. The verified statement 500 may be in JSON format. In some embodiments, the verified statement 500 may have three sections: (1) a statement metadata section 510, (2) a statement section 520, and (3) a certification section 530. The statement metadata 510 is generally used to describe characteristics of the statement, such as context 511, an identifier of the credential 512, the type of statement 513, the entity issuing the credential 514, the issue date 515, and the expiration date 516. The context 511 field generally includes links to one or more files that establish special terms that may be used in the verified statement 500. The ellipsis 517 indicates that there may be additional metadata included in the verified statement 500. For example, the statement metadata 510 may also include a public key (not shown) for verification purposes, revocation mechanisms, etc.

[0089] like Figure 5 As shown, the identity of the statement issuing entity 514 is the DMV of State A. The type of the verified statement 513 is the subject entity's driver's license. The statement's issuance date 515 is 2019-05-20, and the statement's expiration date 517 is 2029-05-20.

[0090] Verified claim 500 also includes one or more claim sections 520. Claim section 520 includes an identifier of a subject entity (e.g., a DID of subject entity 521) and a claim (e.g., a credential) that the subject entity is asserting. Figure 5 As illustrated, the verified claim is the subject entity's driver's license 513 , which includes the driver's (ie, subject entity's) name 522 , the driver's date of birth 523 , the driver's physical address 524 , and the driver's license number 525 .

[0091] Finally, verified claim 500 also includes proof section 530. Proof section 530 is a digital proof that makes the information included in claim section 520 tamper-proof. Proof section 530 typically includes a digital signature 534, the cryptographic signature type 531 used to generate signature 534, and the date 532 when the signature was created.

[0092] Many different embodiments may be implemented to generate the digital signature 534. As an example, in some embodiments, the content in the statement section 520 may be used to generate a hash, and the generated hash may then be encrypted using the private key of the statement issuing entity to generate the digital signature 534. Thus, when a relying entity receives the verified statement 500, the relying entity may decrypt the digital signature 534 using the public key 533 of the statement issuing entity, and recreate the hash using the content included in the statement section 520. The decrypted digital signature and the recreated hash are then compared. If the decrypted digital signature matches the hash of the statement section 520, the statement section 520 is authenticated as authentic and has not been tampered with. On the other hand, if the decrypted digital signature does not match the hash of the statement section 520, the statement section 520 is either tampered with or is false. Thus, the relying entity is able to verify whether the statement was issued by the statement issuing entity and whether the statement is authentic and correct.

[0093] In addition to publishing and presenting verified claims associated with a user's permanent DID (e.g., a DID associated with a user's driver's license), multiple DIDs may be published for the same user. In some embodiments, a user is able to generate a new DID each time the user communicates or conducts business with a new dependent entity, and have the claim-issuing entity publish a new verified claim associated with the newly generated DID. Thus, the dependent entity will only see the newly generated DID and the newly published claim, and not the user's permanent DID. A DID generated for the purpose of dealing with only one dependent entity may also be referred to as a paired DID, because such a DID is generated to be paired only with a specific dependent entity.

[0094] There are many different ways to generate additional DIDs or pairs of DIDs for users. The simplest method is to generate a random number and use the generated random number as the private key of the new DID, and then derive the public key from the randomly generated private key. The benefit of using randomly generated DIDs is that each DID of the same user is unrelated, so it is impossible to recreate the user's other DIDs by knowing any other DID of the user. However, each pair of DIDs can often be used for each entity that communicates with the subject entity or conducts business with it, or even for each transaction. Therefore, there may be a large number of DIDs that have been generated or will be generated for each user. If each DID in the DID is unrelated to each other, it may become difficult to manage a large number of DIDs for the user. Therefore, it is advantageous to derive a new DID from an existing DID. Specifically, if the derived new DID is used to claim a verified statement related to an existing DID credential, deriving a new DID using an existing DID may simplify the DID management of the DID management module.

[0095] Figure 6 An example embodiment is illustrated in which a source DID may be used to derive one or more new DIDs (also referred to herein as (derived DIDs)). Source DID 601 may be a DID similar to DID 201 including public key 609 and private key 602. Chain code 603 may be generated from the same seed used to generate source private key 602. In some embodiments, a one-way hash function may be used to generate source private key 602 and / or chain code 603. In some embodiments, the left M bits of the hash and the right NM bits of the hash may be simply used as source private key 602 and chain code 603.

[0096] For example, N can be 512 and M can be 256. Therefore, the hash is 512 bits long, and the 512-bit long hash is split into two 256-bit halves (because M is 256 and NM is also 256). The left half 256 bits of the hash can be used to generate the source private key 602. The right half 256 bits of the hash can be used to generate the chain code 603. The source private key 602, the chain code 603, and the index number can then be used to generate the private key 606 of the derived DID 620.

[0097] like Figure 6 As illustrated, the source private key 602, chain code 603, and index number 604 may then be used as input to produce another N-bit hash 605. The left M bits of the N-bit hash 605 are then used to generate the derived DID's private key 606. The derived DID 620's private key 606 may then be used to derive the derived DID 620's public key 607.

[0098] The index number 604 may be 0 or any natural number used to index a derived DID. Each time a new derived DID 620 is to be generated, the index number is increased by 1. For example, when a new dependent entity requires the owner of the source DID to prove specific credentials, the owner of the source DID 601 or his / her DID management module may generate a new derived DID 620 (using a new index number). Thus, a user can have as many derived DIDs as needed or desired. Each time a new DID is needed, the process is repeated and a new DID is generated.

[0099] Each derived DID 620 can also be used as a source DID to generate additional DIDs. For example, the derived private key 607, the derived chain code 608, and the index number can be used to generate a new DID derived from the derived DID 620. This process can also be repeated as many times as needed or as desired by the user.

[0100] In some embodiments, the DID management module 320 of the source DID owner may be able to automatically generate such a derived DID whenever a new derived DID is needed. In some embodiments, a separate service may be provided to the DID owner or the DID management module 320 to generate such a derived DID.

[0101] The derived DID 620 can be used to assert a derived claim. A derived claim is a verified claim that asserts only a portion of the information asserted in an existing claim (also referred to herein as a source claim). A source claim is associated with a source DID 601. The derived DID 620 can be used to communicate with a group of entities (e.g., all car rental companies). Alternatively, the derived DID 620 can be used to communicate only with one specific dependent entity or one transaction.

[0102] For example, source DID 601 may be associated with a user's driver's license. Derived DID 620 may be used to declare that the user is older than 21 or is permitted to drive, which is part of the information included in the source statement (eg, driver's license information) associated with source DID 601.

[0103] Fig. 7A An example embodiment 700A is illustrated in which a derived statement 740 or 750 associated with a derived DID 747 or 757 may be issued based on a previously issued verified statement 710. Fig. 7A , the verified statement 710 may correspond to Figure 5 Example verified statement 500. Verified statement 710 includes metadata sections including context 711, ID 712, type 713, publisher 714, issue date 715, and expiration date 716, each of which may correspond to Figure 5 Context 511 , ID 512 , type 513 , issuer 514 , issue date 515 , and expiration date 516 . Ellipses 717 indicate that there may be additional metadata included in the verified statement 710 .

[0104] The statement body 720 may also be similar to the statement section 520. As illustrated, the verified statement 710 may point to the driver's license of the owner of the source DID 721. The statement body 720 includes all the information related to the driver's license, such as ID 721, name 722, DOB 723, address 724, and DL# 725, each of which may correspond to Figure 5 ID 521, name 522, DOB 523, address 524, and DL# 525 of the person who signed the certificate 730. The certificate 730 includes a signature 731 and additional information (indicated by ellipsis 732), which may correspond to Figure 5 Each field illustrated in the proof section 530.

[0105] However, a driver's license includes a lot of personally identifiable information that the owner of source DID 721 may not want to always disclose to relying entities. Moreover, in many scenarios, relying entities may not need to know all of the information included on a driver's license. For example, when the owner of source DID 721 attempts to rent a car from rental car company A 760, the rental car agency may only need to know that the customer is authorized to drive. In this case, the owner of the source DID can generate a derived DID 747 that is only used to communicate with rental car company A 760. The derived DID 747 can be used to publish a derived statement 740. The derived statement 740 may include only a portion of the information included in the verified statement 710, which points to the driver's license of the owner of source DID 721.

[0106] Reference Figure 4 In order to issue a derived statement 740, the DID management module 402 of the subject entity may first send a request to issue a derived statement to the statement issuing entity 403. The request may include a source DID and a derived DID. The source DID may be associated with a statement previously issued by the statement issuing entity 403. For example, the statement issuing entity 403 may be the DMV of Country A, and the source DID may be associated with a driver's license issued by the DMV of Country A. Via the source DID, the statement issuing entity (e.g., the DMV of Country A) then verifies the identity of the subject entity based on the request from the subject entity to issue a derived statement including the derived DID.

[0107] For example, the request from the subject entity may include information indicating that the derived statement should only include whether the owner of the derived DID is allowed to drive and nothing else. Based on the information included in the request, the statement issuing entity 403 (e.g., the DMV of State A) may issue a statement 740 including the derived DID 747, and the derived statement 747 only states whether the owner of the derived DID 747 is allowed to drive 748.

[0108] Since this is the only information that the rental car company A 760 needs to know, the owner of the source DID does not even need to disclose his / her name, date of birth and / or physical address to the rental car company A 760. Even though the derived statement 740 may only include a portion of the information included in the verified statement 710, the derived statement 740 can still be authenticated based on the information provided in the proof section 749. The proof section 749 of the derived statement 740 can also include a proof section for the authentication of the derived statement 740 for the relying entity to verify. The proof section can include a signature signed by the statement issuing entity 744 (e.g., the DMV of State A). Therefore, the rental car company A 760 is able to verify that the derived statement 740 is true and correct, that is, the owner of the derived DID 747 is allowed to drive. At the same time, the rental car company A 760 still does not know other personal information of the driver, such as the driver's age or even the driver's name. Therefore, by using the derived statement 740 and the derived DID 747, the privacy of the driver (the owner of the source DID 721) is not protected by the relying entity.

[0109] Furthermore, since the derived DID 747 may be a paired DID intended to be used only for communication with the car rental company A 760 or only for a single rental transaction, the car rental company A 760 is not only unable to correlate the information obtained from the derived DID 747 with data from other car rental companies, but is also unable to find out whether the owner of the derived DID 747 has rented a car from it without the DID owner's prior consent.

[0110] As another example, at different times and locations, the owner of the source DID may want to rent a car from a different rental car company B 770. A new derived DID 757 may be generated from the source DID 721. Similarly, a new derived statement 750 is generated to include similar metadata information 751 to 755 and a similar statement 758 as those listed in the derived statement 740. The new derived statement 750 may also be signed by the DMV of State A, which is the same statement issuing entity. However, since each of the derived statements 740 and 750 does not include personally identifiable information, it is difficult for the two rental car companies A 760 and B 770 to find out whether the two derived DIDs 747 and 757 belong to the same driver even if the statements are the same.

[0111] The above embodiments allow an individual to present a derived statement to one or more relying entities using a derived DID, so that the individual's personally identifiable information is not protected by the relying entities. However, the statement issuing entity (e.g., the DMV of Country A) may still know that each of the derived DIDs 747, 757 belongs to the same person (i.e., the owner of the source DID 721) because each time a derived statement is to be issued, the subject entity must send the source DID 721 to the statement issuing entity (e.g., the DMV of Country A) to verify the identity of the subject entity, and also request the statement issuing entity to include the derived DID 747 or 757 in the derived statement 740 or 750. In particular, in a decentralized environment, DIDs are often propagated to metadata and / or blockchains, and when the statement issuing entity knows different derived DIDs, the statement issuing entity may be able to correlate different activities involved in different derived DIDs based on the records propagated to the blockchain or other metadata.

[0112] To further protect the privacy of the subject entity from the statement issuing entity, the principles described herein also disclose embodiments that do not require the derived DID to be sent and / or included in the derived statement. Details of such embodiments are described below with respect to Figure 7B describe.

[0113] Figure 7B An example embodiment 700B is illustrated in which derived DIDs 747 and 757 are not provided to a statement issuing entity or included in derived statements 740' and 750'. Instead, an associated data structure 747' or 757' of the derived DIDs 747 and 757 may be provided to the statement issuing entity. The associated data structure 747' or 757' is included in the derived statements 740' and 750'. Each of the associated data structures 747' and 757' is associated with a corresponding derived DID, which can be verified by a dependent entity (e.g., rental car company A 760 or B 770), but the statement issuing entity (e.g., the DMV in Country A) may not be able to reconstruct the derived DID from the associated data structures 747' and 757'.

[0114] As described above, unlike the embodiment where the subject entity sends the derived DID to the statement issuing entity each time a derived statement is requested to be issued, in this embodiment, only the associated data structure 747' or 757' is sent to the statement issuing entity. Therefore, the statement issuing entity will not know the relationship between the source DID and the derived DID.

[0115] Different embodiments may be implemented by the owner of the source DID or a DID management module to generate an associated data structure. Figure 8An example embodiment 800 is illustrated in which an associated data structure 806 may be generated. The generated associated data structure 806 is then provided to a claim issuing entity 807. The claim issuing entity 807 is then caused to generate a derived claim 809 including the associated data structure. The verified claim 809 is then caused to be sent to a relying entity 808. The relying entity 808 is able to verify whether the claim 809 is true and correct.

[0116] Reference Figure 8 , each of the entities (including subject entity 801, declaration issuing entity 807, and dependent entity 808) is represented by a circle. Each of these entities 801, 807, and 808 can be a computing system associated with and / or controlled by a corresponding physical entity. For example, subject entity 801 can be a personal computer, a mobile device, a web browser, and / or a DID management module 320 installed on the computer or mobile device of the DID owner. Declaration issuing entity 807 can correspond to Figure 7B For example, the statement issuing entity 807 may be a computing system of the DMV of country A. The dependent entity 808 may correspond to Figure 7B The DID owner may be a driver who is trying to rent a car from rental car company A 760. Before the rental car company 760 provides the driver with a rental car, the rental car company 760 may want to verify whether the driver is authorized to drive.

[0117] like Figure 8 As illustrated, the subject entity 801 (e.g., the driver's DID management module) first generates a derived DID 802. The derived DID 802 may be intended to be used only for communication with the rental car company A 760. The derived DID 802 is then fed into a function 803 as an input to generate an output. The output is a seed 804. Different functions can be implemented here as function 803, as long as the seed created by function 803 is at least resistant to dictionary attacks.

[0118] The seed 804 and the derived DID 802 are then fed into a function 810 as two inputs to generate an output. The output can then be used as an associated data structure 806. As an example, function 810 can be a function or algorithm for generating a message authentication code (MAC). The MAC algorithm can be composed of different cryptographic primitives, such as a cryptographic hash function or a different block cipher algorithm. A specific type of MAC is called a keyed hash message authentication code (HMAC), which is generated using a cryptographic hash function and a secret cryptographic key. HMAC is generated using a secret key and a message. Here, the seed 804 can be used as a secret key input, and the derived DID can be used as a message input. The seed and the derived DID are then used to derive one or more codes. One or more derived codes are then hashed once or multiple times via a predetermined hash function.

[0119] The function 810 used to generate the associated data structure 806 (e.g., HMAC) is a one-way function, such that an entity receiving the associated data structure 806 cannot work backwards to find out what the derived DID 802 and / or seed 804 are. Further, the more complex the function 810, the more secure the generated associated data structure 806 may be. On the other hand, the function 810 is deterministic, so as long as the two inputs are the same, the output is always the same. This is important because as long as the dependent entity 808 has the derived DID 802 and seed 804, the dependent entity 808 can verify that the associated data structure 806 is associated with the derived DID 802.

[0120] Once the associated data structure 806 is generated, the generated associated data structure 806 is sent to the statement issuing entity 807 to request that the statement issuing entity 807 publish the derived statement including the associated data structure 806. The process of publishing the derived statement 809 can be similar to that with respect to Figure 4 The main entity 801 may correspond to Figure 4 The main entity 401 and / or DID management module 402; the statement issuing entity 807 may correspond to Figure 4 The statement issued by the entity 403.

[0121] First, the subject entity 801 may send a request to the claim issuing entity 807 to issue a verified (derived) statement. The request may specify what types of verified statements will be included in the derived statement, such as a statement stating whether the derived DID owner is allowed to drive. At the same time, the source DID 810 may be sent to the claim issuing entity 807 along with the request, so that the claim issuing entity 807 can verify the identity of the subject entity 801. After the claim issuing entity 807 verifies the identity of the requesting party (e.g., driver, owner of the source DID), the claim issuing entity 807 generates a derived statement 809 and places the associated data structure 806' in the derived statement 809. The derived statement 809 with the associated data structure 806' may include a proof section (similar to Figure 5 ), it is thus concluded that the statements contained in statement 809 can be verified to be true and correct.

[0122] The derived statement 809 may be sent directly from the statement issuing entity 807 to the relying party 808, as represented by the one-way arrow 812. However, to further protect the privacy of the principal entity 801, rather than letting the statement issuing entity 807 know with whom the principal entity 801 is doing business, the derived statement 809 should first be sent to the principal entity 801 (represented by the one-way arrow 811), and then the principal entity 801 may send the received derived statement 809 to the relying entity 808. At substantially the same time, the principal entity 801 also sends the derived DID 802 and the seed 804 to the relying entity 808 (represented by the one-way arrows 813 and 814), so that the relying entity 808 can verify that the associated data structure 806' included in the derived statement 809 is associated with the derived DID 802. Arrows 811 to 814 are drawn by dashed lines, indicating that these communications are not related to the generation of the derived statement 809. Instead, the communications represented by the dashed lines are likely to occur after the derived statement 809 is generated. The arrows drawn by solid lines indicate the actions that are performed to cause the derived statement 809 to be generated.

[0123] Fig. 9 Also illustrated is an example statement 900 that includes an associated data structure but does not include a derived DID. Figure 5 The example statement 500 is similar in format. Statement 900 may be from Figure 5 The derived statement 900 may also include three sections: (i) a statement metadata section 910, (ii) a statement section 920, and (iii) proof sections 930. The statement metadata section 910 may include metadata related to context 911, id 912, type 913, publisher 914, publication date 915, expiration date 917, each of which corresponds to Figure 5511 to 515. Further, the proof section 930 may include information for authenticating the asserted statement 920, such as type 931, creation 932, creator 933, and signature 934, each of which may also correspond to the corresponding fields 531 to 534.

[0124] However, with Figure 5 Unlike declaration section 520 of FIG. 1 , declaration section 920 does not include the DID of the subject entity. Instead, the ID field includes an associated data structure associated with the DID. More than one associated data structure may be included in declaration section 920. Fig. 9 As illustrated, there are two associated data structures 921, 922 included in the declaration section 920. The ellipsis 923 indicates that there may be any natural number of associated data structures included in the declaration section 920.

[0125] Each of the association data structures 921 and 922 is associated with a different DID. For example, the association data structure 921 is associated with a first DID (ie, DID1), and the association data structure 922 is associated with a second DID (ie, DID2). Each of DID1 and DID2 may be a derived DID (from Figure 5 Since the associated data structure 922 is encoded via one or more one-way functions, having only the associated data structures 921, 922 does not allow any entity (including the claim issuing entity) to find out what the base DID is. Moreover, providing the seed and the first derived DID1 to the first entity only allows the first entity to verify the first derived DID1 921. The first entity still does not know what the second derived DID2 922 is.

[0126] For example, the subject entity may be shopping for a rental car company. The driver wants to ask each of the rental car companies A 760 and B 770 for a price. However, each of the rental car companies A 760 and B 770 wants to verify whether the subject entity is allowed to drive before sending a quote to the subject entity.

[0127] In this scenario, the subject entity may generate two derived DIDs (i.e., derived DID1 and derived DID2). The subject entity may then generate a seed for each of these derived DIDs, and then generate an associated data structure for each of the derived DIDs. The subject entity may then send the two associated data structures to a claim issuing entity (e.g., a DMV) and request that the claim issuing entity include the two associated data structures into one derived claim. Thereafter, the claim issuing entity verifies the identity of the subject entity and issues a claim 900 that includes two associated data structures 921 and 922, each associated with a different derived DID.

[0128] Therefore, the claim issuing entity (e.g., DMV) only knows that the issued derived claim is used by subject entities with two different DIDs, but does not know what the two different DIDs are. Therefore, by encoding the derived DID into an associated data structure and providing the associated data structure only to the claim issuing entity, the principles described herein provide additional privacy for the subject entity. Since the claim issuing entity does not know and cannot find out what the derived DID is, they cannot correlate activities associated with different derived DIDs with each other. Similarly, different dependent entities (e.g., car rental companies A and B) are also unaware of other derived DIDs associated with the same claim, making it impossible for car rental company A to retrieve subject entity activities associated with car rental company B, and vice versa.

[0129] In addition, an additional proof section 940 may be included in the derived statement 900. For example, the additional proof section 940 may include a signature signed by the subject entity. Alternatively or in addition, the additional proof section 940 may include information for the dependent entity to verify the associated data structure 921 or 922. For example, if the verified statement 900 is sent to a rental car company A that is processing the first derived DID1 of the subject entity, the additional proof section 940 may include the first derived DID1, the seed generated from the derived DID1, and the function for generating the associated data structure 806 (e.g., HMAC). After receiving the derived statement 900, the rental car company A (or its computer system) will use the information contained in the (multiple) first proof sections 930 to verify whether the statement is true and correct and is issued by the statement issuing entity (e.g., DMV). Further, the rental car company A will use the information contained in the second proof section 940 to verify whether the associated data structure 921 is associated with the first derived DID1.

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

[0131] Fig.10 A flow chart of an example method 1000 is illustrated for using an associated data structure corresponding to a derived decentralized identifier of a subject entity to share a verified claim about the subject entity to one or more dependent entities. The method 1000 includes deriving a DID for a subject entity (act 1001). The derived DID may be derived using an existing source DID. The details of deriving a new DID from an existing DID are described above with respect to Figure 6 describe.

[0132] Method 1000 also includes creating an associated data structure using the derived DID (act 1002). Many different embodiments may be implemented to generate an associated data structure. An example of how an associated data structure may be generated is described above with respect to Figure 8 describe.

[0133] After the associated data structure is generated, the verifiable assertion is caused to be provided to the relying entity (ACT 1003). The verified assertion includes the associated data structure. Figure 8 and Fig. 9 An example embodiment of how a verified derived statement 809 including an associated data structure is provided to a dependent entity 808 is illustrated. Figure 8 and Fig. 9 , the verified derived statement 809 may look similar to the example statement 900. The statement issuing entity 807 receives the associated data structure 806 and includes the associated data structure 806 into the derived statement 809. The derived statement 809 may then be sent directly from the statement issuing entity 807 to the dependent entity 808. Alternatively, the derived statement 809 may first be sent to the subject entity 801, which then sends the received derived statement 809 to the dependent entity 808.

[0134] Fig.11 A flowchart of an example method 1100 for causing a verified claim to be sent to a dependent entity is illustrated, which may correspond to act 1003 of method 1000. Method 1100 includes first causing an associated data structure to be sent to a claim issuing entity (act 1101). Figure 8 As illustrated, after association data structure 806 is generated, association data structure 806 is sent to claims issuing entity 807 .

[0135] After the claim issuing entity 807 receives the associated data structure 806, the claim issuing entity 807 includes the associated data structure in the verified claim (action 1102). Figure 8 As illustrated, including the associated data structure into the verified claim may be performed by claim issuing entity 807. Claim issuing entity 807 may generate derived claim 809 including associated data structure 806'.

[0136] The verified statement (e.g., derived statement 809) may then be sent to the subject entity 801 (action 1103). The receipt of the verified statement 809 by the subject entity 801 may then be detected (action 1103). Upon detecting receipt of the verified statement 809, the verified statement may then be caused to be sent to the relying entity 808 (action 1104).

[0137] The subject entity 801 may be the DID management module 402 of the derived DID 802. Figure 4 After the DID management module 402 receives the verified statement 407, the DID management module 402 may store the verified statement in the statement repository 408. In some embodiments, the statement repository 408 may send the verified statement 407 to the relying entity 808. In some embodiments, the DID management module 402 may directly send the verified statement 407 to the relying entity 808 before storing the verified statement anywhere. In some embodiments, the statement issuing entity 807 may directly send the verified statement to the relying entity 808.

[0138] Fig.12 A flow chart of an example method 1200 is illustrated for sharing a verified statement about a subject entity to one or more dependent entities using a message authentication code (MAC) corresponding to a derived decentralized identifier of the subject entity. Figure 8 As described, a MAC is an example association data structure that can be used to generate a privacy-preserving authenticated claim.

[0139] Method 1200 includes deriving a DID of a subject entity from a source DID of the subject entity (action 1201). There are many different ways to derive a DID of a subject entity. Using a source DID to derive a new DID is an example method for deriving a new DID. The details of how a new DID can be derived from a source DID are described above with respect to Figure 6Description. There are many benefits to using an existing DID as a source DID to derive a new DID. For example, it is easier to manage multiple linked DIDs than to manage multiple unrelated DIDs. The derived DID can be generated using a one-way deterministic hash function so that the derived DID can be recreated when necessary. Moreover, the derived DID can be used to assert a statement that is related to a statement about the source DID.

[0140] Method 1200 also includes calculating a seed based on the derived DID (act 1202). Figure 8 As described, the seed 804 can be generated from the one-way function 803. The function 803 can be a hash function or any function configured to generate the seed 804, as long as the generated seed 804 can at least resist dictionary attacks.

[0141] Based on the generated seed 803 and the derived DID 802, a message authentication code (MAC) can be generated (action 1203). The MAC can be generated using a keyed hash algorithm that uses a cryptographic hash function and a secret cryptographic key. The seed 803 can be used as the secret cryptographic key input, and the derived DID 802 can be used as the message input to generate the hash. The generated hash can be used again as the message input to generate the next hash. This process can be repeated as many times as desired to generate a secure MAC.

[0142] The secure MAC is then sent to the claim issuing entity (action 1204). The subject entity 801 may also send the source DID and other additional information along with the MAC to the claim issuing entity 807 so that the claim issuing entity 807 can verify the identity of the subject entity 801 and know what type of claim the subject entity needs.

[0143] After the entity of the subject entity 801 is authenticated, the claim issuing entity 807 is caused to issue a authenticated claim including a MAC (1205). The details of issuing an authenticated claim including an associated data structure (e.g., a MAC) are described above with respect to Figure 8 and 9 Description. Fig. 9 As illustrated, an associated data structure (eg, a MAC) may be included in an ID field of the authenticated claim 900 , and more than one associated data structure (eg, a MAC) may be included in the authenticated claim 900 .

[0144] The verified statement 900 may then be sent to the subject entity 801, and the subject entity 801 may receive the verified statement 900 from the statement issuing entity 807 (action 1206). The received verified statement 900 may then be sent to one or more dependent entities (action 1207). At substantially the same time, the subject entity 801 may also send the seed 804 and the derived DID 802 to the dependent entity 808, so that the dependent entity 808 may verify that the verified statement 900 is associated with the derived DID. Moreover, since the MAC is generated via a one-way cryptographic function, the statement issuing entity 807 cannot reversely find out what the derived DID is based on the MAC. Therefore, the privacy of the subject entity is protected not only by the dependent entities, but also by the statement issuing entity.

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

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

Claims

1. A computing system comprising: one or more processors; as well as One or more computer-readable storage devices having computer-executable instructions executable by the one or more processors to configure the computing system to perform a method for sharing a verified claim about a subject entity to one or more relying entities using an associated data structure corresponding to a derived decentralized identifier of the subject entity, the method comprising: deriving said decentralized identifier of the subject entity; creating an associated data structure using the derived decentralized identifier, the associated data structure including a message authentication code and structured to be interpretable by a relying entity as proving that a verified claim is about the derived decentralized identifier; and The verified claim about the principal entity is caused to be provided to the dependent entity, the verified claim including the created associated data structure.

2. The computing system of claim 1, wherein the verified claim is provided by a claim-issuing entity that is neither the principal entity nor the dependent entity.

3. The computing system of claim 2, wherein the derived decentralized identifier of the subject entity is derived from an existing source decentralized identifier, and the source decentralized identifier is associated with a previously issued verified claim issued by the claim issuing entity. 4 . The computing system of claim 3 , wherein the linked data structure is generated by one-way encoding such that the claims issuing entity cannot reconstruct the derived decentralized identifier from the linked data structure.

5. The computing system of claim 2, wherein causing the verified statement about the principal entity to be provided to the relying entity comprises: causing the associated data structure to be sent to the claims issuing entity; causing the claim issuing entity to include the associated data structure into the verified claim; detecting receipt of said verified claim including said associated data structure from said claim issuing entity; as well as The verified statement including the associated data structure is sent to the relying entity.

6. The computing system of claim 2, wherein the verified claim includes a first signature generated by the claim issuing entity, the first signature being used to authenticate that the verified claim is authorized by the claim issuing entity.

7. The computing system of claim 6, wherein the verified claim further comprises a second signature generated by the derived decentralized identifier, the second signature being used to authenticate that the verified claim is authorized by the derived decentralized identifier.

8. The computing system of claim 2, the method further comprising: deriving a second decentralized identifier of a subject entity from a source decentralized identifier of the subject entity; Another associated data structure is created using the derived second decentralized identifier, the another associated data structure being structured to be interpretable by a second relying entity as proving that the same verified claim is about the derived second decentralized identifier, the same verified claim being provided by the same claim issuing entity.

9. The computing system of claim 8, the method further comprising: The further associated data structure is sent to the same claim issuing entity so that the same claim issuing entity includes the further associated data structure into the verified claim.

10. The computing system of claim 9, the method further comprising: receiving said verified statement including both said associated data structure and said another associated data structure; as well as The received verified statement is sent to the second relying entity.

11. The computing system of claim 10, wherein sending the received verified claim to the second relying entity further comprises sending additional information to the second relying entity, the additional information allowing the second relying entity to interpret the another associated data structure as being associated with the derived second decentralized identifier.

12. A method implemented by a computing system in a decentralized network for sharing a verified statement about a subject entity to one or more dependent entities using an associated data structure corresponding to a derived decentralized identifier of the subject entity, the method comprising: generating a derived decentralized identifier of a subject entity from a source decentralized identifier of the subject entity, the source decentralized identifier comprising a source private key, and the derived decentralized identifier comprising a derived private key derived from the source private key; creating the associated data structure using the derived decentralized identifier, the associated data structure being structured to be interpretable by a relying entity as proving that a verified claim is about the derived decentralized identifier, the associated data structure being created by: applying the derived decentralized identifier as a first input to a first function to generate a seed as a first output from the first function, and then applying the seed and the derived decentralized identifier as second inputs to a second function to generate the associated data structure as a second output from the second function; as well as The verified claim about the principal entity is caused to be provided to the dependent entity, the verified claim including the created associated data structure.

13. The method of claim 12, wherein the associated data structure includes a message authentication code.

14. The method of claim 13, wherein the message authentication code is generated from a seed, the seed being generated using the derived decentralized identifier.

15. The method of claim 14, wherein the seed and the derived decentralized identifier are sent to the relying entity as additional information, enabling the relying entity to verify that the message authentication code corresponds to the derived decentralized identifier.

16. The method of claim 12, wherein the verified claim is provided by a claim-issuing entity that is neither the principal entity nor the relying entity.

17. The method of claim 16, wherein causing the verified assertion about the principal entity to be provided to the relying entity comprises: sending the associated data structure to the claim issuing entity so that the claim issuing entity includes the associated data structure in the verified claim; detecting receipt of the verified claim including the associated data structure from the claim issuing entity; as well as The verified statement including the associated data structure is sent to the relying entity.

18. The method of claim 16, wherein the linked data structure is generated by one-way encoding such that the claims issuing entity cannot reconstruct the derived decentralized identifier from the linked data structure.

19. The method of claim 18, wherein a message authentication code is generated from a seed, the seed being generated using the derived decentralized identifier; Wherein the seed and the derived decentralized identifier are sent to the relying entity such that the relying entity can verify that the message authentication code corresponds to the derived decentralized identifier.

20. A computing system comprising: one or more processors; as well as One or more computer-readable storage devices having computer-executable instructions executable by the one or more processors to configure the computing system to perform a method for sharing a verified claim about a subject entity to one or more relying entities using an associated data structure corresponding to a derived decentralized identifier of the subject entity, the method comprising: deriving said decentralized identifier of the subject entity; creating an associated data structure using the derived decentralized identifier, the associated data structure being structured to be interpretable by a relying entity as proving that a verified claim provided by a claim-issuing entity that is neither the subject entity nor the relying entity is about the derived decentralized identifier; and Cause the verified statement to be provided to the dependent entity through at least the following operations: cause the associated data structure to be sent to the statement-issuing entity, cause the statement-issuing entity to include the associated data structure in the verified statement, detect receipt of the verified statement including the associated data structure from the statement-issuing entity; and send the verified statement including the associated data structure to the dependent entity.

Images