Method, system, and storage medium for presentation interruption of DID certification

Abstract

Embodiments disclosed herein relate to computing systems and methods for providing presentation interruption for a DID certificate. A DID certificate issued by a first entity of a decentralized network is accessed. The DID certificate defines information generated by the first entity about a DID owner who is the subject of the DID certificate. The DID certificate includes interruption metadata that directs the first entity to be contacted before the DID owner can present the DID certificate to a second entity of the decentralized network. In response to the DID owner attempting to present the DID certificate to the second entity, the first entity is contacted as directed by the interruption metadata. Authorization information is received from the first entity. The authorization information indicates whether the DID owner can present the DID certificate to the second entity.

Description

Background Art

[0001] Most documents or records that prove identity in use today are issued by centralized organizations such as governments, schools, employers, or other service centers or regulatory organizations. These organizations typically maintain the identity of each member in a centralized identity management system. A centralized identity management system is a centralized information system used by an organization to manage issued identities, their authentication, authorization, roles, and privileges. Centralized identity management systems are considered secure because they typically use professionally maintained hardware and software. Typically, the identity issuing organization establishes the terms and requirements for registering people with the organization. When one party needs to verify the identity of another party, the verifying party often needs to go through the centralized identity management system to obtain information used to verify and / or authenticate the identity of the other party.

[0002] A decentralized identifier (DID) is a new type of identifier that is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technologies, such as blockchain, offer the opportunity to use fully decentralized identifiers. Distributed ledger technologies use a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in the ledger portion cannot be retroactively changed without changing all subsequent ledger portions, which provides a fairly secure platform. Because DIDs are typically not controlled by a centralized management system, but rather owned by the owner of the DID, DIDs are sometimes referred to as unauthorized identities.

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

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

[0005] Embodiments disclosed herein relate to computing systems and methods for providing presentation interruption for a DID certificate. A DID certificate issued by a first entity of a decentralized network is accessed. The DID certificate defines information generated by the first entity about a DID owner who is the subject of the DID certificate. The DID certificate includes interruption metadata that directs the first entity to be contacted before the DID owner can present the DID certificate to a second entity of the decentralized network. In response to the DID owner attempting to present the DID certificate to the second entity, the first entity is contacted as directed by the interruption metadata. Authorization information is received from the first entity. The authorization information indicates whether the DID owner can present the DID certificate to the second entity.

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

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

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

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

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

[0011] Figure 4 An example decentralized storage device or identity center is shown;

[0012] Figure 5 An example embodiment of an environment for providing a presentation break for DID attestation is shown; and

[0013] Figure 6 A flow chart of an example method for providing presence interruption for DID attestation is shown. DETAILED DESCRIPTION

[0014] Embodiments disclosed herein relate to computing systems and methods for providing presentation interruption for a DID certificate. A DID certificate issued by a first entity of a decentralized network is accessed. The DID certificate defines information generated by the first entity about a DID owner who is the subject of the DID certificate. The DID certificate includes interruption metadata that directs the first entity to be contacted before the DID owner can present the DID certificate to a second entity of the decentralized network. In response to the DID owner attempting to present the DID certificate to the second entity, the first entity is contacted as directed by the interruption metadata. Authorization information is received from the first entity. The authorization information indicates whether the DID owner can present the DID certificate to the second entity.

[0015] The embodiments disclosed herein represent a technological advancement over existing systems. For example, an entity may issue a DID certificate that includes information about a DID owner. The DID owner may then wish to present the DID certificate to a second entity so that the second entity can utilize the information included in the DID certificate. However, the entity that issues the DID certificate may wish to have some control over which entities the DID certificate is presented to and how and where the DID certificate is presented. For example, an entity that issues a DID certificate may want to verify that the DID owner attempting to present the DID certificate is actually the party to which the DID certificate is issued. The entity that issues the DID certificate may also want to ensure that the DID certificate is used in a permitted geographic location or that the DID certificate is up to date.

[0016] Existing systems do not allow entities that issue DID certificates to control how DID owners present DID certificates. The embodiments disclosed herein provide a method for maintaining at least some control over how DID certificates are presented by requiring the DID owner to contact the issuing entity to obtain authorization before being allowed to present the DID certificate to a second entity. The issuing entity is then able to provide or deny authorization to present the DID certificate to the second entity, depending on the circumstances. This provides enhanced security for DID certificates that are not allowed to be used. This also provides the second entity with higher confidence in the following situation when the second entity is presented with the DID certificate: that is, the DID certificate is valid and authorized by the entity that issued the DID certificate. This reduces the amount of interaction between the parties, thereby reducing processing usage and time. In addition, user convenience and productivity are increased.

[0017] Because the principles described herein can be implemented in the context of a computing system, Figure 1 Some introductory discussion describing the computing system. The description will then return to the principles of the decentralized identifier (DID) platform with respect to the remaining figures.

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

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

