Trusted Chain of Custody for Verifiable Claims

Abstract

A first chain of custody verifiable claim is received by the second entity from the first entity. The first chain of custody verifiable claim is signed by the first entity and specifies that the object was under the control of the first entity. The distributed ledger is accessed to verify the first chain of custody verifiable claim. A second chain of custody verifiable claim is generated, which embeds the first chain of custody verifiable claim and is signed by the second entity. The second chain of custody verifiable claim is recorded on the distributed ledger. The second chain of custody verifiable claim is provided to a third entity. The second chain of custody verifiable claim is configured to specify to the third entity that the object was under the control of the second entity.

Description

[Background technology]

[0001] Digital identity is a mechanism for tracking an entity across different digital contexts. Once an identity is determined, appropriate actions can be taken in relation to the entity with that identity. As an example, authorization, privileges, customization, and access can be provided to the entity. Digital identity is therefore a key mechanism for ensuring that authorizations and privileges are properly contained to restrict information to appropriate trust boundaries. Digital identity is also a key mechanism for ensuring a positive and consistent user experience when accessing data and customization.

[0002] Most identity-proving documents and records in use today are issued by centralized organizations, such as governments, companies, schools, employers, or other service centers or regulatory organizations. These organizations often maintain the identities of all their members in a centralized identity management system. A centralized identity management system is a centralized information system used by an organization to manage the issued identities, their authentications, authorizations, roles, and privileges. Centralized identity management systems are considered secure because they often use professionally maintained hardware and software. Typically, the identity-issuing organization sets the conditions and requirements for registering a person with the organization. When a party needs to verify the identity of another party, the verifying party must often go through the centralized identity management system to obtain information that verifies and / or authenticates the other party's identity.

[0003] A decentralized identifier (DID) is a newer type of identifier. A decentralized identifier is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) offers the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction has been recorded, the data in a section of the ledger cannot be retroactively changed without modifying all subsequent sections of the ledger. This provides a fairly secure platform where tampering with the data recorded on the distributed ledger is difficult or impossible. DIDs are sometimes referred to as non-authoritative identities because DIDs are typically not controlled by a centralized system and are owned by the owner of the DID.

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in such environments. Rather, this background is provided only to illustrate one example technology area in which 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] Computational techniques provide a data structure called a "verifiable claim or attestation." In these techniques, a claim issuer creates one or more claims about an object, generating a verifiable claim. The verifiable claim includes these claims, as well as attestation instructions to prove that the claims have not been tampered with and were in fact issued by the claim issuer. The verifiable claim often also includes duration information metadata that defines a period during which the use of the verifiable claim is valid, or defines a specific number of times the use of the verifiable claim is authorized. In a distributed environment, the verifiable claim also includes the DID of the claim issuer. The claim issuer then provides the verifiable claim to the claim holder for presentation to any relying parties that rely on the veracity of the claim.

[0007] As an example, a claim issuer may be a computing system associated with a government agency responsible for issuing driver's licenses. The government agency's computing system may generate verifiable claims that include claims about citizens, such as date of birth, residential address, weight, eye color, hair color, driving authorization, and driving authorization restrictions. The government agency's computing system issues the verifiable claims to citizens. If a citizen is stopped by law enforcement, the citizen's computing system may present the verifiable claim, which allows the law enforcement-related computing system to use attestation instructions to verify that the claim was issued by the government agency and has indeed not been tampered with since issuance. In another example, an organization that provides immunization computing systems may issue claims to parents of children that claim that their children have received certain vaccinations. The parents' computing systems may then present these immunization claims to the school the child attends. In the above example, the relying parties were the law enforcement agency and the school the child attends, more specifically the law enforcement agency and the school's computing system.

[0008] Some verifiable claims are directed to specific objects that are considered valuable and can be bought and sold by various entities. For example, such objects can be digital or physical works of art, or antiques such as furniture or cars. Thus, a first entity can create the object. Alternatively, the first entity can be an entity such as an art broker that can validate that the object is authentic. The first entity can then sell the object to a second entity. Because the second entity received the object from its creator or an entity such as an art broker, the second entity typically has a high degree of confidence that the object is authentic. However, at a later date, the second entity may choose to sell the object to a third entity, which may then sell the object to a fourth entity, and so on.

[0009] As the chain of custody from the first entity gets longer, it can become increasingly difficult for a purchasing entity to know if the object is authentic. For example, at some point an entity may attempt to sell a fraudulent version of the object. Or, an entity that does not own the object may attempt to claim that it does, and may attempt to use this to initiate a fraudulent sale. Often, the purchasing entity ends up with no way to verify if the object is authentic and if the selling entity owns it.

[0010] The embodiments presented herein provide a novel solution to the above-mentioned problem. The embodiments presented herein allow for the chain of custody of an object to be recorded on a distributed ledger. Each subsequent purchaser can then access and verify this chain of custody, which can help ensure that the object they are purchasing is authentic. For example, a first entity can generate a verifiable claim of the first chain of custody and then record this (or at least a representation of the verifiable claim) on the blockchain. When a second entity wishes to purchase the object, it can access the distributed ledger and verify the verifiable claim of the first chain of custody. Once the verifiable claim of the first chain of custody is verified, the second entity can have confidence that the object is authentic before purchasing it.

[0011] The second entity can then generate a second chain of custody verifiable claim that embeds the first chain of custody verifiable claim, which can then be recorded on the distributed ledger. If a third entity wishes to purchase the object, it can access the distributed ledger and verify both the second chain of custody verifiable claim and the embedded first chain of custody verifiable claim. Once the first and second chain of custody verifiable claims are verified, the third entity can have confidence that the object is authentic before purchasing it. The process of generating and embedding additional chain of custody verifiable claims and recording them on the distributed ledger can occur every time the ownership of the object changes, thus creating confidence for all subsequent purchasers.

[0012] In one embodiment, a first chain of custody verifiable claim is received by a second entity from a first entity. The first chain of custody verifiable claim is signed by the first entity and specifies that the object was under the custody of the first entity at the time the first chain of custody verifiable claim was received. The distributed ledger is accessed to verify the first chain of custody verifiable claim. A second chain of custody verifiable claim is generated. The second chain of custody verifiable claim has the first chain of custody verifiable claim embedded therein and is signed by the second entity. At least a portion of the second chain of custody verifiable claim is recorded in the distributed ledger. The second chain of custody verifiable claim is provided to a third entity. The second chain of custody verifiable claim is configured to specify to the third entity that the object was under the custody of the second entity at the time the second chain of custody verifiable claim was provided to the third entity.

[0013] In one embodiment, a first chain of custody verifiable claim relating to the object is received by a third entity from a first entity. The first chain of custody verifiable claim includes a first signature generated by the first entity and embeds a second chain of custody verifiable claim relating to the object received by the first entity from the second entity. The second chain of custody verifiable claim includes a second signature generated by the second entity. The distributed ledger is accessed to verify the first chain of custody verifiable claim. Validation of the first chain of custody verifiable claim indicates that the first entity had proper custody of the object at the time the first chain of custody verifiable claim was received by the third entity. Upon successful validation of the first chain of custody verifiable claim, the distributed ledger is accessed to verify the second chain of custody verifiable claim. Verification of the second chain of custody verifiable claim indicates that the second entity had proper control of the object at the time the second chain of custody verifiable claim was received by the first entity.

[0014] Additional features and advantages will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

[0015] To explain how the above and other advantages or features can be obtained, a more particular description of the subject matter briefly described above will be made by reference to specific embodiments that are illustrated in the accompanying drawings, with the understanding that these drawings depict only typical embodiments and therefore should not 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: [Brief description of the drawings]

[0016] [Figure 1] FIG. 1 illustrates an exemplary computing system in which the principles described herein may be employed. [Diagram 2] FIG. 1 illustrates an example environment for creating a distributed identification or identifier (DID). [Diagram 3] FIG. 1 illustrates an example environment for various DID management operations and services. [Figure 4] FIG. 1 illustrates an example of a distributed personal storage device or identity hub. [Diagram 5] FIG. 1 illustrates an example environment in which the principles described herein may be implemented. [Figure 6A] FIG. 13 is a diagram showing an example of a claim. [Figure 6B] FIG. 1 illustrates an example of a verifiable claim. [Figure 7A] FIG. 1 illustrates an example environment that can be used to record and verify the chain of custody in a distributed network. [Figure 7B] FIG. 1 illustrates an example of a claim of authenticity and chain of custody. [Figure 7C] FIG. 1 illustrates an example of a verifiable claim of a series of originating chain of custody. [Figure 7D] FIG. 1 illustrates another exemplary chain of custody claim. [Figure 7E] FIG. 1 illustrates an example of a chain of custody verifiable claim with an original chain of custody verifiable claim embedded therein. [Figure 7F] FIG. 1 illustrates another exemplary chain of custody claim. [Figure 7G] FIG. 2 illustrates an example of a chain of custody verifiable claim having an original chain of custody verifiable claim and another chain of custody verifiable claim embedded within it. [Figure 7H] FIG. 7B illustrates an alternative embodiment of the environment of FIG. 7A. [Figure 7I] FIG. 7B illustrates an alternative embodiment of the environment of FIG. 7A. [Figure 7J]FIG. 1 illustrates an example of a verifiable claim of a chain of custody that includes a repair verifiable claim. [Figure 7K] FIG. 1 illustrates an example of a chain of custody verifiable claim that includes an endorsement verifiable claim. [Figure 8] FIG. 1 illustrates an example flow for verifying multiple chain of custody verifiable claims. [Figure 9] FIG. 1 illustrates an alternative embodiment of a verifiable claim of chain of origin custody. [Figure 10] FIG. 1 illustrates a flowchart of an exemplary method for recording chain of custody in a distributed network implementing a distributed identifier (DID) backed by a distributed ledger. [Figure 11] FIG. 1 illustrates a flowchart of an exemplary method for verifying chain of custody in a distributed network implementing distributed identifiers (DIDs) backed by a distributed ledger. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] In one embodiment, a first chain of custody verifiable claim is received by a second entity from a first entity. The first chain of custody verifiable claim is signed by the first entity and specifies that the object was under the control of the first entity at the time the first chain of custody verifiable claim was received. The distributed ledger is accessed to verify the first chain of custody verifiable claim. A second chain of custody verifiable claim is generated. The second chain of custody verifiable claim has the first chain of custody verifiable claim embedded therein and is signed by the second entity. At least a portion of the second chain of custody verifiable claim is recorded in the distributed ledger. The second chain of custody verifiable claim is provided to a third entity. The second chain of custody verifiable claim is configured to specify to the third entity that the object was under the control of the second entity at the time the second chain of custody verifiable claim was provided to the third entity.

[0018] In one embodiment, a first chain of custody verifiable claim relating to the object is received by a third entity from a first entity. The first chain of custody verifiable claim includes a first signature generated by the first entity and embeds a second chain of custody verifiable claim relating to the object received by the first entity from the second entity. The second chain of custody verifiable claim includes a second signature generated by the second entity. The distributed ledger is accessed to verify the first chain of custody verifiable claim. Validation of the first chain of custody verifiable claim indicates that the first entity had proper control of the object at the time the first chain of custody verifiable claim was received by the third entity. Upon successful validation of the first chain of custody verifiable claim, the distributed ledger is accessed to verify the second chain of custody verifiable claim. Verification of the second chain of custody verifiable claim indicates that the second entity had proper control of the object at the time the second chain of custody verifiable claim was received by the first entity.

[0019] Because the principles described herein are implemented in the context of a computing system, some introductory discussion of a computing system is described with reference to Figure 1. The discussion then returns to the principles of the embodiments disclosed herein with respect to the remaining figures.

[0020] Computing systems now take on an increasingly wide variety of forms. A computing system may be, for example, a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or a device not traditionally thought of as a computing system, such as a wearable (e.g., glasses). In this description and in the claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) that includes at least one physical and tangible processor and physical and tangible memory capable of having computer-executable instructions executed by the processor. The memory may take any form, depending on the nature and type of the computing system. A computing system may be distributed over a network environment and include multiple constituent computing systems.

[0021] As shown in FIG. 1, in its most basic configuration, a computing system 100 typically includes at least one hardware processing unit 102 and memory 104. The hardware processing unit 102 includes a general-purpose processor, but also includes a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuitry. The memory 104 is the physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" is also used herein to refer to non-volatile mass storage devices, such as physical storage media. When a computing system is distributed, the functions of processing, memory, and storage are also distributed.

[0022] Computing system 100 also has a number of structures thereon, often referred to as "executable components." For example, memory 104 of computing system 100 is shown as including executable component 106. The term "executable component" is a name for a structure that is well understood by those skilled in the computing arts as a structure that may be software, hardware, or a combination thereof. For example, when implemented in software, those skilled in the art will understand that the structure of an executable component includes software objects, routines, methods, etc., that execute on a computing system, and whether such an executable component resides on the heap of a computing system, or whether the executable component resides on a computer-readable storage medium.

[0023] In such cases, those skilled in the art will recognize that the structure of the executable component resides on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by processor threads), the functions are executed on the computing system. Such structure is directly computer readable by the processor (as would be the case if the executable component were binary). Alternatively, the structure is structured to be interpretable and / or compiled (in a single stage or multiple stages) to generate such binary directly interpretable by the processor. Such understanding of example structures of executable components is well within the understanding of those skilled in the computing arts when using the term "executable component."

[0024] The term "executable component" is also well understood by those skilled in the art to include structures such as hard-coded or wired logic gates that are implemented exclusively or nearly exclusively in hardware, such as in a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or any other specialized circuit. Thus, the term "executable component" is a term that describes structures that are well understood by those skilled in the computing arts, whether implemented in software, hardware, or a combination thereof. In this description, terms such as "component," "agent," "manager," "service," "engine," "module," "virtual machine," and the like are also used. As used in this description and examples, these terms are also intended to be synonymous with the term "executable component" (with or without modifiers) and thus also have structures that are well understood by those skilled in the computing arts.

[0025] In the following description, the embodiments are described with reference to acts performed by one or more computing systems. When such acts are implemented in software, one or more processors (of the relevant computing systems performing the acts) direct the operation of the computing systems in response to execution of computer-executable instructions that constitute the executable components. For example, such computer-executable instructions are embodied on one or more computer-readable media that form a computer program product. Examples of such acts include the manipulation of data. When such acts are implemented exclusively or nearly exclusively in hardware, such as in an FPGA or ASIC, the computer-executable instructions are hard-coded or wired logic gates. The computer-executable instructions (and the data that is manipulated) are stored in memory 104 of computing system 100. Computing system 100 also includes a communication channel 108 that allows computing system 100 to communicate with other computing systems, for example, via network 110.

[0026] Although not all computing systems require a user interface, in some embodiments, the computing system 100 includes a user interface system 112 for use in interfacing with a user. The user interface system 112 includes an output mechanism 112A and an input mechanism 112B. The principles described herein are not limited to the exact output mechanism 112A or input mechanism 112B, which as such depends on the nature of the device. However, the output mechanism 112A may include, for example, a speaker, a display, a tactile output, a hologram, and the like. Examples of the input mechanism 112B may include, for example, a microphone, a touch screen, a hologram, a camera, a keyboard, a mouse or other pointer input, any type of sensor, and the like. The embodiments described herein comprise or utilize a dedicated or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as described in more detail below. The embodiments described herein also include physical media and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media that can be accessed by a general-purpose or dedicated computing system. A computer-readable medium that stores computer-executable instructions is a physical storage medium. A computer-readable medium that carries computer-executable instructions is a transmission medium. Thus, by way of example and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.

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

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

[0029] Furthermore, upon reaching the various computing system components, program code means in the form of computer-executable instructions or data structures may be automatically transferred from a transmission medium to a storage medium (or vice versa). For example, computer-executable instructions or data structures received over a network or data link may be buffered in RAM in a network interface module (e.g., a "NIC") and eventually transferred to the computing system's RAM and / or to a less volatile storage medium of the computing system. It should thus be understood that storage media may be included in computing system components that also (or primarily) utilize transmission media.

[0030] Computer-executable instructions include, for example, instructions and data that, when executed by a processor, cause a general-purpose computing system, special-purpose computing system, or special-purpose processing device to perform a particular function or group of functions. Alternatively, or in addition, computer-executable instructions configure a computing system to perform a particular function or group of functions. Computer-executable instructions may be, for example, binaries, or instructions that have undergone some transformation (e.g., compilation) before being executed directly by a processor (e.g., intermediate format instructions such as assembly language, or source code).

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

[0032] Those skilled in the art will appreciate that the present invention may be implemented in a networked computing environment with many types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, cell phones, PDAs, pagers, routers, switches, data centers, wearables (such as glasses), and the like. In some cases, the present invention may also be implemented in a distributed system environment in which local and remote computing systems are linked through a network (by wired data links, wireless data links, or a combination of wired and wireless data links) and both perform tasks. In a distributed system environment, program modules are located in both local and remote memory storage devices.

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

[0034] The remaining figures describe various computing systems corresponding to the computing system 100 described above. The computing systems of the remaining figures include various components or functional blocks that implement various embodiments disclosed herein, as described below. The various components or functional blocks are implemented on a local computing system or on a distributed computing system that includes elements that reside in the cloud or that implement aspects of cloud computing. The various components or functional blocks are implemented as software, hardware, or a combination of software and hardware. The computing systems of the remaining figures include more or fewer components than those shown in the figures, and some of the components are combined depending on the circumstances. Although not necessarily shown, the various components of the computing systems access and / or utilize processors and memory, such as processing unit 102 and memory 104, as necessary to perform their various functions.

[0035] Some introductory discussion of distributed identities (DIDs) and the environment in which they are created and exist will now be given with reference to Figure 2, which shows a distributed network 200. As shown in Figure 2, a DID owner 201 owns or controls a DID 205 that represents the identity of the DID owner 201. The DID owner 201 registers the DID using a creation and registration service, which will be described in more detail below.

[0036] A DID owner 201 is any entity that can benefit from a DID. For example, a DID owner 201 is a human being or a human organization. Such organizations may include a company, a department, a government, an agency, or any other organization or group of organizations. Individual humans may have DIDs, while organizations to which each person belongs may have DIDs as well.

[0037] Alternatively, the DID Owner 201 is a machine, system, or device, or a collection of machines, devices, and / or systems. In yet other embodiments, the DID Owner 201 is a subpart of a machine, system, or device. For example, the device may be a printed circuit board, and the subparts of that circuit board are the individual components of the circuit board. In such embodiments, the machine or device has a DID, and each subpart also has a DID. The DID Owner may also be a software component, such as the executable component 106 described above with respect to FIG. 1. An example of a complex executable component 106 may be an artificial intelligence. The artificial intelligence also owns a DID.

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

[0039] As mentioned above, a DID owner 201 creates and registers a DID 205. A DID 205 is any identifier associated with a DID owner 201. Preferably, the identifier is unique to that DID owner 201, at least within the scope in which the DID is expected to be used. As an example, the identifier is a locally unique identifier, perhaps more desirably a globally unique identifier for an identity system expected to operate globally. In some embodiments, the DID 205 is a Uniform Resource Identifier (URI) (such as a Uniform Resource Locator (URL)) or other pointer that associates the DID owner 201 with a mechanism for trusted interaction with the DID owner 201.

[0040] DIDs 205 are "decentralized" because they do not require a centralized third-party management system for their generation, management, or use. Thus, DIDs 205 remain under the control of the DID owner 201. This differs from traditional centralized IDs based on trust in a centralized authority, which is under the control of an enterprise directory service, certification authority, domain name registry, or other centralized authority (collectively referred to herein as a "centralized authority"). Thus, DIDs 205 are arbitrary identifiers that are under the control of the DID owner 201 and independent of any centralized authority.