[0020] Computing system 100 also has a number of structures on it that are generally 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 known to those of ordinary skill in the computing arts as a structure that can be software, hardware, or a combination thereof. For example, when implemented in software, one of ordinary skill in the art will understand that the structure of an executable component can include software objects, routines, methods, etc. that can be executed on a computing system, regardless of whether such executable components are present in a stack of the computing system or whether the executable components are present on a computer-readable storage medium.

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

[0022] The term "executable component" is also well understood by those of ordinary skill to include structures such as hard-coded or hard-wired logic gates, which are implemented exclusively or almost exclusively in hardware, such as in a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other special-purpose circuit. Therefore, the term "executable component" is a term used for structures well known to those of ordinary skill in the computing field, whether implemented in software, hardware, or a combination. In this specification, the terms "component", "mechanism", "manager", "service", "engine", "module", "virtual machine", etc. may also be used. As used in this specification and cases, these terms (whether or not expressed with a modifying clause) are also intended to be synonymous with the term "executable component" and therefore also have structures well known to those of ordinary skill in the computing field.

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

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

[0025] The embodiments described herein may include or utilize a dedicated or general-purpose computing system including computer hardware, such as one or more processors and system memory, as discussed in more detail below. The embodiments described herein also include physical 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 special-purpose computing system. The computer-readable medium that stores computer-executable instructions is a physical storage medium. The computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct computer-readable media: a storage medium and a transmission medium.

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

[0027] A "network" is defined as one or more data links that enable the transmission of electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computing system properly treats 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 general or special computing systems. Combinations of the above should also be included within the scope of computer-readable media.

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

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

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

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

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

[0033] The remaining figures may discuss various computing systems that may correspond to the computing system 100 previously described. The computing systems of the remaining figures include various components or functional blocks that may implement the various embodiments disclosed herein as will be explained. The various components or functional blocks may be implemented on a local computing system, or may be implemented on a distributed computing system that includes elements residing in the cloud or implements various aspects of cloud computing. The various components or functional blocks may be implemented as software, hardware, or a combination of software and hardware. The computing systems of the remaining figures may include more or fewer components than those shown in the figures, and certain components may be combined as appropriate.

[0034] Now about Figure 2 Give some introductory discussion of decentralized identifiers (DIDs) and the environments in which they are created and reside, Figure 2 2 shows a portion of a decentralized network 200. Figure 2 As shown, DID owner 201 may own or control DID 205 that represents the identity of DID owner 201. DID owner 201 may register a DID using a creation and registration service, which will be explained in more detail below.

[0035] DID owner 201 may be any entity that can benefit from a DID. For example, DID owner 201 may be a human or a human organization. Such an organization may include a company, department, government, agency, or any other organization or group of organizations. Each individual may have a DID, and each organization to which the individual belongs may also have a DID.

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

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

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

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

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

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

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

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

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

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

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

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

[0048] The DID document 210 may also include one or more service endpoints 213. A service endpoint may include a network address where a service operates on behalf of the DID owner 201. Examples of specific services include discovery services, social networks, file storage services (such as identity servers or centers), and verifiable claims repository services. Thus, the service endpoints 213 operate as pointers to services that operate on behalf of the DID owner 201. These pointers can be used by the DID owner 201 or a third-party entity to access services that operate on behalf of the DID owner 201. Specific examples of service endpoints 213 will be explained in more detail below.

[0049] The DID document 210 may also include identification information 214. The identification information 214 may include personally identifiable information such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Thus, for example, the identification information 214 listed in the DID document 210 may represent different roles of the DID owner 201 for different purposes.

[0050] A role can be pseudo-anonymous. For example, DID owner 201 can include a pseudonym in a DID document when identifying him or her as the author of an article published on a blog. A role can be completely anonymous. For example, DID owner 201 may only want to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.) instead of his or her name in the DID document. For another example, a role can be specific to DID owner 201 as an individual. For example, DID owner 201 can include information that identifies him or her as a volunteer for a specific charity, an employee of a specific company, a winner of a specific award, etc.

[0051] DID document 210 may also include attestation information 215. Attestation information 215 may be any information associated with the background of DID owner 201. For example, attestation information 215 may be, but is not limited to, qualifications, achievements, government IDs, government entitlements such as a passport or driver's license, payment providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of DID owner 201. In some embodiments, DID owner 201 collects various signed attestations included in the attestation information from different third-party entities.

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

[0053] Figure 2 Also shown is a distributed ledger 220. The distributed ledger 220 may be any decentralized distributed network including various computing systems that communicate with each other. For example, the distributed ledger 220 may include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems as shown by oval 260. The distributed ledger 220 may operate according to any known standard or method for distributed ledgers.

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

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

[0056] In one embodiment, when DID owner 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger 220. Distributed ledger 220 thus records that DID 205 now exists. Because distributed ledger 220 is decentralized, DID 205 is not controlled by any entity other than DID owner 201. In addition to a pointer to DID document 210, each of DID hash 231, DID hash 241, and DID hash 251 may also include a record or timestamp specifying when DID 205 was created. At a later date, when modifications are made to DID document 210, each modification (and possibly the timestamp of the modification) may also be recorded in DID hash 231, DID hash 241, and DID hash 251. DID hash 231 , DID hash 241 , and DID hash 251 may also include a copy of public key 207 , such that DID 205 is cryptographically bound to DID document 210 .

[0057] Already referenced Figure 2 Having described DIDs and how they generally operate, a specific embodiment of a DID environment will now be explained. Figure 3 , an environment 300 that can be used to perform various DID management operations and services will now be explained. It should be understood that for ease of explanation, Figure 3 The environment can be referenced as needed Figure 2 The elements in .

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

[0059] Environment 300 also includes a DID management module 320. It should be noted that in operation, DID management module 320 can reside on and be executed by user device 301, web browser 302, and operating system 303 as shown by corresponding lines 301a, 302a, and 303a. Therefore, for ease of explanation, DID management module 320 is shown as being separate. In some embodiments, management module 320 can be referred to as a "digital wallet" or "user institution."

[0060] like Figure 3 As shown, the DID management module 320 includes a DID creation module 330. The DID creation module 330 can be 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 can include or otherwise access a user interface (UI) element 335 that can guide the DID owner 201 to create the DID 205. The DID creation module 330 can have one or more drivers that are configured to work with a specific distributed ledger (such as the distributed ledger 220) so that the DID 205 conforms to the underlying methods of the distributed ledger.

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

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

[0063] In operation, DID creation module 330 accesses register 310, which is configured as a specific distributed ledger that will record transactions related to DID 205. DID creation module 330 uses register 310 to record DID hash 231, DID hash 241, and DID hash 251 in the distributed ledger in the manner previously described, and stores DID document 210 in the manner previously described. This process can use public key 207 in hash generation.

[0064] In some embodiments, DID management module 320 may include ownership module 340. Ownership module 340 may provide a mechanism for ensuring that DID owner 201 has sole control over DID 205. In this way, a provider of DID management module 320 can ensure that the provider does not control DID 205, but only provides management services.

[0065] As previously described, the key generation module 350 generates a pair of private key 206 and public key 207, and the public key 207 is then recorded in the DID document 210. Therefore, the public key 207 can be used by all devices associated with the DID owner 201 and all third parties who wish to provide services to the DID owner 201. Therefore, when the DID owner 201 wishes to associate a new device with the DID 205, the DID owner 201 can execute the DID creation module 330 on the new device. The DID creation module 330 can then use the register 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 previously described.

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

[0067] In embodiments where the additional public keys 208 and 209 are associated with different devices, the additional public keys 208 and 209 may be recorded in the DID document 210 as being associated with those devices. Figure 3 It should be understood that, except for Figure 3 The DID document 210 may also include information previously provided about Figure 2 The information described (information 205, 207 and 211 to 216). If the DID document 210 existed before the device-specific public key was generated, the DID document 210 will be updated by the creation module 330 via the register 310, and this will be reflected in the updated transaction on the distributed ledger 220.

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

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

[0070] As described above, in order to ensure that the private key 206 is completely under the control of the DID owner 201, the private key 206 is created on a user device 301, a browser 302, or an operating system 303 owned or controlled by the DID owner 201, and the DID owner 201 executes the DID management module 320. In this way, the possibility of a third party (most importantly, the provider of the DID management module 320) gaining control of the private key 206 is small.

[0071] However, DID owner 201 may lose the device storing private key 206, which may cause DID owner 201 to lose access to DID 205. Therefore, in some embodiments, UI 335 may include an option to allow DID owner 201 to export private key 206 to a secure database 305 outside the device under the control of DID owner 201. For example, database 305 may be the following about Figure 4 The storage module 380 is configured to store data (such as the private key 206 or the certification information 215 made by or about the DID owner 201) outside the device in the database 305 or the identity center 410 described in detail later. Of course, in some embodiments, if the device has sufficient storage resources, the storage module 380 can store at least some data on the device. In some embodiments, the private key 206 can be stored as a QR code that can be scanned by the DID owner 201.

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

[0073] The DID management module 320 may also include a revocation module 370 for revoking or disconnecting a device from the DID 205. In operation, the revocation module may use a UI element 335 that may allow the DID owner 201 to indicate a desire to disassociate a device from the DID 205. In one embodiment, the revocation module 370 may access the DID document 210 and may cause all references to the device to be removed from the DID document 210. Alternatively, the public key of the device may be removed. Such changes in the DID document 210 may then be reflected as updated transactions on the distributed ledger 220, as previously described.

[0074] Figure 4An embodiment of an environment 400 in which a DID such as DID 205 may be utilized is shown. Specifically, environment 400 will be used to describe the use of DID 205 in association with one or more decentralized storage or identity centers 410, each under the control of DID owner 201, for storing data belonging to or about DID owner 201. For example, DID 205 may be used to store data belonging to or about DID owner 201. Figure 3 The storage module 380 stores the data in the identity center. It should be noted that Figure 4 This may include first Figure 2 or 3 and therefore the same figure numbers are used for ease of explanation.