[0041] In some embodiments, the structure of the DID 205 is as simple as a username or other human understandable term. However, in other embodiments, the DID 205 is preferably a random string of numbers and letters to increase security. In one embodiment, the DID 205 is a string of 128 letters and numbers. Thus, the embodiments disclosed herein are not dependent on any particular implementation of the DID 205. In a very simple example, the DID 205 is shown as "123ABC".

[0042] As also shown in Figure 2, the DID owner 201 controls the private key 206 and public key 207 pair associated with the DID 205. Since the DID 205 is independent of any central authority, the private key 206 must always be fully controlled by the DID owner 201. That is, the private and public keys must be generated in a decentralized way to ensure that they remain under the control of the DID owner 201.

[0043] As described in more detail below, the private key 206 and public key 207 pair is generated on a device controlled by the DID owner 201. The private key 206 and public key 207 pair should not be generated on a server controlled by a central authority, as this would ensure that the private key 206 and public key 207 pair is not under the full control of the DID owner 201 at all times. It should also be noted that while FIG. 2 and this description describe a private key and public key pair, other types of reasonable encryption information and / or mechanisms may also be used, depending on the circumstances.

[0044] FIG. 2 also shows a DID document 210 associated with the DID 205. As described in more detail below, the DID document 210 is generated upon creation of the DID 205. In its simplest form, the DID document 210 describes how the DID 205 is used. Thus, the DID document 210 includes a reference to the DID 205, which is the DID described by the DID document 210. In some embodiments, the DID document 210 is implemented according to a method specified by a distributed ledger 220 used to store a representation of the DID 205, as described in more detail below. Thus, the DID document 210 has different methods depending on the particular distributed ledger.

[0045] The DID document 210 also contains a public key 207, or other equivalent cryptographic information, created by the DID owner 201. The public key 207 is used by third party entities authorized by the DID owner 201 to access information and data owned by the DID owner 201. The public key 207 is also used by verifying that the DID owner 201 actually owns or controls the DID 205.

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

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

[0048] Authorization information 212 also specifies one or more mechanisms that a third party must follow to prove that they are authorized to modify DID document 210. In some embodiments, the mechanisms are similar to those described above with respect to authentication information 211.

[0049] The DID document 210 also includes one or more service endpoints 213. The service endpoints include network addresses at which services act on behalf of the DID owner 201. Examples of specific services include discovery services, social networks, file storage services such as identity servers or hubs, and verifiable claims repository services. The service endpoints 213 thus act as pointers to services acting on behalf of the DID owner 201. These pointers are used by the DID owner 201 or third-party entities to access the services acting on behalf of the DID owner 201. Specific examples of service endpoints 213 are described in more detail below.

[0050] The DID document 210 further includes identification information 214. The identification information 214 includes personally identifiable information such as the name, address, occupation, family structure, age, hobbies, and interests of the DID owner 201. Thus, the identification information 214 listed in the DID document 210 represents different personas of the DID owner 201 for different purposes. For example, the personas are pseudo-anonymous. For example, the DID owner 201 includes a pen name in the DID document when identifying himself as a writer who posts articles to a blog. The personas are completely anonymous, for example, the DID owner 201 only wants to disclose his job title and other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.), but does not want to disclose his name in the DID document. The personas identify who the DID owner 201 is as an individual. For example, the DID owner 201 includes information identifying himself as a volunteer for a particular charity organization, an employee of a particular company, a recipient of a particular award, etc.

[0051] The DID document 210 also includes credential information 215, which may also be referred to herein as evidence. Certification information 215 (also referred to as a verifiable claim) is any information associated with the background of the DID owner 201. For example, credential information 215 may be (but is not limited to) qualifications, achievements, government entitlements such as government ID, passport or driver's license, digital asset provider or bank account, college degree or other educational history, employment status or career, or any other information regarding the background of the DID owner 201.

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

[0053] 2 also illustrates a distributed ledger or blockchain 220. Distributed ledger 220 is any decentralized distributed network that includes various computing systems that communicate with each other. For example, distributed ledger 220 includes a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems, as illustrated by oval 260. Distributed ledger or blockchain 220 operates according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers that correspond to distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0054] In the context of DIDs 205, a distributed ledger or blockchain 220 is used to store a representation of the DIDs 205 that refers to the DID documents 210. In some embodiments, the DID documents 210 are actually stored in a distributed ledger. Alternatively, in other embodiments, the DID documents 210 are stored in a data store (not shown) associated with the distributed ledger or blockchain 220.

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

[0056] In one embodiment, when the DID owner 201 creates the DID 205 and the associated DID document 210, the DID has 231, the DID has 241, and the DID hash 251 are written to the distributed ledger or blockchain 220. Thus, the distributed ledger or blockchain 220 records that the DID 205 currently exists. Because the distributed ledger or blockchain 220 is decentralized, the DID 205 is not under the control of any entity outside the DID owner 201. The DID hash 231, the DID has 241, and the DID has 251 contain a pointer to the DID document 210, as well as a record or timestamp specifying when the DID 205 was created. At a later date, when changes are made to the DID document 210, this also records that the DID has 231, the DID has 241, and the DID has 251. The DID has 231 , the DID has 241 , and the DID hash 251 further includes a copy of the public key 207 such that the DID 205 is cryptographically bound to the DID document 210 .

[0057] Having described DIDs and how they generally operate with reference to Figure 2, a particular embodiment of a DID environment will now be described. With reference to Figure 3, a computing system environment 300 that may be used to perform various DID management operations and services will now be described. It will be understood that the environment of Figure 3 references elements of Figure 2 as necessary for ease of explanation.

[0058] As shown in Figure 3, computing system environment 300 includes various devices and computing systems owned or otherwise under the control of DID owner 201. These include user device 301. User device 301 is any device, such as, but not limited to, a mobile device such as a smartphone, a computing device such as a laptop computer, or an automobile or appliance that includes computing capabilities. User device 301 includes a web browser 302 that runs on the device and an operating system 303 that operates the device. More broadly, dashed line 304 represents that all of these devices are owned or otherwise under the control of DID owner 201.

[0059] The computing system environment 300 also includes a DID management module 320. Note that in operation, the DID management module 320 resides on and is executed by one or more of the user device 301, the web browser 302, and the operating system 303, as indicated by respective lines 301a, 302a, and 303a. Thus, for ease of explanation, the DID management module 320 is shown as separate. In some embodiments, the DID management module 320 is referred to as a "digital wallet" or a "user agent." However, one skilled in the art will appreciate that in other embodiments, a digital wallet or a user agent may be implemented in a computing system other than the DID management module 320.

[0060] 3, the DID management module 320 includes a DID creation module 330. The DID creation module 330 is used by the DID owner 201 to create the DID 205, or any number of additional DIDs, such as DID 331. In one embodiment, the DID creation module includes or is otherwise accessible to a user interface (UI) element 335 that guides the DID owner 201 in creating the DID 205. The DID creation module 330 has one or more drivers configured to interface with a particular distributed ledger, such as the distributed ledger 220, such that the DID 205 conforms to the methodology underlying that distributed ledger.

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

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

[0063] During operation, the DID creation module 330 accesses a registrar 310 configured for a particular distributed ledger that records transactions related to the DID 205. The DID creation module 330 uses the registrar 310 to record the DID hash 231, the DID hash 241, and the DID hash 251 in the distributed ledger in the manner described above, and stores the DID document 210 in the manner described above. In this process, the public key 207 is used to generate the hash.

[0064] In some embodiments, the DID management module 320 includes an ownership module 340. The ownership module 340 provides a mechanism to ensure that the DID owner 201 has sole control over the DID 205. In this way, the provider of the DID management module 320 can ensure that they do not control the DID 205, but only provide management services.

[0065] As mentioned above, the key generation module 350 generates a pair of private key 206 and public key 207, which is then recorded in the DID document 210. The public key 207 is therefore available to all devices associated with the DID owner 201, and to all third parties wishing to provide services to the DID owner 201. Thus, if the DID owner 201 wishes to associate a new device with the DID 205, the DID owner 201 executes the DID creation module 330 on the new device. The DID creation module 330 then uses the registrar 310 to update the DID document 210 to reflect that the new device is now associated with the DID 205, which update will be reflected in the transaction on the distributed ledger 220, as mentioned above. However, in some embodiments, it is advantageous to have a public key for each user device 301 that the DID owner 201 owns, as this allows the DID owner 201 to sign with a device-specific public key without needing access to a general public key. In other words, because the DID owner 201 uses different devices at different times (e.g., a cell phone in one instance and then a laptop computer in another instance), it is advantageous to associate a key with each device to streamline signing using the key. Thus, in such an embodiment, the key generation module 350 generates additional public keys 208 and 209 as the additional devices execute the DID creation module 330. These additional public keys are associated with the private key 206 or, in some cases, paired with a new private key.

[0066] In embodiments where the additional public keys 208 and 209 are associated with different devices, the additional public keys 208 and 209 are recorded in the DID document 210 as being associated with those devices. This is illustrated in Figure 3. It will be appreciated that the DID document 210 will often include the information described above in relation to Figure 2 (information 205, 207, and 211 to 216) in addition to the information illustrated in Figure 3 (information 208, 209, and 365). If the DID document 210 existed before the device-specific public keys were generated, the DID document 210 will be updated by the DID creation module 330 via the registrar 310, which will be reflected in the updated transactions on the distributed ledger 220.

[0067] In some embodiments, the DID owner 201 often desires to keep the association of the device with the public key or the association of the device with the DID 205 private. Thus, the DID creation module 330 ensures that such data is represented privately in the DID document 210.

[0068] As explained so far, the DID 205 is associated with all devices under the control of the DID owner 201, even if the 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 the DID owner 201 to have their own DID. Thus, in some embodiments, the DID creation module 330 generates an additional DID for each device, e.g., DID 331. The DID creation module 330 then generates a private-public key pair and a DID document for each device and records them in the distributed ledger 220 in the manner described above. Such an embodiment is advantageous for devices that change ownership, since the device-specific DID can be associated with the new owner of the device by granting authorization rights in the DID document to the new owner and revoking such rights from the old owner.

[0069] As mentioned above, to ensure that the private key 206 is entirely under the control of the DID owner 201, the private key 206 is created on a user device 301, web browser 302, or operating system 303 owned or controlled by the DID owner 201 that executed the DID management module 320. In this way, there is little chance that a third party (and most consequentially, the provider of the DID management module 320) will gain control of the private key 206.

[0070] However, the device storing the private key 206 may be lost by the DID owner 201, resulting in the DID owner 201 losing access to the DID 205. Thus, in some embodiments, the UI 335 includes an option that allows the DID owner 201 to export the private key 206 to an off-device secured database 305 under the control of the DID owner 201. As an example, the database 305 is one of the identity hubs 410 described below with respect to FIG. 4. The storage module 380 is configured to store data (such as the private key 206 or the certificate information 215 created by or for the DID owner 201) in the database 305 off-device or in the identity hub 410 described in more detail below. Of course, in some embodiments, the storage module 380 stores at least some data on the device if the device has sufficient storage resources. In some embodiments, the private key 206 is stored as a QR code that is scanned by the DID owner 201.

[0071] In other embodiments, the DID management module 320 includes a recovery module 360 ​​that is used to recover a lost private key 206. In operation, the recovery module 360 ​​allows the DID owner 201 to select, at the time of creation of the DID 205, one or more recovery mechanisms 365 that are later used to recover a lost private key. In those embodiments having a UI 335, the UI 335 allows the DID owner 201 to provide information that is used by the one or more recovery mechanisms 365 during recovery. The recovery module 360 ​​runs on any device associated with the DID 205.

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

[0073] 4 illustrates an embodiment of a computing system environment 400 in which DIDs, such as DID 205, are utilized. Specifically, computing system environment 400 is used to describe the use of DIDs 205 in association with one or more distributed stores or identity hubs 410, each of which is under the control of and stores data belonging to or relating to DID owner 201. For example, data is stored in an identity hub using storage module 380 of FIG. 3. Note that FIG. 4 includes references to elements first described in connection with FIG. 2 or FIG. 3, and thus the same reference numbers are used for ease of description.

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

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

[0076] However, identity hubs 413 and 414 may have less memory space. Thus, these identity hubs contain descriptors of the data stored in the first and second identity hubs, or records of changes made to data in the other identity hubs. Thus, a change in one of identity hubs 410 is either fully replicated in the other identity hub, or at least a record or descriptor of that data is recorded in the other identity hub.

[0077] Since identity hubs are multiple instances of the same identity hub, only a complete description of the first identity hub 411 is provided as this description also applies to identity hubs 412-414. As shown, identity hub 411 includes a data store 420. Data store 420 is used to store any type of data associated with DID owner 201. In one embodiment, the data is a collection 422 of a particular type of data corresponding to a particular protocol. For example, collection 422 may be medical record data corresponding to a particular protocol of medical data. Collection 422 may also include other types of data, such as certificate information 215 created by or for DID owner 201.

[0078] In one embodiment, the stored data has different authentication and privacy settings 421 associated with the stored data. For example, a first subset of data has settings 421 that allow the data to be published but does not include authentication to the DID owner 201. This type of data is typically for less sensitive data such as color schemes. A second subset of data has settings 421 that allow the data to be published and includes authentication to the DID owner 201. A third subset of data has settings 421 that encrypt the subset of data using a private key 206 and public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data requires a party to have access to the public key 207 (or other relevant public key) to decrypt the data. This process also includes authentication to the DID owner 201. A fourth subset of data has settings 421 that restrict this data to a subset of third parties. This requires the use of a public key associated with a subset of third parties to decrypt the data. For example, the DID owner 201 has the settings 421 specify that only public keys associated with friends of the DID owner 201 can decrypt this data. With respect to the data stored by the storage module 380, these settings 421 are configured at least in part by the storage module 380 of FIG.

[0079] In some embodiments, identity hub 411 has a permission module 430 that allows DID owner 201 to set specific authorizations or permissions for third parties, such as third parties 401 and 402, to access the identity hub. For example, DID owner 201 grants access permission to his / her spouse to all data stored in data storage 420. Or, DID owner 201 grants access to his / her doctor to any medical records. It will be appreciated that DID owner 201 can grant permission to any number of third parties to access a subset of the data stored in data storage 420, as will be described in more detail below. With respect to data stored by storage module 380, these access permissions 430 are configured at least in part by storage module 380 of FIG.

[0080] Identity hub 411 also includes messaging module 440. In operation, messaging module enables identity hub 411 to receive messages, such as requests from parties, such as third parties 401 and 402, to access the identity hub's data and services. Additionally, messaging module 440 enables identity hub 411 to respond to messages from third parties and communicate with DID resolver 450, which is described in more detail below. Ellipsis 416 represents that identity hub 411 may have additional services, depending on the circumstances.

[0081] In one embodiment, the DID owner 201 wants to authenticate the new user device 301 with an identity hub 411 that is already associated with a DID 205 in the manner described above. Thus, the DID owner 201 utilizes the DID management module 320 associated with the new user device 301 to send a message to the identity hub 411 claiming that the new user device is associated with the DID owner's 201's DID 205.

[0082] However, the identity hub 411 is initially unable to recognize the new device as being owned by the DID owner 201. Therefore, the identity hub 411 contacts the DID resolver 450 using the messaging module 440. The message sent to the DID resolver 450 includes the DID 205.

[0083] The DID resolver 450 is a service, application, or module that is configured in operation to search the distributed ledger 220 for a DID document associated with a DID. Thus, in this embodiment, the DID resolver 450 searches the distributed ledger 220 using the DID 205, which would result in the DID resolver 450 finding the DID document 210. The DID document 210 is then provided to the identity hub 411.

[0084] As previously mentioned, the DID document 210 includes the public key 208 or 209 associated with the new user device 301. To verify that the new user device is owned by the DID owner 201, the identity hub 411 uses the messaging module 440 to provide a cryptographic challenge to the new user device 301. This cryptographic challenge is configured such that only devices with access to the private key 206 can successfully answer the challenge.

[0085] In this embodiment, the challenge is answered successfully because the new user device is owned by the DID owner 201 and therefore has access to the private key 206. The identity hub 411 then records in the authorization 430 that the new user device 301 can access the data and services of the identity hub 411, as well as the rest of the identity hub 410.

[0086] Note that this process of authenticating the new user device 301 was performed without the DID owner 201 having to provide a username, password, etc. to the provider of the identity hub 411 (i.e., the first cloud storage provider) before the identity hub 411 could be accessed. Rather, access was determined in a distributed manner based on the DID 205, the DID document 210, and the associated public and private keys. Because these were always under the control of the DID owner 201, the provider of the identity hub 411 was not involved and therefore has no knowledge of the transactions or personal information of the DID owner 201.

[0087] In another exemplary embodiment, the DID owner 201 provides the DID 205 to the third party 401 to allow the third party to access data or services stored in the identity hub 411. For example, the DID owner 201 is a human attending a scientific conference who wants to allow the third party 401, also a human, access to his or her research data. Thus, the DID owner 201 provides the DID 205 to the third party 401.

[0088] Once the third party 401 has access to the DID 205, it accesses the DID resolver 450 to access the DID document 210. As mentioned above, the DID document 210 includes a service endpoint 213, which is an address or pointer to a service associated with the distributed identity. Upon completing the research data example, the third party 401 sends a message to the messaging module 440 asking for permission to access the research data. The messaging module 440 sends a message to the DID owner 201 asking whether the third party 401 should be given access to the research data. Since the DID owner wants to provide access to this data, the DID owner 201 allows permission to the third party 401, which is recorded in the permission 430. The messaging module 440 then sends a message to the third party 401 informing it that the third party can access the research data. The identity hub 411 and the third party 401 communicate directly to allow the third party to access the data. Note that in many cases, it is actually the identity hub associated with the third party 401 that communicates with the identity hub 411. However, it may also be the device of the third party 401 that initiates the communication. Advantageously, the process described above allows the identity hub 411 and the third party 401 to communicate and share data without the third party needing to access the identity hub 411 in the traditional manner. Rather, the communication is provisioned in a decentralized manner using the DIDs 205 and DID documents 210. This has the advantage that the DID owner has full control over the process.

[0089] 4, a third party 402 also uses a DID 205 and a DID document 210 to request permission to access an identity hub 411. Thus, the embodiments disclosed herein enable access to the identity hub 410 by any number of third parties.

[0090] As briefly described above, the identity hub 411 is hosted on a cloud service. The service provider has access to the data stored in the identity hub 411 for each user. In addition, the service provider also has access to certain activities of the DID owner. For example, entities with which the DID owner shares their data are stored in the identity hub 411. As another example, the user has multiple DIDs and shares data among the multiple DIDs. Alternatively, the user uses different DID management modules to access the same data. Based on the data sharing activity, the service provider of the identity hub 411 correlates the relationship of the different DIDs and discovers that the two DIDs are related or owned by the same owner. Thus, the user's privacy is violated. The principles described herein solve these potential privacy issues for the DID owner by encrypting the personal data stored in the identity hub 411. The encryption / decryption keys are not stored and cannot be accessed by the identity hub 411, so the DID owner not only has a high degree of control over the data from other DID owners or users, but also has privacy protection from the service provider.

[0091] There are many different objects stored in the identity hub 411. A data object is a file, folder, or any piece of data stored in the identity hub 411. The entire identity hub 411 may be encrypted as an object with one encryption / decryption key. Alternatively, different pieces of data stored in the identity hub 411 may be encrypted with different encryption / decryption keys.