[0075] In one embodiment, identity centers 410 may be multiple instances of the same identity center. This is represented by line 410A. Thus, various identity centers 410 may include at least some of the same data and services. Thus, if a change is made to a portion of at least some of the data (and potentially any portion of any of the data) in one of identity centers 410, that change may be reflected in one or more (and potentially all) of the remaining identity centers.

[0076] Identity center 410 may be any data store that may be under the exclusive control of DID owner 201. By way of example only, first identity center 411 and second identity center 412 are implemented in cloud storage (possibly within the same cloud, or even on different clouds managed by different cloud providers), and thus may be able to hold large amounts of data. Thus, complete data sets may be stored in these identity centers.

[0077] However, identity centers 413 and 414 may have less memory space. Therefore, in these identity centers, descriptors of the data stored in the first and second identity centers may be included. Alternatively, a record of changes made to the data in the other identity centers may be included. Therefore, changes in one of identity centers 410 are fully replicated in the other identity centers, or at least a record or descriptor of the data is recorded in the other identity centers.

[0078] Because the identity center can be multiple instances of the same identity center, a complete description of only the first identity center 411 will be provided, as the description may also apply to identity centers 412 to 414. Figure 4As shown, identity center 411 may include data storage 420. Data storage 420 may be used to store any type of data associated with DID owner 201. In one embodiment, the data may be a collection 422 of a specific type of data corresponding to a specific protocol. For example, collection 422 may be medical record data corresponding to a specific protocol for medical data. Collection 422 may include any other type of data, such as attestation 215 made by or about DID owner 201.

[0079] In one embodiment, the stored data may have different authentication and privacy settings 421 associated with the stored data. For example, a first subset of data may have settings 421 that allow the data to be exposed publicly, but does not include any authentication of the DID owner 201. This type of data may be used for relatively unimportant data, such as color schemes, etc. A second subset of data may have settings 421 that allow the data to be exposed publicly and include authentication of the DID owner 201. A third subset of data may have settings 421 that encrypt the data subset using a private key 206 and a public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data would require a party to have access to the public key 207 or some other associated public key in order to decrypt the data. The process may also include authentication of the DID owner 201. A fourth subset of data may have settings 421 that restrict the data to a subset of third parties. This may require the use of a public key associated with the third-party subset to decrypt the data. For example, DID owner 201 may cause settings 421 to specify that only public keys associated with friends of DID owner 201 may decrypt the data. With respect to data stored by storage module 380, these settings 411 may be at least partially determined by Figure 3 The storage module 380 is composed of.

[0080] In some embodiments, identity center 411 may have 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, etc.) to access identity center. For example, DID owner 201 may provide access permissions to all data 420 to his or her spouse. Alternatively, DID owner 201 may allow access to his or her doctor to obtain any medical records. It should be understood that DID owner 201 may provide permissions for any number of third parties to access subsets of data 420. This will be explained in more detail below. With respect to data stored by storage module 380, these access permissions 430 may be at least partially determined by Figure 3 The storage module 380 is composed of.

[0081] Identity center 411 may also have a messaging module 440. In operation, the messaging module allows the identity center to receive messages such as requests from parties such as third parties 401 and 402 to access the data and services of the identity center. In addition, messaging module 440 allows identity center 411 to respond to messages from third parties and also communicate with DID resolver 450. This will be explained in more detail below. Ellipsis 416 indicates that identity center 411 may have additional services if the situation warrants.

[0082] In one embodiment, the DID owner 201 may wish to authenticate the new device 301 to the identity center 411 that has been associated with the DID 205 in the manner previously described. Therefore, the DID owner 201 can use the DID management module 320 associated with the new user device 301 to send a message to the identity center 411 to claim that the new user device is associated with the DID 205 of the DID owner 201.

[0083] However, identity center 411 may not initially recognize the new device as owned by DID owner 201. Therefore, identity center 411 may contact DID resolver 450 using messaging module 440. The message sent to DID resolver 450 may include DID 205.

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

[0085] As previously discussed, the DID document 210 may include a 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 center 411 may provide a cryptographic challenge to the new user device 301 using the messaging module 440. The cryptographic challenge will be constructed such that only devices that have access to the private key 206 will be able to successfully answer the challenge.

[0086] In this embodiment, the challenge can be successfully answered because the new user device is owned by DID owner 201 and therefore has access to private key 206. Identity center 411 can then record in permission 430 that new user device 301 can access identity center 411 and the rest of identity center 410's data and services.

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

[0088] In another example embodiment, DID owner 201 may provide DID 205 to third-party entity 401 so that the third party can access data or services stored on identity center 411. For example, DID owner 201 may be a human being at a scientific conference who wishes to allow third party 401, who is also a human being, to access his or her research data. Thus, DID owner 201 may provide DID 205 to third party 401.