[0092] In another exemplary embodiment, a verifiable claim (e.g., certificate information 215) is issued and stored in identity hub 411. For example, a verifiable claim associated with DID owner 201 is issued by a claim issuing entity, and the issued verifiable claim is stored in identity hub 411 associated with DID owner 201. DID owner 201 sends the verifiable claim to another entity when the other entity requests to verify the DID owner's certificate. For example, DID owner 201 is a person who holds a driver's license, and the claim issuing entity is the DMV that issued the DID owner's driver's license. The DMV issues a verifiable claim verifying that DID owner 201 holds a valid driver's license. DID owner 201 stores the verifiable claim in identity hub 411. Another entity is a rental car company, which requests that DID owner 201 demonstrate that he has a valid driver's license. The DID owner then sends the verifiable claim stored in identity hub 411 to the rental car company.

[0093] Having described DIDs and how they generally operate with reference to Figures 2-4, a specific embodiment of distributed identity will now be described. With reference to Figure 5, a distributed environment 500 will now be described that enables DID owners to access services and conduct transactions with other DID owners while identifying themselves. It will be understood that for ease of explanation, Figure 5 refers to elements of Figures 2-4 as necessary.

[0094] As shown in Figure 5, distributed environment 500 includes devices associated with service provider 510 and wallet apps 521 and 522 for users 520 and 530 (e.g., DID owners). Ellipsis 540 represents that there may be any number of devices associated with any number of service providers and / or users in distributed environment 500. Each of the service provider and users 520, 530 corresponds to DID owner 201 of Figure 2. Wallet apps 521 or 531 correspond to DID management module 320 of Figure 3. Identity hub 522 or identity hub 532 corresponds to identity hub 411 of Figure 4.

[0095] User 520 uses wallet app 521 to manage his / her DID, and user 530 uses wallet app 531 to manage his / her DID. Wallet app 521 or 531 is connected to a respective identity hub 522 or 531. Each of service provider device 510 and wallet app 521, 531 can access the distributed ledger via computer network 550. In some embodiments, wallet app 521 or 531 can access the distributed ledger indirectly via identity hub 522 or 532. In some embodiments, wallet app 521 or 531 is configured to store a full copy of the distributed ledger or can directly access the distributed ledger via computer network 550.

[0096] The service provider 510 device and each wallet app 521, 531 and / or ID hub 522, 532 can communicate with each other through various communication channels, including, but not limited to, local area networks, wide area networks, BLE beacon signals, and / or near field communication (NFC). Communication can also be performed by generating a barcode or QR code by one wallet app 521 and scanning the barcode or QR code by another wallet app 531 or service provider 510 device. The barcode or QR code includes identifying information related to the user 520, such as a DID associated with the user 520. In some embodiments, the service 510 can act as an issuer or relying party. As used herein, an "issuer" is an entity that makes at least one assertion about a subject. The assertion is also referred to herein as a "claim." A "certificate" is a set of one or more claims. Examples of issuers include a business, organization, association, government, agency, individual, or any other entity that can make a claim that others can trust. Thus, service 510 may provide one or more verifiable claims or certificates regarding user 520 or user 530, for which such instance serves as a "holder." Users 520 and 530 may store verifiable claims in identity hub 522 and identity hub 532, respectively. As used herein, a "relying party" is a party that relies on a verifiable claim or certificate to verify information about the holder and then provides a service to the holder.

[0097] For example, assume that the service 510 is the Department of Motor Vehicles (DMV). While acting as an "issuer," the service 510 issues a verifiable claim to the user 520 asserting that the user 520 has a valid driver's license issued by the DMV. The user 520, as the "holder," can then provide the verifiable claim associated with the driver's license to an intermediate party that requires this information. Assume that the relying party (as noted above, in some embodiments the service 510 can be a relying party, but is not shown in this embodiment) is a rental car agency. The user 520 presents the verifiable claim associated with the driver's license to the rental car agency when he or she wishes to rent a car and the rental car agency can use the verifiable claim associated with the driver's license to verify that the user 520 has a valid driver's license that can be used to rent a car.

[0098] 6A shows an example data structure representing a claim 610. The claim 610 includes a subject 611, properties 612, and a value 613. For example, the subject 611 corresponds to an owner of a DID (e.g., DID owner 201), and a DID 611A corresponding to a DID 205 is recorded as part of the subject 611. The properties 612 can be any property of the owner of the DID 611A, such as a name, a phone number, an email address, etc. The value 613 is the value of the corresponding property 612. For example, if the property is "name", the value would be the name of the owner of the DID (e.g., JohnDoe). If the property is "phone number", the value would be the phone number of the owner of the DID (e.g., 1-800-123-4567).

[0099] FIG. 6B illustrates an example data structure for a verifiable claim or certificate 600B. In some embodiments, the data structure for a verifiable claim or certificate is referred to as a portable identity card (PIC), which is a way for an issuer (e.g., service 510) to organize verifiable claims or certificates in a way that is easily understandable by a user (e.g., user 520 or user 530). The verifiable claim or certificate 600B includes a claim 610 that corresponds to claim 610 of FIG. 6A and includes a DID 611A. The verifiable claim or certificate 600B also includes a signature 630 that is generated by signing the verifiable claim or certificate 600B with the issuer's private key. The signature 630 is typically a cryptographic mechanism (e.g., a digital signature) used to detect whether the verifiable claim or certificate 600B has been tampered with since the verifiable claim or certificate 600B was issued, and can be used to verify the identity of the issuer of the verifiable claim or certificate 600B.

[0100] Once the verifiable claim or certificate 600B is generated, at least a portion of the data associated with the verifiable claim or certificate 600B is propagated to a distributed ledger (e.g., 220, 560) such that a trusted entity can verify the verifiable claim or certificate 600B using the portion of the data propagated onto the distributed ledger. In some embodiments, a public key corresponding to the issuer's private key is propagated onto the distributed ledger. In some embodiments, a hash of the public key, or a hash of the verifiable claim or certificate 600B, is propagated onto the distributed ledger.

[0101] In some embodiments, the verifiable claim or certificate 600B also includes various metadata 620 associated with the verifiable claim or certificate 600B. For example, the metadata may include, but is not limited to, (1) a unique identifier 621 that identifies the corresponding verified claim or certificate, (2) one or more conditions 622 for accessing the verifiable claim or certificate 600B, or (3) duration information metadata 623 associated with the duration the issuer desires the verifiable claim or certificate 600B to be valid or usable.

[0102] The one or more conditions metadata 622 for accessing the verifiable claim or certificate 600B may include, but are not limited to, (1) requiring the trusted entity to pay a predetermined amount of cryptocurrency or type of currency, (2) requiring the trusted entity to provide identifying information, (3) requiring the trusted entity to provide one or more verifiable claims, (4) requiring the trusted entity to grant permission to access a portion of the data, and / or (5) requiring the trusted entity to provide a particular service.

[0103] Duration information metadata 623 may include, but is not limited to, (1) an expiration date for the corresponding verifiable claim or certificate 600B, (2) a predetermined number of times the corresponding verifiable claim or certificate 600B may be accessed or used, (3) a mechanism for automatically expiring the verifiable claim or certificate 600B upon instruction from the issuer, or (4) a mechanism for allowing a user to manually expire the verifiable claim or certificate 600B.

[0104] 7A illustrates an embodiment of a computing system environment 700 for recording chain of custody and verifying chain of custody in a distributed network. As illustrated, the environment 700 includes an origin entity 710 associated with an object 712. For example, in some embodiments, the object 712 is a work of art, such as, but not limited to, a painting, a portrait, a sculpture, a musical piece, or any other type of artistic work. In some embodiments, the work of art is a digital object version, such as a digital portrait or digital music. In other embodiments, the work of art is a version of a physical object, such as a physical portrait or music. In some embodiments, the object 712 is a physical object, such as a table, desk, other furniture, a musical instrument, or a vehicle. Although embodiments disclosed herein are not limited by the type of object 712, the object 712 is typically an object that is considered to have value and that can be bought and sold or transferred from one entity to another.

[0105] In some embodiments disclosed herein, original entity 710 is an entity that creates or generates object 712. For example, in such embodiments, original entity 710 may be an artist that creates or generates object 712, which is a digital or physical work of art. In other embodiments, original entity 710 is an entity that acquires object 712 for sale to other entities. For example, in such embodiments, original entity 710 may be an antiques dealer that sells antique furniture or vehicles. Thus, embodiments disclosed herein are not limited by the type of original entity 710.

[0106] Because the object 712 is typically an object that is considered valuable and can be bought and sold, it is important to ensure that the object 712 is authentic when it is bought and sold. This helps ensure that a particular entity is not attempting to sell a fraudulent object 712. Thus, the embodiments disclosed herein allow the originating entity or a subsequent selling entity to record a verifiable claim or certificate regarding the chain of custody of the object 712 in the distributed ledger. The purchasing entity can then access the distributed ledger to verify the verifiable claim or certificate associated with the object 712. If the verifiable claim or certificate associated with the chain of custody of the object 712 is verified, the purchasing entity can have a high degree of confidence that the object 712 is authentic. In some embodiments, the originating entity 710 obtains the DID 712A of the object 712 in the manner described above. Obtaining the DID of the object 712 can further help identify the object 712 in a distributed system and can help record and validate the verifiable claim or certificate on the distributed ledger. Thus, as shown in 701 of Figure 7A, a computing system of originating entity 710 provides a verifiable claim or proof of original chain of custody 715 to a computing system of entity 730, which is an entity purchasing object 712 from originating entity 710. The computing system of originating entity 710 may generate verifiable claim or proof of original chain of custody 715 when entity 730 initiates the purchasing process.

[0107] 7B shows an example data structure representing a chain of custody claim 720 created by an originating entity 710. Chain of custody claim 720 includes object 712 as the subject of the claim, a property 721 specifying that object 712 was sold, and a value 722 listing the name of the entity to which object 712 was sold, as well as a DID associated with that entity. In the illustrated embodiment, it is entity 730 to which object 712 is sold, and therefore includes a DID 737A associated with entity 730. Additionally, object 712 is shown as being associated with its DID 712A, which may correspond to the DID discussed above.

[0108] In some embodiments, in addition to the chain of custody claim 720, the originating entity 710 also makes an authenticity claim 711 regarding the object 712. Figure 7B shows an example data structure representing an authenticity claim 711 made by the originating entity 710. The authenticity claim 711 includes the object 712 and its associated DID 712A as the subject of the claim, a property 713 that specifies that the object 712 is authentic, and a value 714 that indicates "true" because the object 712 is authentic.

[0109] 7C illustrates an example data structure of an original verifiable claim or certificate 715. The original chain of custody verifiable claim or certificate 715 includes a custody claim 720, which includes a DID 712A of the object 712 and a DID 737A of the entity 730. In some embodiments, it also includes an authenticity claim 711, which includes the DID 712A of the object 712. The original chain of custody verifiable claim or certificate 715 also includes a signature 717, which is generated by signing the original chain of custody verifiable claim or certificate 715 with the private key of the original entity 710, which is associated with the DID 717A of the original entity 710 and is part of a key pair with a public key 717B included in the signature 717. The signature 717 is typically a cryptographic mechanism (e.g., a digital signature) used to detect whether the original chain of custody verifiable claim or certificate 715 has been tampered with since the original chain of custody verifiable claim or certificate 715 was issued, and can be used to verify the identity of the originating entity 710. In some embodiments, the original chain of custody verifiable claim or certificate 715 also includes claim metadata 716 associated with the original verifiable claim or certificate 715. The claim metadata 716 corresponds to metadata 620 discussed above.

[0110] Once the original chain of custody verifiable claim or certificate 715 is generated, at least a portion of the data associated with the original chain of custody verifiable claim or certificate 715 is propagated to the distributed ledger 760 (corresponding to the distributed ledger 220, 560) by the computing system of the originating entity 710, as shown at 702 in FIG. 7A, thereby allowing a trusted entity to verify the original verifiable claim or certificate 715 using the portion of the data propagated to the distributed ledger. For example, in some embodiments, the DID 717A or the public key 717B is propagated onto the distributed ledger 760 for use in validating the original verifiable claim or certificate 715. In other embodiments, a hash of the public key 717B or a hash of the original chain of custody verifiable claim or certificate 715 is propagated onto the distributed ledger 760.

[0111] As shown in 701 of Figure 7A, a computing system of entity 730 receives a verifiable claim or proof 715 of the original chain of custody from originating entity 710 upon the consummation of the sale of object 712. Although not shown for ease of illustration, it will be appreciated that entity 730 will also receive the actual object 712 from originating entity 710 once the sale of object 712 is consummated, since entity 730 now owns object 712.

[0112] Upon receiving the original verifiable claim or certificate 715, the computing system of the entity 730 may access the distributed ledger 760 as shown at 704 and verify the signature 717 using the DID 717A and / or public key 717B. In other words, the computing system of the entity 730 will use the DID 717A and / or public key 717B to verify that the multiple entries on the distributed ledger 760 indicate that the signature 717 (or at least a representation of the signature 717) was properly recorded and not tampered with. Successful verification of the signature 717 will verify that the original entity 710 had proper custody of the object 712 at the time the original chain of custody verifiable claim or certificate 715 was received by the entity 730.

[0113] After gaining control of object 712, entity 730 may wish to sell object 712 to entity 740. Thus, as shown at 703 in FIG. 7A , the computing system of entity 730 provides a verifiable claim or certificate of chain of custody 735 to the computing system of entity 740 to demonstrate the proper chain of custody to entity 740. The computing system of entity 730 may generate the verifiable claim or certificate of chain of custody 735 when entity 740 initiates the purchasing process. Because entity 730 is “presenting” the verifiable claim or certificate of chain of custody 735 to entity 740, the verifiable claim or certificate of chain of custody 735 may also be referred to as a verifiable presentation 735.

[0114] 7D shows an example data structure representing a chain of custody claim 731 made by entity 730. Chain of custody claim 731 includes object 712 as the subject of the claim and its associated DID 712A, a property 732 specifying that object 712 has been sold, a value 733 listing the name of the entity to which object 712 has been sold and that entity's associated DID. In the illustrated embodiment, it is entity 740 to which object 712 has been sold, and therefore includes a DID 747A associated with entity 740.

[0115] 7E illustrates an example data structure of a chain of custody verifiable claim or certificate 735. The chain of custody verifiable claim or certificate 735 includes the chain of custody claim 731 and includes the DID 712A of the object 712 and the DID 747A of the entity 740. In some embodiments, the chain of custody verifiable claim or certificate 735 also includes various metadata 736 that is associated with the chain of custody verifiable claim or certificate 735 and may correspond to the metadata 620 described above. The chain of custody verifiable claim or certificate 735 also includes or has embedded therein the original verifiable claim or certificate 715.

[0116] The chain of custody verifiable claim or certificate 735 also includes a signature 737 that is generated by signing the chain of custody verifiable claim or certificate 735 with the private key of the entity 730 associated with the DID 737A of the entity 730. The signature 737 is typically a cryptographic mechanism (such as a digital signature) that can be used to detect whether the chain of custody verifiable claim or certificate 735 has been tampered with since it was issued, and can be used to verify the identity of the entity 730.

[0117] Once the chain of custody verifiable claim or certificate 735 is generated, as shown at 704 in FIG. 7A , at least a portion of the data associated with the chain of custody verifiable claim or certificate 735 is propagated onto the distributed ledger 760 by the computational system of the entity 730 to enable a trusted entity to use the portion of the data propagated to the distributed ledger to verify the chain of custody verifiable claim or certificate 735. For example, in some embodiments, the DID 737A or the public key 737B is propagated onto the distributed ledger 760 for use in validating the chain of custody verifiable claim or certificate 735. In other embodiments, a hash of the public key 737B or a hash of the chain of custody verifiable claim or certificate 735 is propagated onto the distributed ledger 760.

[0118] As shown at 703 in Figure 7A, once the sale of object 712 is completed, a computing system of entity 740 receives a verifiable claim or certificate of chain of custody 735 from entity 730. Although not shown for ease of illustration, it will be appreciated that since entity 740 now owns object 712, once the sale of object 712 is completed, entity 740 will also receive the actual object 712 from entity 730.

[0119] Upon receiving a verifiable claim or proof of chain of custody 735, the computing system of entity 740 can access the distributed ledger 760 as shown at 706 and verify the signature 737 using the DID 737A and / or public key 737B. In other words, the computing system of entity 740 will use the DID 737A and / or public key 737B to verify that multiple entries on the distributed ledger 760 indicate that the signature 737 (or at least a representation of the signature 737) has been properly recorded and has not been tampered with or revoked.

[0120] However, validating the signature 737 by itself does not necessarily verify that the entity 730 had proper custody of the object 712. For example, the entity 730 may have been attempting to sell a counterfeit version of the object 712 and thus fraudulently generated the chain of custody verifiable claim or certificate 735 to deceive the entity 740. Thus, the computational system of the entity 740 may also access the distributed ledger as shown at 706 to verify the signature 717 of the original chain of custody verifiable claim or certificate 715 that is embedded in the chain of custody verifiable claim or certificate 735 using the DID 717A and / or the public key 717B. As previously mentioned, verifying the signature 717 indicates that the original chain of custody verifiable claim or certificate 715 has not been tampered with, since such tampering would cause the signature to fail to verify. Furthermore, verifying the signature 717 indicates that the original chain of custody verifiable claim or certificate 715 of support has not been revoked, since such a revocation would likely be recorded in the distributed ledger 760. Thus, successful verification of signatures 717 and 737 verifies that entity 730 had proper control over object 712 at the time that verifiable chain of custody claim or certificate 735 was received by entity 740.

[0121] After gaining control of object 712, entity 740 may wish to sell object 712 to entity 750. Thus, as shown at 705 in FIG. 7A , the computing system of entity 740 provides a verifiable claim or certificate 745 to the computing system of entity 750. The computing system of entity 740 may generate the verifiable claim or certificate 745 when entity 730 initiates the purchasing process. Because entity 740 is "presenting" verifiable claim or certificate 745 of the chain of custody to entity 750, verifiable claim or certificate of custody 745 may also be referred to as a verifiable presentation 745.

[0122] 7F shows an example data structure representing a chain of custody claim 741 created by entity 740. Chain of custody claim 741 includes object 712 and its associated DID 712A as the subject of the claim, a property 742 specifying that object 712 was sold, and a value 743 listing the name of the entity to which object 712 was sold, as well as that entity's associated DID. In the illustrated embodiment, it is entity 750 to which object 712 is sold, and therefore includes a DID 750A associated with entity 750.

[0123] 7G illustrates an example data structure of a chain of custody verifiable claim or certificate 745. The chain of custody verifiable claim or certificate 745 includes the chain of custody claim 741, which includes the DID 712A of the object 712 and the DID 750A of the entity 750. In some embodiments, the chain of custody verifiable claim or certificate 745 also includes various metadata 746 that is related to the chain of custody verifiable claim or certificate 745 and may correspond to the metadata 620 described above. The chain of custody verifiable claim or certificate 745 also includes or has embedded therein the chain of custody verifiable claim or certificate 735. As described above, the chain of custody verifiable claim or certificate 735 includes or has embedded therein the original verifiable claim or certificate 715.

[0124] The chain of custody verifiable claim or certificate 745 also includes a signature 747 that is generated by signing the chain of custody verifiable claim or certificate 745 with the private key of the entity 740 associated with the DID 747A of the entity 740. The signature 747 is typically a cryptographic mechanism (such as a digital signature) that can be used to detect whether the chain of custody verifiable claim or certificate 745 has been tampered with since the chain of custody verifiable claim or certificate 745 was issued, and can be used to verify the identity of the entity 740.