[0089] Once third party 401 has access to DID 205, he or she may access DID resolver 450 to access DID document 210. As previously described, DID document 210 may include endpoint 213, which is an address or pointer to a service associated with the decentralized identity.

[0090] After completing the research data instance, third party 401 can send a message to messaging module 440 to request permission to access the research data. Messaging module 440 can then send a message to DID owner 201 to ask whether third party 401 should be given access to the research data. Because the DID owner wishes to provide access to the data, DID owner 201 can allow permission to third party 401, and the permission can be recorded in permission 430.

[0091] Messaging module 440 may then send a message to third party 401 to notify the third party that he or she can access the research data. Identity center 411 and third party 401 may then communicate directly so that the third party can access the data. It should be noted that in many cases, it is actually the identity center associated with third party 401 that is communicating with identity center 411. However, it may be a device of third party 401 that is communicating.

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

[0093] like Figure 4 As shown, third party 402 may also request permission to access identity center 411 using DID 205 and DID document 210. Thus, embodiments disclosed herein allow any number of third parties to access identity center 410.

[0094] Figure 5 An embodiment of an environment 500 is shown that will be used to describe a presentation interrupt for DID attestation or assertion. It should be noted that Figure 5 This may include first Figure 2-Figure 4 Reference to the elements discussed and therefore the same reference numerals may be used to facilitate the explanation.

[0095] like Figure 5 As shown, environment 500 includes an attestation module 530. In one embodiment, attestation module 530 may be implemented by a third party, such as a provider of DID management module 320 and / or identity center 410. In some embodiments, attestation module 530 may be hosted on a server computer separate from device 301 owned by DID owner 201. In other embodiments, attestation module 530 may be part of DID management module 320, or may share at least some functionality with DID management module 320. In other embodiments, attestation module 530 may be part of or controlled by a third party entity, such as entity 550 or 560.

[0096] A specific use embodiment of the attestation module 530 will now be described with respect to a presentation interrupt for DID attestation or assertion. For example, assume that the DID owner 201 is associated with an entity 550. The entity 550 may be any type of entity, such as a company or organization or even another human user. In a specific embodiment, it will be assumed that the entity 550 is a government agency, such as the Department of Motor Vehicles (DMV) that has issued a driver's license to the DID owner 201. Figure 5 As shown, entity 550 may include DID 555 that has been generated for entity 550 in the manner previously described.

[0097] DID owner 201 may, at any point in time, request a signed attestation or statement 501 from entity 550 that verifies that DID owner 201 has a valid driver's license that has been issued by entity 550. In one embodiment, DID owner 201 may make the request directly to entity 550, while in other embodiments, the request may be made via DID owner 201 first contacting attestation module 530 and then having attestation module 530 make the request to entity 550. Attestation 501 is thus associated with DID owner 201's DID 205 and may be considered a DID attestation.

[0098] Attestation 501 may also be referred to as a signed statement, credential, or verified credential, such as attestation 215 of DID document 210. That is, the attestation or verified credential may provide information about DID owner 201 and / or about various entities with which DID owner 201 has interacted. For consistency of explanation, "attestation" will be the term used in the following discussion.

[0099] In response to the request for proof 501, entity 550 may create proof 501 related to verifying that DID owner 201 has a valid driver's license. In some embodiments, proof 501 may be a cryptographically protected pointer to the location of entity 550's identity center 556 where driver's license information is stored. Entity 550 may then digitally sign proof 501 using its public key, thereby verifying that entity 550 agrees that DID owner 201 has a valid driver's license. Proof module 530 may then use public key 207 to request that DID owner 201 endorse or digitally sign proof 501. In this way, when proof 501 is provided to other parties such as entity 560, DID owner 201 is able to verify that he or she agrees with the driver's license information of his or her proof 501.

[0100] In some embodiments, in addition to information specifying that DID owner 201 has a valid driver's license, proof 501 may include various additional information. For example, entity 550 may include interruption metadata or information 510 in proof 501. As will be explained in more detail below, interruption metadata 510 may cause entity 550 to be contacted before proof 501 is presented to entity 560 each time DID owner 201 attempts to present proof 501 to an entity such as entity 560. Thus, interruption metadata 510 causes an "interruption" in the presentation process. As will also be explained in more detail below, entity 550 may then be able to grant or deny authorization for DID owner 201 to present proof 501 to entity 560.

[0101] There may be a variety of reasons why entity 550 may want to include blackout metadata 510 in attestation 501. In one case, entity 550 may want to verify that the party attempting to present attestation 501 is actually DID owner 201. In another example, entity 550 may want to ensure that DID owner 201 is attempting to use attestation 501 in a permitted geographic location. In yet another example, entity 550 may want to ensure that attestation 501 is up to date, which may be helpful if a long period of time has passed since entity 550 issued attestation 501 to DID owner 201. Note that there may be a variety of reasons why entity 550 may want to include blackout metadata 510 in attestation 501.

[0102] In some embodiments, the interruption metadata 510 may include contact metadata 511. The contact metadata 511 may include information that directs how to contact entity 550 when DID owner 201 attempts to present proof 501 to entity 560 or some other entity. Thus, in some embodiments, proof module 530 may use contact metadata 511 to contact entity 550. Ellipses 512 indicate that proof 501 may include any number of additional elements as appropriate.

[0103] Although the disclosed embodiments are described with respect to providing proof 501 for a driver's license issued by entity 550, the process may be performed in other scenarios as well. For example, proofs may be generated by various third-party entities related to one or more of qualifications, achievements, government IDs, government entitlements (such as a passport or driver's license), payment providers or bank accounts, college degrees or other educational experiences. It should be noted that any number of proofs may be generated for any number of objects, and therefore, the embodiments disclosed herein are not limited to any particular type or number of proofs.

[0104] Attestation 501 generated by entity 550 on behalf of DID owner 201 may be provided to the DID owner (as shown at 502) and stored in identity center 411. Thus, DID owner 201 may be considered the owner of attestation 501 because DID owner 201 is the subject of the attestation. In other words, attestation 501 includes information about DID owner 201 generated by entity 550. It should be noted that, although not shown, entity 550 may utilize attestation module 550 when providing attestation 501 to DID owner 201.

[0105] In one particular embodiment, assume that entity 560, which may have its own DID 565 generated in the aforementioned manner, is a car rental agency or similar business that may rent cars or other types of motor vehicles to DID owner 201. Therefore, in such an embodiment, DID owner 201 may wish to present proof 501 to entity 560 to prove that he or she has a valid driver's license in order for entity 560 to rent a car or motor vehicle to him or her.

[0106] Thus, attestation module 530 may include attestation presentation module 540. In operation, attestation presentation module 540 may be able to access attestation 501 from identity center 411, as shown at 503A, in order to present attestation 501 to entity 560.

[0107] In this embodiment, proof presentation module 540 may receive request 503B from DID owner 201 to present proof 501 to entity 560. This may occur when DID owner 201 wants to rent a car or motor vehicle from entity 560. Thus, request 503B may be considered an attempt by DID owner 201 to present proof 501 to entity 560.

[0108] In this embodiment, the proof presentation module 540 can access the proof 501 as previously described. However, when attempting to present the proof 501 to the entity 560, the proof presentation module 540 can read or otherwise operate on the interruption metadata 510 included in the proof 501. As previously described, the interruption metadata 510 can prevent the proof presentation module 540 from completing the presentation of the proof 501 to the entity 560, and may require contacting the entity 550 to obtain authorization to present the proof 501. In other words, the interruption metadata 510 prevents the DID owner 201 from presenting the proof 501 to the entity 560 without first receiving authorization to present the proof in some form from the entity 550.

[0109] Thus, as shown at 504, if the contact metadata 511 is included in the interruption metadata 510, the proof presentation module 540 may contact the entity 550 using the contact metadata 511. When contacted by the proof presentation module 540, the entity 550 may determine whether it wants to authorize the DID owner 201 to be able to present the proof 501 to the entity 560. Thus, the entity 550 may generate authorization information 520 indicating whether the DID owner 201 is able to present the proof 501. The authorization information 520 may be received by the proof presentation module 540 and attached to the proof 501 to control whether the DID owner 201 is authorized to present the proof 501, and provided to the DID owner 201, as shown at 505.

[0110] The authorization information 520 may take several forms, as will now be explained. It should be noted that the authorization information 520 may include one of the forms discussed, all of the forms discussed, a subset of the forms discussed, or even one or more forms in addition to or in lieu of the forms discussed below, as indicated by the ellipsis 529 below.

[0111] In one embodiment, authorization information 520 may take the form of or include permission information 525. Permission information 525 may specify a given permission for DID owner 201. For example, entity 550 may have no problem with DID owner 201 presenting proof 501 to entity 560, and thus permission information 525 may grant permission. In an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, if DMV 550 has no problem with DID owner renting from car rental agency 560, DMV 550 may provide permission information 525 that allows DID owner 201 to present proof 501.

[0112] However, in the event that entity 550 does not want DID owner 201 to present proof 501 to entity 560, permission information 525 may deny permission. In one embodiment, such denial may take the form of permission information 525 that renders entity 560 unable to use proof 501. In this case, entity 560 would be unable to use proof 501 even if DID owner 201 were somehow able to present proof 501 to entity 560.

[0113] In an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, assume that car rental agency 560 is well-known for renting cars or other motor vehicles that have caused a large number of accidents due to poor maintenance of the cars. In such an embodiment, DMV 550 may want to deny authorization to present proof 501 so that DID owner 201 cannot rent a vehicle from car rental agency 560. Therefore, DMV 550 can provide permission information 525 that denies permission to present to car rental agency 560 or prevents car rental agency 560 from using proof 501, as previously described.