[0125] Once the chain of custody verifiable claim or certificate 745 is generated, as shown at 706 in FIG. 7A , at least a portion of the data associated with the chain of custody verifiable claim or certificate 745 is propagated onto the distributed ledger 760 by the computational system of the entity 740 to enable a trusted entity to use the portion of the data propagated to the distributed ledger to verify the chain of custody verifiable claim or certificate 745. For example, in some embodiments, the DID 747A or the public key 747B is propagated onto the distributed ledger 760 for use in validating the chain of custody verifiable claim or certificate 745. In other embodiments, a hash of the public key 747B or a hash of the chain of custody verifiable claim or certificate 745 is propagated onto the distributed ledger 760.

[0126] As shown in Figure 7A at 706, the computing system of entity 750 receives a verifiable claim or certificate 745 of the chain of custody from entity 740 upon the consummation of the sale of object 712. Although not shown for ease of illustration, it will be appreciated that entity 750 will also receive the actual object 712 from entity 740 once the sale of object 712 is consummated, since entity 750 currently owns object 712.

[0127] Upon receiving a verifiable claim or proof of chain of custody 745, the computational system of entity 750 can access the distributed ledger 760 as shown at 707 and verify the signature 747 using the DID 747A and / or public key 747B, confirming that multiple entries on the distributed ledger 760 indicate that the signature 747 (or at least a representation of the signature 747) has been properly recorded and has not been tampered with or revoked.

[0128] Validating the signature 747 by itself does not necessarily verify that the entity 740 or entity 730 had proper custody of the object 712, since an incorrect chain of custody claim may have been added to a previous chain of custody verifiable claim or certificate. Thus, the computing system of the entity 750 may also access the distributed ledger as shown at 707 to verify the signature 737 of the chain of custody verifiable claim or certificate 735 embedded in the chain of custody verifiable claim or certificate 745 using the DID 737A and / or public key 737B. Additionally, the computing system of the entity 750 may access the distributed ledger as shown at 706 to verify the signature 717 of the original chain of custody verifiable claim or certificate 715 embedded in the chain of custody verifiable claim or certificate 735 using the DID 717A and / or public key 717B. Successful verification of signatures 717, 737, and 747 verifies that entity 740 had proper control over object 712 at the time that verifiable chain of custody claim or certificate 745 was received by entity 750.

[0129] 8 shows a more detailed diagram of a process flow for entity 750 to verify or validate various verifiable claims or certificates 715, 735, and 745. As previously described, the computing system of entity 750 receives chain of custody verifiable claim or certificate 745 from entity 730. As shown at 801, the computing system of entity 750 accesses the distributed ledger 760 to verify or validate the chain of custody verifiable claim or certificate 745 in the manner previously described. As shown at 802, upon successful verification or validation of the chain of custody verifiable claim or certificate 745, the computing system of entity 750 accesses the distributed ledger 760 to verify or validate the chain of custody verifiable claim or certificate 735 embedded in the chain of custody verifiable claim or certificate 745 in the manner previously described as shown at 803. Upon successful verification or validation of chain of custody verifiable claim or certificate 735, as shown at 804, the computational system of entity 750 accesses the distributed ledger 760 to verify or validate the original chain of custody verifiable claim or certificate 715 embedded in chain of custody verifiable claim or certificate 735 in the manner described above, as shown at 805. In this manner, entity 750 can verify that each of the entities that claimed to have appropriate control over object 712 at some point in time actually did have control. This allows entity 750 to be confident of the authenticity of object 712.

[0130] In some embodiments, one of the entities with custody of the object 712 may wish to perform repairs or other changes to the object 712. For example, if the object 712 is an antique piece of furniture or an antique car, it may need to be repaired or restored to increase its value. Accordingly, FIG. 7H illustrates an alternative embodiment of the environment 700 including a repair entity 770. In this embodiment, the computational system of the repair entity 770 may generate a repair verifiable claim or certificate 775. Although not shown, the repair verifiable claim or certificate 775 may include claim metadata that includes a claim having a subject, properties, and values ​​and specifies the repairs or changes made to the object 712. It may also include a signature along with an associated DID and public key that is used to record the repair verifiable claim or certificate 775 on the distributed ledger 760, as shown at 709.

[0131] The repair verifiable claim or certificate 775 is provided to the entity that initiated the repair or modification. In the illustrated embodiment, this entity is entity 740, and the repair verifiable claim or certificate 775 is provided to entity 740, as shown at 708. The repair verifiable claim or certificate 775 can then be embedded in the verifiable claim or certificate 745 of the chain of custody, as shown in FIG. 7J. In this manner, any repairs or modifications to object 712 can be included in the verifiable claim or certificate. While the illustrated embodiment shows entity 740 initiating the repair or modification, this may be performed by any of the entities. Additionally, in some embodiments, repair entity 770 may be entity 740 or some other entity of environment 700.

[0132] 7I illustrates another alternative embodiment of environment 700 that includes an assisting entity 780. Assisting entity 780 is typically a well-known entity that is an expert in a particular field that may be trusted by other entities for its expertise. For example, assisting entity 780 may be an antiques dealer that is well-known for making claims on antiques.

[0133] In this embodiment, a computing system of the assisting entity 780 can generate an assistance request or certificate 785. Although not shown, the assistance request or certificate 785 includes a claim having a subject, properties, and values, and can include claim metadata specifying that the assisting entity has established authenticity of the object 712. It can also include a signature along with an associated DID and public key that is used to record the assistance request or certificate 785 on the distributed ledger 760, as shown at 709A.

[0134] The assistance request or certificate 785 is provided to the entity that requested the assistance. In the illustrated embodiment, this entity is entity 740, and the assistance request or certificate 785 is provided to entity 740, as shown at 708A. The assistance request or certificate 785 can then be embedded into a chain of custody verifiable claim or certificate 745, as shown in FIG. 7K. Entity 750 (or any subsequent entity that receives the chain of custody verifiable claim or certificate) can then verify the assistance request or certificate 785 in the manner described above using distributed ledger 760. If the assistance request or certificate 785 is verified or validated, entity 750 can trust that object 712 is authentic. Entity 750 (or any subsequent entity that receives the chain of custody verifiable claim or certificate) may not need to further verify or validate other chain of custody claims or certificates, because entity 750 can be confident of the assistance provided by assisting entity 780. Although the illustrated embodiment shows entity 740 requesting assistance request or certificate 785, this may be performed by any of the entities. Additionally, in some embodiments, the assisting entity may be entity 740 or some other entity in environment 700.

[0135] 9 illustrates an embodiment in which the object 712 is a digital artwork 910. The digital artwork 910 will typically include metadata 920 that includes information about the digital artwork. Thus, in some embodiments, the originating entity 710 includes the original chain of custody verifiable claim or certificate 715 as part of the metadata 920 when selling the digital artwork 910 to the entity 730. Although not shown, the entity 730 may then include the chain of custody verifiable claim or certificate 735 in the metadata 920. This process may then be repeated by the entity 740 for the chain of custody verifiable claim or certificate 745. In other embodiments, the digital artwork 910 may be included in the claim metadata 716 of the original verifiable claim or certificate 715.

[0136] 9 also illustrates an alternative embodiment of an original verifiable claim or certificate 715. In this embodiment, the originating entity 710 has included a digital image 930 of the object 712 in the claim metadata 716. This may be useful for embodiments in which the object 712 is a physical object, such as an antique piece of furniture or a physical piece of art. By including the digital image 930 in the claim metadata 716, an entity that acquires the object 710 after the generation of the original chain of custody verifiable claim or certificate 715 can compare the physical object 712 to the digital image 930. A match may indicate that the object 712 is authentic and that the chain of custody was properly maintained. Shane In the following description, reference is made now to a number of methods and method acts that may be performed. Although the method acts may be described in a particular order or illustrated in a flowchart as occurring in a particular order, no particular order is required unless specifically stated or required, as some acts are dependent upon other acts being completed before the act can be performed.

[0137] 10 illustrates a flowchart of an example method 1000 for recording a chain of custody in a distributed network implementing a distributed ledger-backed decentralized identifier (DID). Method 1000 is described with respect to one or more of FIGS. 2-9 above.

[0138] The method 1000 includes receiving, at the second entity, a first chain of custody verifiable claim from the first entity, the first chain of custody verifiable claim being signed by the first entity and specifying that the object was under the control of the first entity at the time the first chain of custody verifiable claim was received (1010). For example, as previously described, the entity 730 may receive an original chain of custody verifiable claim or certificate 715 from the originating entity 710. The original chain of custody verifiable claim or certificate 715 includes a signature 717 of the originating entity 710 and includes a chain of custody claim 720 specifying that the object 712 was under the control of the originating entity 710 at the time the original chain of custody verifiable claim or certificate 715 was received by the entity 730. Alternatively, the entity 740 may receive a chain of custody verifiable claim or certificate 735 from the entity 740. The chain of custody verifiable claim or certificate 735 includes a signature 737 of the entity 730 and includes a chain of custody claim 731 specifying that the object 712 was under the control of the entity 730 at the time the chain of custody verifiable claim or certificate 735 was received by the entity 740.

[0139] Method 1000 includes accessing 1020 the distributed ledger to verify the first chain of custody verifiable claim. For example, as described above, entity 730 accesses distributed ledger 760 to verify original chain of custody verifiable claim or certificate 715. Alternatively, entity 740 accesses distributed ledger 760 to verify chain of custody verifiable claim or certificate 735.

[0140] Method 1000 includes generating a second chain of custody verifiable claim having the first chain of custody verifiable claim embedded therein and signed by the second entity (1030). For example, as described above, entity 730 generates chain of custody verifiable claim or certificate 735 including signature 737 and embedded original chain of custody verifiable claim or certificate 715. Alternatively, entity 740 generates chain of custody verifiable claim or certificate 745 including signature 747 and embedded chain of custody verifiable claim or certificate 735.

[0141] Method 1000 includes recording 1040 at least a portion of the second chain of custody verifiable claims in the distributed ledger. For example, as described above, entity 730 records at least a portion of chain of custody verifiable claims or certificates 735 in the distributed ledger 760. Alternatively, entity 740 records at least a portion of chain of custody verifiable claims or certificates 745 in the distributed ledger 760.

[0142] Method 1000 includes providing a second chain of custody verifiable claim to a third entity, where the second chain of custody verifiable claim is configured to designate to the third entity that the object was under the control of the second entity at the time the second chain of custody verifiable claim was provided to the third entity (1050). For example, as described above, entity 730 provides chain of custody verifiable claim or certificate 735 to entity 740 to establish a proper chain of custody for object 712. Alternatively, entity 740 provides chain of custody verifiable claim or certificate 745 to entity 750 to establish a proper chain of custody for object 712.

[0143] 11 illustrates a flowchart of an example method 1100 for verifying chain of custody in a distributed network implementing distributed identifiers (DIDs) backed by a distributed ledger. The method 900 is described with respect to one or more of FIGS. 2-9, discussed above.

[0144] The method 1100 includes receiving, at a third entity, a first chain of custody verifiable claim associated with the object from the first entity, the first chain of custody verifiable claim including a first signature generated by the first entity having embedded therein a second chain of custody verifiable claim associated with the object received by the first entity from the second entity, the second chain of custody verifiable claim including a second signature generated by the second entity (1110). For example, as described above, entity 740 receives from entity 730 a chain of custody verifiable claim or certificate 735 including signature 737, a chain of custody claim 731 for the object 712, and an embedded original chain of custody verifiable claim or certificate 715 including a signature 717 of the original entity 710. Alternatively, entity 750 receives from entity 740 an embedded chain of custody verifiable claim or certificate 735 and an original chain of custody verifiable claim or certificate 715, which include signature 747, a chain of custody claim 741 for object 712, and signature 737 of entity 730 and signature 171 of the original entity 710, respectively.

[0145] Method 1100 includes accessing the distributed ledger to validate the first chain of custody verifiable claim, where validation of the first chain of custody verifiable claim indicates that the first entity had proper custody of the object at the time the first chain of custody verifiable claim was received by the third entity (1120). For example, as described above, entity 740 may access distributed ledger 760 to validate chain of custody verifiable claim or certificate 735 to establish that entity 730 had proper chain of custody of object 712. Alternatively, entity 750 may access distributed ledger 760 to validate chain of custody verifiable claim or certificate 745 to establish that entity 740 had proper chain of custody of object 712.

[0146] Upon successful validation of the first chain of custody verifiable claim, method 1100 includes accessing the distributed ledger to validate the second chain of custody verifiable claim, where validation of the second chain of custody verifiable claim indicates that the second entity had proper custody of the object at the time the second chain of custody verifiable claim was received by the first entity (1130). For example, as previously described, entity 740 may access distributed ledger 760 to validate original chain of custody verifiable claim or certificate 715 to establish that original entity 710 had proper chain of custody for object 712. Alternatively, entity 750 may access distributed ledger 760 to validate the chain of custody verifiable claim or certificate and validate original chain of custody verifiable claim or certificate 715 to establish that entity 730 and original entity 710 had proper chain of custody of object 712.

[0147] In the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing orders. Additionally, the outlined operations are provided only as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with additional operations, or expanded into additional operations, without detracting from the essence of the disclosed embodiments.

[0148] The present invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present invention is therefore indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are intended to be embraced within their scope.

Claims

1. 1. A computing system for recording chain of custody in a distributed network that implements a distributed ledger backed decentralized identifier (DID), comprising: one or more processors; one or more computer-readable storage media having computer-executable instructions; the computer-executable instructions, when executed by the one or more processors, cause the computing system to: receiving, at a second entity, a first chain of custody verifiable claim from a first entity, the first chain of custody verifiable claim being signed by the first entity and specifying that an object was under the control of the first entity at the time the first chain of custody verifiable claim was received; accessing a distributed ledger to verify the verifiable claim of the first chain of custody; generating a second chain of custody verifiable claim, the second chain of custody verifiable claim having the first chain of custody verifiable claim embedded therein and signed by the second entity; recording at least a portion of the second chain of custody verifiable claims on the distributed ledger; and providing the second chain of custody verifiable claim to a third entity, the second chain of custody verifiable claim configured to specify to the third entity that the object was under the control of the second entity at the time the second chain of custody verifiable claim was provided to the third entity; configured to execute The first chain of custody verifiable claim and the second chain of custody verifiable claim are configured such that at least one of: (i) the second chain of custody verifiable claim includes a claim specifying a repair made to the object; (ii) the second chain of custody verifiable claim includes a claim specifying a change made to the object; and (iii) the first chain of custody verifiable claim includes an image of the object in metadata of the first chain of custody verifiable claim. Calculation system.

2. 2. The computing system of claim 1, wherein the first entity is an entity that initiates the chain of custody.

3. 2. The computing system of claim 1, wherein the first entity is an entity that creates the object.

4. 2. The computing system of claim 1, wherein the second chain of custody verifiable claims include the claims specifying the repairs made to the object.

5. 10. The computing system of claim 1, wherein the second chain of custody verifiable claims include claims made by a supporting entity.

6. 10. The computing system of claim 1, wherein the object is a digital object, and the verifiable claim of first chain of custody is included in metadata of the digital object.

7. 2. The computing system of claim 1, wherein the first chain of custody verifiable claim includes a digital image of the object within the metadata of the first chain of custody verifiable claim.

8. 2. The computing system of claim 1, wherein the second chain of custody verifiable claims include the claims that specify the changes made to the object.

9. 1. A method for recording chain of custody in a distributed network implementing a distributed ledger backed decentralized identifier (DID), comprising: receiving, at a second entity, a first chain of custody verifiable claim from a first entity, the first chain of custody verifiable claim being signed by the first entity and specifying that the object was under the control of the first entity at the time the first chain of custody verifiable claim was received; accessing a distributed ledger to verify the verifiable claim of the first chain of custody; generating a second chain of custody verifiable claim, the second chain of custody verifiable claim having the first chain of custody verifiable claim embedded therein and signed by the second entity; recording at least a portion of the verifiable claims of the second chain of custody in the distributed ledger; providing the second chain of custody verifiable claim to a third entity, the second chain of custody verifiable claim configured to specify to the third entity that the object was under the control of the second entity at the time the second chain of custody verifiable claim was provided to the third entity; Including, The first chain of custody verifiable claim and the second chain of custody verifiable claim are configured such that at least one of: (i) the second chain of custody verifiable claim includes a claim specifying a repair made to the object; (ii) the second chain of custody verifiable claim includes a claim specifying a change made to the object; and (iii) the first chain of custody verifiable claim includes an image of the object in metadata of the first chain of custody verifiable claim. method.

10. 10. The method of claim 9, wherein the first entity is an entity that initiates the chain of custody.

11. 10. The method of claim 9, wherein the first entity is an entity that creates the object.

12. 10. The method of claim 9, wherein the second chain of custody verifiable claim includes the claim specifying the repair performed on the object.

13. 10. The method of claim 9, wherein the second chain of custody verifiable claim comprises a claim made by a supporting entity.

14. 10. The method of claim 9, wherein the object is a digital object, and the verifiable claim of the first chain of custody is included in metadata of the digital object.

15. 10. The method of claim 9, wherein the first chain of custody verifiable claim includes a digital image of the object within the metadata of the first chain of custody verifiable claim.

16. 10. The method of claim 9, wherein the second chain of custody verifiable claims include the claims that specify the changes made to the object.

17. 1. A computational system for verifying a chain of custody in a distributed network that implements a distributed ledger-backed decentralized identifier (DID), comprising: one or more processors; one or more computer-readable storage media having computer-executable instructions; the computer-executable instructions, when executed by the one or more processors, cause the computing system to: receiving, at a third entity, from a first entity, a first chain of custody verifiable claim associated with an object, the first chain of custody verifiable claim including a first signature generated by the first entity having embedded therein a second chain of custody verifiable claim associated with the object received by the first entity from a second entity, the second chain of custody verifiable claim including a second signature generated by the second entity; accessing a distributed ledger to verify the first chain of custody verifiable claim, where verifying the first chain of custody verifiable claim indicates that the first entity had appropriate control over the object at the time the first chain of custody verifiable claim was received by the third entity; upon successful validation of the first chain of custody verifiable claim, accessing the distributed ledger to validate the second chain of custody verifiable claim, where validation of the second chain of custody verifiable claim indicates that the second entity had proper control of the object at the time the second chain of custody verifiable claim was received by the first entity; configured to execute The first chain of custody verifiable claim and the second chain of custody verifiable claim are configured such that at least one of: (i) the second chain of custody verifiable claim includes a claim specifying a repair made to the object; (ii) the second chain of custody verifiable claim includes a claim specifying a change made to the object; and (iii) the first chain of custody verifiable claim includes an image of the object in metadata of the first chain of custody verifiable claim. Calculation system.

18. 20. The computing system of claim 17, wherein the first entity is an entity that initiates the chain of custody.

19. 20. The computing system of claim 17, wherein the first entity is an entity that creates the object.

20. 20. The computing system of claim 17, wherein the second chain of custody verifiable claims include the claims specifying the repairs made to the object.

21. 20. The computing system of claim 17, wherein the second chain of custody verifiable claim comprises a claim made by a supporting entity.

22. 20. The computing system of claim 17, wherein the object is a digital object, and the verifiable claim of the first chain of custody is included in metadata of the digital object.

23. 20. The computing system of claim 17, wherein the second chain of custody verifiable claims include the claims that specify the changes made to the object.

Images