[0114] In another embodiment, authorization information 520 may take the form of or include callback metadata 526. In operation, callback metadata 526 may direct entity 560 to contact entity 550 to determine whether proof 501 is still valid, which may be useful if a long time has passed since entity 550 issued proof 501 to DID owner 201. In an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, callback metadata 526 may allow car rental agency 560 to find out from DMV 550 whether the driver's license of DID owner 201 is still valid. This may increase the confidence of the interaction between DMV 550 and car rental agency 560.

[0115] In another embodiment, the authorization information 520 may take the form of or include location information 527. In operation, the location information 527 may limit the ability of the DID owner 201 to present the certificate 501 to certain locations approved by the entity 550. Thus, the DID owner may be able to present the certificate 501 to the entity 560 only when the entity 560 is located in an approved location. For example, in an embodiment where the entity 550 is the DMV and the entity 560 is a car rental agency, the DMV 550 may wish to limit the use of the certificate 501 including driver's license information to certain countries that it has determined to be safe. Thus, if the car rental agency 560 is located in an approved country, the location information 527 may allow the DID owner 201 to present the certificate 501 to the car rental agency 560. However, if the car rental agency 560 is not located in an approved country, the location information 527 may not allow the DID owner 201 to present the certificate 501 to the car rental agency 560.

[0116] In yet another embodiment, authorization information 520 may take the form of or include an update 528 to certification 501. Thus, update 528 allows entity 550 to ensure that certification 501 is always up to date when DID owner 201 presents certification 501 to entity 560. For example, in an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, update 528 allows DMV 550 to ensure that DID owner 201 always has updated driver's license information when renting a vehicle from car rental agency 560.

[0117] In some embodiments, before providing authorization information 520, entity 550 may require DID owner 201 to provide identification information 515, as shown at 506, which verifies that it is actually DID owner 201 who is attempting to present proof 501 to entity 560. This can help entity 550 ensure that a third party is not impersonating DID owner 201 and attempting to use proof 501 in an unallowable manner. Identification information 515 may simply be DID 205. Alternatively, identification information 515 may be a pairwise identifier between DID owner 201 and entity 550. Identification information 515 may include additional identification information agreed upon between DID owner 201 and entity 550 as desired. Thus, DID owner 201 may be able to specify with entity 550 what type of identification information entity 550 should request in order to maintain control of his or her identity.

[0118] For example, assume that in an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, a third party that is not DID owner 201 attempts to present credential 501 including driver's license information to rent a vehicle from car rental agency 560. The third party may have stolen a device of DID owner 201 and gained access to credential 501. Car rental agency 560 may not be able to determine whether the party presenting credential 501 is actually DID owner 201. By requiring identification information 515 to verify or authenticate DID owner 201, DMV 550 may be able to prevent impermissible use of credential 501.

[0119] In response to receiving authorization information 520 (in any valid form), DID owner 201 may then be authorized to present proof 501 to entity 560. Thus, proof presentation module 540 may present proof 501 to entity 560, as indicated at 507. Entity 560 may then use proof 501 in a desired manner. For example, in an embodiment where entity 550 is a DMV and entity 560 is a car rental agency, car rental agency 560 may use proof 501 to determine whether DID owner 201 has a valid driver's license and whether a car or other motor vehicle should be rented to DID owner 201.

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

[0121] Figure 6 A flow chart of an example method 600 for providing a presence interrupt for a DID attestation or assertion is shown. Figure 1-Figure 5 Method 600 is described with reference to one or more of the following.

[0122] Method 600 includes an act of accessing a DID certificate issued by a first entity of a decentralized network (act 610). The DID certificate defines information generated by the first entity about a DID owner that is the subject of the DID certificate. The DID certificate includes interruption metadata that directs the first entity to be contacted before the DID owner can present the DID certificate to a second entity of the decentralized network.

[0123] For example, as previously described, attestation presentation module 540 may access attestation 501, as shown at 503A. Attestation 501 may be generated by entity 550 and defines information about DID owner 201, which is the subject of attestation 501. Attestation 501 is therefore associated with DID 205 of DID owner 201 and may be considered a DID attestation. Attestation 501 may include interruption metadata 510 that directs entity 550 to be contacted before DID owner 201 can present attestation 501 to entity 560.

[0124] Method 600 includes an act of contacting a first entity as directed by the interruption metadata in response to the DID owner attempting to present the DID certification to the second entity (act 620). For example, as previously described, authentication presentation module 540 may contact entity 550 (as indicated by 504) as directed by the interruption metadata 510 in response to DID owner 201 attempting to present authentication 501 to entity 560 (as indicated by 503B).

[0125] Method 600 includes an act of receiving authorization information from a first entity (act 630). The authorization information indicates whether the DID owner is able to present the DID certificate to a second entity. For example, as previously described, the certificate presentation module 540 can receive authorization information 520, as shown in 505. The authorization information 520 can identify whether the DID owner 201 is able to present the certificate 501 to the entity 560.

[0126] For the process and method disclosed herein, the operations performed in the process and method can be implemented in different orders. In addition, the operations outlined 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 departing from the essence of the disclosed embodiments.

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

Claims

1. A computing system implemented in a decentralized network implementing a distributed ledger, the distributed ledger configured to support one or more decentralized identities (DIDs) for one or more users of the computing system, the computing system comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions stored thereon, the computer-executable instructions being configured to, when executed by the one or more processors, cause the computing system to: accessing a DID proof issued by a first entity of the decentralized network, the DID proof defining information about a DID owner that is a subject of the DID proof that has been generated by the first entity, the DID proof including interruption metadata directing the first entity to be contacted before the DID owner can present the DID proof to a second entity of the decentralized network; In response to the DID owner attempting to present the DID proof to the second entity, contacting the first entity as directed by the interruption metadata; as well as Authorization information is received from the first entity, the authorization information indicating whether the DID owner can present the DID certificate to the second entity.

2. The computing system of claim 1 , wherein execution of the computer executable instructions further causes the computing system to: In response to receiving the authorization information from the first entity, presenting the DID certificate to the second entity.

3. The computing system of claim 1, wherein the authorization information comprises an update to the DID certificate.

4. The computing system of claim 1, wherein the authorization information includes callback metadata directing the second entity to contact the first entity to determine whether the DID proof is valid.

5. The computing system of claim 1, wherein the authorization information includes location information specifying a geographic area in which the DID owner is authorized to present the DID proof to the second entity. 6 . The computing system of claim 1 , wherein the interruption metadata includes contact metadata defining how to contact the first entity to receive the authorization information.

7. The computing system of claim 1, wherein the DID owner cannot present the DID proof to the second entity without first receiving the authorization information from the first entity.

8. The computing system of claim 1, wherein the authorization information disables the second entity from using the DID credential when the first entity has not granted permission for the DID owner to present the DID credential to the second entity.

9. The computing system of claim 1 , wherein execution of the computer executable instructions further causes the computing system to: Upon contacting the first entity, identification information is provided to the first entity, the identification information verifying that it is the DID owner who is attempting to present the DID certificate to the second entity.

10. A method in a computing system implemented in a decentralized network implementing a distributed ledger, the distributed ledger configured to support one or more decentralized identities (DIDs) for one or more users of the computing system, the method for providing a presence interrupt for a DID attestation or claim, the method comprising: an act of accessing a DID proof issued by a first entity of the decentralized network, the DID proof defining information about a DID owner that is the subject of the DID proof that has been generated by the first entity, the DID proof including interruption metadata directing the first entity to be contacted before the DID owner can present the DID proof to a second entity of the decentralized network; an action of contacting the first entity as directed by the interruption metadata in response to the DID owner attempting to present the DID proof to the second entity; as well as An act of receiving authorization information from the first entity, the authorization information indicating whether the DID owner can present the DID proof to the second entity.

11. The method according to claim 10, further comprising: An act of presenting the DID proof to the second entity in response to receiving the authorization information from the first entity.

12. The method of claim 10, wherein the authorization information comprises an update to the DID certificate.

13. The method of claim 10, wherein the authorization information includes callback metadata directing the second entity to contact the first entity to determine whether the DID proof is valid.

14. The method of claim 10, wherein the authorization information includes information specifying a geographic region in which the DID owner is authorized to present the DID proof to the second entity.

15. The method of claim 10, wherein the interruption metadata includes contact metadata defining how to contact the first entity to receive the authorization information.

16. The method of claim 10, wherein the DID owner cannot present the DID proof to the second entity without first receiving the authorization information from the first entity.

17. The method of claim 10, wherein the authorization information disables the second entity from using the DID credential when the first entity has not granted permission for the DID owner to present the DID credential to the second entity.

18. The method according to claim 10, further comprising: Upon contacting the first entity, providing identification information to the first entity, the identification information verifying that the DID owner is attempting to present the DID certificate to the second entity.

19. A computer-readable storage medium storing computer-executable instructions, the computer-executable instructions being configured to, when executed by one or more processors of a computing system, cause the computing system to perform a method for providing a presentation interruption for a decentralized identity DID attestation or assertion, the method comprising: an act of accessing a DID proof issued by a first entity of a decentralized network, the DID proof defining information about a DID owner that is a subject of the DID proof that has been generated by the first entity, the DID proof including interruption metadata directing the first entity to be contacted before the DID owner can present the DID proof to a second entity of the decentralized network; an action of contacting the first entity as directed by the interruption metadata in response to the DID owner attempting to present the DID proof to the second entity; as well as An act of receiving authorization information from the first entity, the authorization information indicating whether the DID owner can present the DID proof to the second entity.

20. The computer-readable storage medium of claim 19, further comprising: An act of presenting the DID proof to the second entity in response to receiving the authorization information from the first entity.

Images