Publishing verifiable pairwise statements

Abstract

Verifiable pair-wise statements are generated. A request to issue a verifiable statement associated with a subject entity and verifiable by one or more verifying entities is received. The request includes at least an encrypted portion using a particular type of cryptography. The subject entity is verified as being associated with a subject of the verifiable statement based on decrypting the encrypted portion using the particular type of cryptography. In response to verifying the subject entity as being associated with the subject of the verifiable statement, the verifiable statement is issued that is structured to be verifiable only by the one or more verifying entities.

Description

Background Technology

[0001] Most identity verification documents or records currently in use are issued by centralized organizations such as governments, schools, employers, or other service centers or regulatory bodies. These organizations typically maintain the identity of each member within a centralized identity management system. A centralized identity management system is a centralized information system used by organizations to manage issued identities, their authentication, authorization, roles, and privileges. Centralized identity management systems are considered secure because they often use professionally maintained hardware and software. Typically, identity issuing organizations set terms and requirements for registered personnel within the organization. Finally, when one party needs to verify the identity of another, the verifying party often needs to obtain information for verifying and / or authenticating the other party's identity through a centralized identity management system.

[0002] Decentralized Identifiers (DIDs) are a new type of identifier that is independent of any centralized registry, identity provider, or proof authority. Distributed ledger technologies, such as blockchain, provide the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a globally distributed ledger to verifiably record transactions between two or more parties. Once a transaction is recorded, the data in a portion of the distributed ledger cannot be retroactively changed without altering all subsequent portions of the distributed ledger, providing a fairly secure platform. In such a decentralized environment, each owner of a DID can typically use his / her DID to control his / her own data. DID owners access the data stored in personal storage associated with their DID via a DID management module, which can be a mobile application, personal computer, browser, etc.

[0003] The subject matter claimed herein is not limited to embodiments that address any shortcomings or operate only in environments such as those described above. Rather, this background is provided merely to illustrate an exemplary technical field in which some of the embodiments described herein are practiced. Summary of the Invention

[0004] This "Summary" is provided to present the chosen concept in a simplified form, which will be further described in the detailed description below. This "Summary" is not intended to identify key 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] For reference Figure 6 and Figure 7 To explain in more detail, a statement is a declaration about a subject. A pair of statements are statements that can only be accessed by one or more specific validators. See reference [link / reference]. Figure 7 As explained, verifiable pairwise statements add additional information to pairwise statements 702 so that the verifier can trust the pairwise statements.

[0006] Existing technologies allow users to generate multiple paired DIDs, each used by the user to communicate with another party. The paired DID mechanism can protect user privacy because each DID is used only for communication with another entity. Therefore, user identity privacy is preserved, as only the other party derives the user's identity from the DID. However, when a user communicates with a new entity for the first time, a new DID needs to be generated. Over time, more and more DIDs are generated, and managing multiple DIDs for each user is cumbersome. Furthermore, it is often permissible to present existing verifiable claims (statements about a subject encrypted with a user key) to multiple verifying entities. The more verifying entities present the same verifiable claim, the higher the risk of user privacy exposure, as the user key used to encrypt the verifiable claim is more likely to be compromised.

[0007] The principles described in this paper aim to address at least some of the aforementioned problems by allowing users to communicate with multiple other parties using the same DID, but presenting pairwise verifiable claims to those parties. Since each pairwise verifiable claim is presented only to the other party, user privacy is protected. Simultaneously, users can reuse the same DID to communicate with multiple other parties without generating a new DID for each party. This reduces the burden of managing a large number of DIDs.

[0008] The embodiments disclosed herein relate to the publication of verifiable pairwise claims that are associated with a subject entity and are verifiable by one or more pre-defined verification entities. (See reference...) Figure 6 and Figure 7 To explain in more detail, a statement is a declaration about a subject. A pair of statements are statements that can only be accessed by one or more specific validators. See reference [link / reference]. Figure 7 As explained, a verifiable pairwise statement adds additional information to pairwise statement 702 to enable the verifier to trust the pairwise statement. The subject entity is associated with a first identifier. The embodiment is implemented in the computing system of a statement publisher (hereinafter also referred to as the "statement publisher"). First, the statement publisher receives a request to publish a verifiable statement associated with a subject entity and verifiable by one or more predetermined verification entities. This request includes at least an encrypted portion using a specific type of cryptography. Then, the statement publisher verifies the association between the subject entity and the subject of the verifiable statement based on decrypting the encrypted portion using the specific type of cryptography. In response to verifying the association between the subject entity and the subject of the verifiable statement, the statement publisher's computing system is configured to publish a verifiable statement that is verifiable only by one or more predetermined entities or a defined list of entities.

[0009] In some embodiments, conditions are imposed for accessing a verifiable claim. When a requesting entity requests access to a verifiable claim, the claim publisher determines whether the conditions are met. The claim publisher notifies the subject entity of the determination that the conditions are met. In response to the determination that the conditions are met, the claim publisher sends a verifiable claim to the subject entity, and causes the subject entity to pass the verifiable claim to the requesting entity. Alternatively, the claim publisher sends the verifiable claim directly to the requesting entity.

[0010] This condition includes verifying that the requesting entity is one of a predefined set of one or more verification entities. At least one of the one or more verification entities is associated with a decentralized identifier (DID). Verifying the identity of the requesting entity includes verifying that the requesting entity is the holder of the DID.

[0011] Alternatively or otherwise, the condition may include receiving a certain amount of digital assets. Digital assets include verifiable digital assets. Verifiable digital assets are broadly defined as objects that have value and / or can only be consumed a limited number of times via a computer network.

[0012] Alternatively or additionally, the conditions include a predetermined number of times the verifiable statement is allowed to be accessed. The conditions also include an expiration date for allowing access to the verifiable statement.

[0013] Allowing conditions to be imposed when verifying verifiable claims is advantageous. Existing decentralized identifiers are used by users and claim publishers to control the publication of claims. However, once a claim is published, users and / or claim publishers have no control over access to it. Imposing conditions on access to verifiable claims as described herein allows the owner (or subject) of the verifiable claim and the claim publisher to further control access to the verifiable claim after its publication.

[0014] Furthermore, in some embodiments, the verifiable claim is encrypted by one or more keys to allow the verifiable claim to be securely transmitted over a computer network. In some embodiments, the one or more keys include the public keys of one or more verification entities, such that the encrypted verifiable claim can only be decrypted by the private keys of one or more verification entities. Alternatively or additionally, the one or more keys include the key of the subject entity, such that the encrypted verifiable claim can only be decrypted with the permission of the subject entity. Alternatively or additionally, the one or more keys include the key of the claim publisher.

[0015] In some embodiments, the claim publisher sends an encrypted verifiable claim to the subject entity, causing the subject entity to pass the verifiable claim to a verification entity. Alternatively, the claim publisher sends the encrypted verifiable claim directly to at least one of one or more verification entities, causing the verification entity to request permission from the subject entity before accessing the received encrypted verifiable claim.

[0016] In some embodiments, when a claim publisher receives a request from a requesting entity for access to an encrypted verifiable claim, the claim publisher determines whether a condition has been met. In response to determining that the condition has been met, the claim publisher causes the requesting entity to receive one or more keys. At least one of the one or more keys is sent to the subject entity, causing the subject entity to decrypt the encrypted verifiable claim and send the decrypted verifiable claim to the requesting entity, or causing the subject entity to pass at least one key to the requesting entity. Alternatively, at least one key is sent directly to the requesting entity.

[0017] In some embodiments, conditions are imposed for publishing a verifiable claim. When a request to publish a verifiable claim is received, the claim publisher determines whether the conditions are met. The conditions for publishing a verifiable claim include verifying that the request to publish the verifiable claim was generated by a subject entity. The subject entity is associated with a decentralized identifier (DID). Verifying that the request to publish the verifiable claim was generated by a subject entity includes verifying that the requesting entity is the holder of the DID.

[0018] In response to a request for verification to publish a verifiable claim generated by the subject entity, the claim publisher then generates the requested verifiable claim and causes it to be stored in the identity center associated with the DID. The identity center is a store of attributes under the control of the DID holder, including keys and metadata. The identity center is then instructed to send the verifiable claim to at least one of one or more verification entities.

[0019] In some embodiments, the request to publish a verifiable claim is not necessarily generated by the subject entity. For example, the request to publish a verifiable claim may be generated by the verification entity. In this case, the claim publisher may impose a condition requiring the subject entity to grant permission to publish the requested verifiable claim.

[0020] Furthermore, in some embodiments, the conditions for issuing a verifiable claim also include receiving a certain amount of digital assets. Similar to the conditions for accessing a verifiable claim, this certain amount of digital assets is generated via anonymous digital assets, including but not limited to cryptocurrencies controlled by a distributed ledger. The digital assets can be any verifiable digital asset.

[0021] Additional features and advantages will be set forth in the following description and will be apparent in part from the description or may be learned by practice of the teachings herein. The features and advantages of the invention are 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 set forth below. Attached Figure Description

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

[0023] Figure 1 An example computing system in which the principles described herein are employed is shown;

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

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

[0026] Figure 4 An example of a decentralized personal storage or identity center is shown;

[0027] Figure 5 An example environment in which the principles described in this article are implemented is shown;

[0028] Figure 6 Example pair declarations are shown;

[0029] Figure 7 An example is shown to verify the pairwise declarations;

[0030] Figure 8 An example is shown to demonstrate paired rendering;

[0031] Figures 9A-9C This illustrates an example communication pattern that occurs between the claim publisher, the DID management module associated with the DID, the validator, the distributed ledger, and the identity center;

[0032] Figure 10 shows a flowchart of an example method for publishing verifiable pairwise statements;

[0033] Figure 11 A flowchart illustrating an example method for issuing a verifiable claim, which is constructed to be verifiable only by a second entity, is shown; and

[0034] Figure 12 A flowchart is shown for an example method used to apply conditions for accessing verifiable pairwise statements. Detailed Implementation

[0035] The embodiments disclosed herein relate to the publication of verifiable pairwise claims associated with a subject entity and verifiable by one or more predetermined verification entities. The subject entity is associated with a first identifier. The embodiments are implemented in a computational system of a claim publisher (hereinafter also referred to as the "claim publisher"). First, the claim publisher receives a request to publish a verifiable claim associated with a subject entity and verifiable by one or more predetermined verification entities. This request includes at least an encrypted portion using a specific type of cryptography. The claim publisher then verifies the association of the subject entity with the subject of the verifiable claim based on decrypting the encrypted portion using a specific type of cryptography (e.g., a private key pair and a public key pair). Hashes or tokens may also be used to verify the requesting entity. In response to verifying the association of the subject entity with the subject of the verifiable claim, the claim publisher's computational system is configured to publish verifiable claims for verification only by one or more predetermined entities or a defined list of entities.

[0036] In some embodiments, conditions are imposed for accessing a verifiable claim. When a requesting entity requests access to a verifiable claim, the claim publisher determines whether the conditions are met. The claim publisher notifies the subject entity of the determination that the conditions are met. In response to the determination that the conditions are met, the claim publisher sends a verifiable claim to the subject entity, and causes the subject entity to pass the verifiable claim to the requesting entity. Alternatively, the claim publisher sends the verifiable claim directly to the requesting entity.

[0037] This condition includes verifying that the requesting entity is one of a predefined set of one or more verification entities. At least one of the one or more verification entities is associated with a decentralized identifier (DID). Verifying the identity of the requesting entity includes verifying that the requesting entity is the holder of the DID.

[0038] Alternatively or otherwise, the condition may include receiving a certain amount of digital assets. Digital assets include verifiable digital assets. Verifiable digital assets are broadly defined as objects that have value and / or can only be consumed a limited number of times. Digital assets may be generated by any entity, or be required to be generated by one or more specific entities, such as the subject entity and / or one or more verification entities.

[0039] Alternatively or additionally, the conditions include a predetermined number of times the verifiable statement is allowed to be accessed. The conditions also include an expiration date for allowing access to the verifiable statement.

[0040] Furthermore, the verifiable claim is encrypted using one or more keys. In some embodiments, the one or more keys include the public keys of one or more verification entities, such that the encrypted verifiable claim can only be decrypted using the private keys of one or more verification entities. Alternatively or additionally, the one or more keys include the key of the subject entity, such that the encrypted verifiable claim can only be decrypted with the permission of the subject entity. Alternatively or additionally, the one or more keys include the key of the claim publisher.

[0041] The claim publisher sends an encrypted verifiable claim to the subject entity, which then passes the verifiable claim to a verification entity. Alternatively, the claim publisher sends the encrypted verifiable claim directly to at least one of one or more verification entities, causing the verification entity to request permission from the subject entity before accessing the received encrypted verifiable claim.

[0042] In some embodiments, when a claim publisher receives a request from a requesting entity for access to an encrypted verifiable claim, the claim publisher determines whether a condition has been met. In response to determining that the condition has been met, the claim publisher causes the requesting entity to receive one or more keys. At least one of the one or more keys is sent to the subject entity, causing the subject entity to decrypt the encrypted verifiable claim and send the decrypted verifiable claim to the requesting entity, or causing the subject entity to pass at least one key to the requesting entity. Alternatively, at least one key is sent directly to the requesting entity.

[0043] In some embodiments, conditions are imposed for publishing a verifiable claim. When a request to publish a verifiable claim is received, the claim publisher determines whether the conditions are met. The conditions for publishing a verifiable claim include verifying that the request to publish the verifiable claim was generated by a subject entity. The subject entity is associated with a decentralized identifier (DID). Verifying that the request to publish the verifiable claim was generated by a subject entity includes verifying that the requesting entity is the holder of the DID.

[0044] In response to a request to publish a verifiable claim generated by the subject entity, the claim publisher then generates the requested verifiable claim and causes it to be stored in the identity center associated with the DID. The identity center is a store of attributes under the control of the DID holder, including keys and metadata. The identity center is then instructed to send the verifiable claim to at least one of one or more verification entities.

[0045] In some embodiments, the request to publish a verifiable claim is not necessarily generated by the subject entity. For example, the request to publish a verifiable claim may be generated by the verification entity. In this case, the claim publisher imposes a condition, namely, that the subject entity grants permission to publish the requested verifiable claim.

[0046] Furthermore, in some embodiments, the conditions for issuing a verifiable claim also include receiving a certain amount of digital assets. Similar to the conditions for accessing a verifiable claim, this certain amount of digital assets is generated via anonymous digital assets, including but not limited to cryptocurrencies controlled by a distributed ledger. The digital assets are also any verifiable digital assets. The digital assets are generated by any entity, or are required to be generated by one or more specific entities, such as a subject entity and / or one or more verification entities.

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

[0048] Computing systems are increasingly taking on a variety of forms. For example, a computing system can 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 not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) comprising at least one physical and tangible processor and physical and tangible memory capable of having computer-executable instructions executed by the processor thereon. The memory takes any form and depends on the nature and form of the computing system. Computing systems are distributed over a network environment and comprise multiple component computing systems.

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

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

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

[0052] The term "executable component" is also well understood by those skilled in the art to include structures such as hard-coded or hard-wired logic gates, which are exclusively or nearly exclusively implemented in hardware, such as within a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or any other dedicated circuit. Therefore, the term "executable component" is a term for structures well understood by those skilled in the art of computing, whether implemented in software, hardware, or a combination thereof. In this specification, the terms "component," "agent," "manager," "service," "engine," "module," "virtual machine," etc., are also used. As used in this specification and examples, these terms (with or without modifications) are also intended to be synonymous with the term "executable component" and therefore also have the structure well understood by those skilled in the art of computing.

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

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

[0055] The embodiments described herein include or utilize dedicated or general-purpose computing systems comprising 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 can be any available media accessible by a general-purpose or dedicated computing system. A computer-readable medium storing computer-executable instructions is a physical storage medium. A computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: storage media and transmission media.

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

[0057] 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 another communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computing system appropriately regards the connection as a transmission medium. The transmission medium may include networks and / or data links that can be used to carry desired program code in the form of computer-executable instructions or data structures and that are accessible by general-purpose or special-purpose computing systems. Combinations of the foregoing should also be included within the scope of computer-readable media.

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

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

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

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

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

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

[0064] Not targeting Figure 2 This section provides an introductory discussion of decentralized identifiers (DIDs) and the environments in which they are created and reside. Figure 2 As shown, DID owner 201 owns or controls DID 205, which represents the identity of DID owner 201. DID owner 201 uses the creation and registration service to register DIDs, which will be explained in more detail below.

[0065] DID Owner 201 is any entity that can benefit from a DID. For example, DID Owner 201 is a person or an organization of a person. Such organizations may include corporations, departments, governments, agencies, or any other organization or group of organizations. Each individual can have a DID, and the organizations(s) to which each person belongs can also have DIDs.

[0066] 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 is a sub-part of a machine, system, or device. For example, a device may be a printed circuit board, wherein a sub-part of the circuit board is an individual component of the circuit board. In such embodiments, the machine or device has a DID and each sub-part also has a DID. The DID owner may also be a software component, such as those described above. Figure 1 The executable component 106 is described. An example of a complex executable component 106 could be artificial intelligence. Artificial intelligence also has a DID (Distributed Identifier).

[0067] Therefore, DID owner 201 is any reasonable entity, human or non-human, capable of creating DID 205 or at least having a DID 205 created for and associated with it. Although DID owner 201 is shown as having a single DID 205, this is not necessarily the case, as any number of DIDs associated with DID owner 201 may exist where circumstances permit.

[0068] As described above, DID owner 201 creates and registers DID 205. DID 205 is any identifier associated with DID owner 201. Preferably, this identifier is unique to the DID owner 201, at least within the scope of where the DID is expected to be used. As an example, the identifier is a locally unique identifier, and for an identity system expected to operate globally, a globally unique identifier may be preferred. In some embodiments, DID 205 is a Uniform Resource Identifier (URI) (such as a Uniform Resource Locator (URL)) or other pointer that associates DID owner 201 with a mechanism involved in trusted interactions with DID owner 201.

[0069] DID 205 is "decentralized" because it does not require a centralized third-party management system to generate, manage, or use it. Therefore, DID 205 remains under the control of DID owner 201. This differs from traditional centralized IDs based on the trust of a centralized authority, which remains under the control of a corporate directory service, credential authority, domain name registry, or other centralized entity (collectively referred to as "centralized authority" in this document). Therefore, DID 205 is any identifier under the control of DID owner 201 and independent of any centralized authority.

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

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

[0072] As will be described in more detail below, the private key 206 and public key 207 pair is generated on a device controlled by the DID owner 201. The private key 206 and public key 207 pair should not be generated on a server controlled by any centralized authority, as this would prevent the private key 206 and public key 207 pair from always being fully under the control of the DID owner 201. Although Figure 2 This specification describes private key pairs and public key pairs, but it should also be noted that other types of reasonable cryptographic information and / or mechanisms may be permitted as appropriate.

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

[0074] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 is used by third-party entities authorized 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.

[0075] DID document 210 also includes authentication information 211. Authentication information 211 specifies one or more mechanisms by which DID owner 201 can prove that DID owner 201 owns DID 205. In other words, the authentication of mechanism information 211 demonstrates proof of the binding between DID 205 (and therefore its DID owner 201) and DID document 210. In one embodiment, authentication information 211 specifies a public key 207 for signing operations to prove ownership of DID 205. Alternatively or additionally, authentication information 211 specifies a public key 207 for biometric operations to prove ownership of DID 205. Therefore, authentication information 211 includes any number of mechanisms by which DID owner 201 can prove that DID owner 201 owns DID 205.

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

[0077] Authorization information 212 also specifies one or more mechanisms that third parties will need to follow to prove they are authorized to modify DID document 210. In some embodiments, this mechanism is similar to those previously discussed with respect to authentication information 211.

[0078] DID document 210 also includes one or more service endpoints 213. A service endpoint includes a network address where a service operates on behalf of 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. Therefore, service endpoints 213 serve as pointers to services that operate on behalf of DID owner 201. These pointers are used by DID owner 201 or third-party entities to access services that operate on behalf of DID owner 201. Specific examples of service endpoints 213 will be explained in more detail below.

[0079] ID document 210 also includes identity information 214. Identity information 214 includes personally identifiable information such as the name, address, occupation, family members, age, hobbies, interests, etc. of DID owner 201. Therefore, the identity information 214 listed in DID document 210 represents different roles used by DID owner 201 for different purposes. For example, the role is pseudo-anonymous, such as DID owner 201 including a pseudonym in the DID document when identifying himself or her as an author of articles published on a blog; the role is completely anonymous, such as DID owner 201 only wanting to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years of age, etc.), but not his or her name in the DID document; and the role is specific to DID owner 201 as an individual, such as DID owner 201 including information identifying him or her as a volunteer for a specific charity, an employee of a specific company, a winner of a specific award, etc.

[0080] DID document 210 also includes credential information 215, which is also referred to herein as proof. Credential information 215 is any information associated with the background of DID owner 201. For example, credential information 215 is (but is not limited to) qualifications, achievements, government ID, government rights (such as a passport or driver's license), digital asset provider or bank account, university degree or other educational history, employment status and history, or any other information about the background of DID owner 201.

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

[0082] Figure 2 A distributed ledger or blockchain 220 is also shown. Distributed ledger 220 is any decentralized distributed network comprising various computing systems communicating with each other. For example, distributed ledger 220 includes a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems as indicated by ellipsis 260. Distributed ledger or blockchain 220 operates according to any known standards or methods for distributed ledgers.

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

[0084] As described above, the representation of DID 205 is stored on each distributed computing system of the distributed ledger or blockchain 220. For example, in Figure 2 This shows that DID hashes 231, 241, and 251 are ideally identical copies of the same DID. DID hashes 231, 241, and 251 therefore point to the location of DID document 210. The distributed ledger or blockchain 220 also stores many other representations of other DIDs, as indicated by reference numerals 232, 233, 234, 242, 243, 244, 252, 253, and 254.

[0085] In one embodiment, when DID user 201 creates DID 205 and the associated DID document 210, DID hashes 231, 241, and 251 are written to a distributed ledger or blockchain 220. The distributed ledger or blockchain 220 thus records that DID 205 now exists. Because the distributed ledger or blockchain 220 is decentralized, DID 205 is not controlled by any other entity besides DID owner 201. In addition to a pointer to DID document 210, DID hashes 231, 241, and 251 include a record or timestamp specifying when DID 205 was created. This is also recorded in DID hashes 231, 241, and 251 when DID document 210 is subsequently modified. DID hashes 231, 241, and 251 also include a copy of public key 207, which enables DID 205 to be cryptographically bound to DID document 210.

[0086] Already referenced Figure 2 Having described DIDs and how they generally operate, we will now explain specific implementations of DIDs. (Continue...) Figure 3 The environment 300 used to perform various DID lifecycle management operations and services will now be explained. It should be understood that, for ease of explanation, Figure 3 The environment needs to be referenced from Figure 2 Element.

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

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

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

[0090] Specific embodiments will now be described. For example, UI 335 provides a prompt for the user to enter a username or some other human-recognizable name. This name serves as the display name for the generated DID 205. As previously mentioned, DID 205 is a long string of random numbers and letters, and therefore having a human-recognizable name for the display is advantageous. DID creation module 330 then generates DID 205. In embodiments with UI 335, DID 205 is displayed in an identity list and associated with a human-recognizable name.

[0091] The DID creation module also includes a key generation module 350. The key generation module generates the previously described private key pair 206 and public key pair 207. The DID creation module 330 then uses the DID 205, along with the private key pair and public key pair, to generate a DID document 210.

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

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

[0094] As previously described, the key generation module 350 generates a private key pair 206 and a public key pair 207. The public key 207 is then recorded in the DID document 210. Therefore, the public key 207 is used by all devices associated with the DID owner 201 and all third parties wishing to provide services to the DID owner 201. Thus, when the DID owner 201 wishes to associate a new device with 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 DID 205, and this will be reflected in the updated transactions on the distributed ledger 220, as previously described.

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

[0096] In those embodiments where additional public keys 208 and 209 are associated with different devices, additional public keys 208 and 209 are recorded in DID document 210 as associated with those devices. This is in Figure 3 As shown in the image. It should be understood that, in addition to... Figure 3 In addition to the information shown, DID document 210 also includes previous information about Figure 2 The information described. If DID document 210 exists before the device-specific public key is generated, DID document 210 will be updated by creation module 330 via registrar 310, and this will be reflected in the updated transactions on distributed ledger 220.

[0097] In some embodiments, the DID owner 201 can keep the association between the device and the public key or even the DID 205 confidential. Therefore, the DID creation module 330 makes such data confidentially displayed in the DID document 210.

[0098] As described so far, DID 205 is already associated with all devices under the control of DID owner 201, even when the devices have their own public keys. However, in some embodiments, it is useful for each device or a subset of devices under the control of DID owner 201 to have its own DID. Therefore, in some embodiments, DID creation module 330 generates an additional DID for each device, such as DID 331. The creation module then generates a private and public key pair and a DID document for each device and records them on distributed ledger 220 in the manner described above. Such embodiments are advantageous for devices whose ownership changes, as a particular device DID can be associated with the new owner of the device by granting authorization permissions to the new owner in the DID document and revoking such permissions from the old owner.

[0099] As mentioned, to ensure the private key remains entirely under the control of the DID owner 201, it is created on the user device 301, browser 302, or operating system 303 owned or controlled by the DID owner 201, who is implementing the DID management module 320. In this way, the likelihood of a third party gaining control of the private key 206 is very small, especially for the provider of the DID lifecycle management module 320. 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. Therefore, in some embodiments, the UI 335 includes an option to allow the DID owner 201 to export the private key 206 to a closed device security database 305 under the control of the DID owner 201. In some embodiments, the private key 206 is stored as a QR code scanned by the DID owner 201.

[0100] In other embodiments, the DID lifecycle management module 320 includes a recovery module 360 ​​for recovering a lost private key 206. In operation, the recovery module 360 ​​allows the DID owner 201 to select one or more recovery mechanisms 365 at the time of DID 205 creation, which are later used to recover the lost private key. In those embodiments with a UI 335, the UI 335 allows the DID owner 201 to provide the necessary information that one or more recovery mechanisms 365 will require when the recovery mechanisms are implemented. The recovery module then operates on any device associated with DID 205.

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

[0102] Figure 4 An embodiment of an environment 400 in which a DID such as DID 205 is used is illustrated. Specifically, environment 400 will be used to describe the use of DID 205 in relation to one or more decentralized personal stores or identity centers. The identity center is a store of attributes, including keys and metadata under the control of the DID holder. It should be noted that Figure 4 Including the first regarding Figure 2 or Figure 3 The references to elements discussed and therefore used with the same reference numerals for ease of explanation.

[0103] In one embodiment, identity center 410 is multiple instances of the same identity center. This is indicated by line 410A. Therefore, the various identity centers 410 include at least some of the same data and services. Thus, if any change is made to one of the identity centers 410, that change is reflected in the remaining identity centers. For example, the first identity center 411 and the second identity center 412 are implemented in cloud storage and are therefore capable of storing large amounts of data. Thus, a complete set of data is stored in these identity centers. However, identity centers 412 and 413 have less storage space. Therefore, descriptors of the data stored in the first and second identity centers are included in these identity centers. Alternatively, records of changes made to data in other identity centers are included. Thus, a change in one of the identity centers 410 is either completely copied to the other identity centers, or at least a record or descriptor of that data is recorded in the other identity centers.

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

[0105] In one embodiment, the stored data has different authentication and privacy settings 421 associated with it. For example, a first subset of the data has setting 421, which allows the data to be publicly disclosed but does not include any authentication of the DID owner 201. This type of data is used for relatively unimportant data, such as color schemes. A second subset of the data has setting 421, which allows the data to be publicly disclosed and includes authentication of the DID owner 201. A third subset of the data has setting 421, which encrypts a subset of the 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 would require a party to have access to public key 207 or some other relevant public key in order to decrypt the data. The process also includes authentication of the DID owner 201. A fourth subset of the data has setting 421 that restricts this data to a third-party subset. This requires the use of the public key associated with the third-party subset to decrypt the data. For example, DID owner 201 causes setting 421 to specify that only the public key associated with a friend of DID owner 201 can decrypt the data.

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

[0107] Identity center 411 also has a messaging module 440. In operation, the messaging module allows the identity center to receive messages, such as requests from parties like third parties 401 and 402 to access the identity center's data and services. Furthermore, messaging module 440 allows identity center 411 to respond to messages from third parties and also communicates with DID resolver 450. This will be explained in more detail later. The ellipsis 416 indicates that identity center 411 has additional services when circumstances permit.

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

[0109] However, Identity Center 411 did not initially recognize the new device as owned by DID owner 201. Therefore, Identity Center 411 used messaging module 440 to contact DID resolver 450. The message sent to DID resolver 450 included DID 205.

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

[0111] As previously described, DID document 210 includes a public key 208 or 209 associated with the new user equipment 301. To verify that the new user equipment is owned by the DID owner 201, identity center 411 provides a password challenge to the new user equipment 301 using messaging module 440. This password challenge will be constructed such that only devices authorized to access private key 206 will be able to successfully answer the challenge.

[0112] In this embodiment, the challenge is successfully answered because the new user equipment is owned by the DID owner 201 and therefore has access to the private key 206. Identity center 411 then records in permission 430 that the new user equipment 301 is able to access data and services of identity center 411 and the rest of identity center 210.

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

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

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

[0116] Third party 401 sends a message to messaging module 440 requesting permission to access research data. Messaging module 440 then sends a message to DID owner 201 to inquire whether permission should be granted to third party 401 to access the research data. Because the DID owner wishes to grant access to the data, DID owner 201 grants permission to third party 401, and this permission can be recorded in permission 430.

[0117] The messaging module 440 then sends a message to the third party 401 to notify the third party that he or she has access to the research data. Identity center 411 and third party 401 then communicate directly to enable the third party to access the data. It should be noted that in many cases, the entity communicating with identity center 411 is actually the identity center associated with third party 401. However, the communication is conducted by the device of third party 401.

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

[0119] As described above, Identity Center 411 is hosted in a cloud service. The service provider can access the data stored in each user's Identity Center 411. Furthermore, the service provider can also access certain activities of the DID owner. For example, a DID owner may share data with entities stored in Identity Center 411. As another example, a user may have multiple DIDs and share data among them; alternatively, the user may access the same data using different DID management modules. Based on these data-sharing activities, the service provider of Identity Center 411 can correlate different DIDs and identify whether two DIDs are related or belong to the same owner. Therefore, the user's privacy is compromised.

[0120] The principles described in this article address these potential privacy concerns for DID owners by encrypting personal data stored in Identity Center 411. Identity Center 411 does not store or access encryption / decryption keys, therefore DID owners do not have extensive control over the data of other DID owners or users, and their privacy is protected by the service provider.

[0121] Identity Center 411 stores many different objects. A data object is any file, folder, or part of data stored in Identity Center 411. The entire Identity Center 411 is encrypted as an object using a single encryption / decryption key. Alternatively, different parts of the data stored in Identity Center 411 are encrypted using different encryption / decryption keys.

[0122] In another example embodiment, a verifiable claim is published and stored in Identity Center 411. For example, a verifiable claim associated with DID owner 201 is published by a claim-issuing entity, and the published verifiable claim is stored in Identity Center 411 associated with DID owner 201. When another entity needs to verify the DID owner's credentials, DID owner 201 sends the verifiable claim to the other entity. For example, DID owner 201 is a person holding a driver's license, and the claim-issuing entity is the DMV that issued the DID owner's driver's license. The DMV publishes a verifiable claim that verifies DID owner 201 holds a valid driver's license. DID owner 201 stores the verifiable claim in Identity Center 411. The other entity is a car rental company that requires DID owner 201 to prove that he / she has a valid driver's license. The DID owner then sends the verifiable claim stored in Identity Center 411 to the car rental company.

[0123] The principles described herein involve publishing pairwise verifiable claims associated with a subject entity and verifiable by a second entity. Further details of embodiments for publishing pairwise verifiable claims will be found in [reference]. Figures 5 to 1 5. Describe it.

[0124] Figure 5 An environment 500 is shown where verifiable claims are published and accessed. Identity Center 501 corresponds to... Figure 4 Identity Center 411, DID Management Module 503 corresponds to Figure 3 The DID management module 320 and the distributed ledger 505 correspond to Figure 2 Distributed ledger 220.

[0125] Verifiable claims, also known as verifiable credentials, provide a way to express claims and / or credentials on a cryptographically secure, privacy-respecting, and automatically verifiable computer network. Claims and / or credentials can be used for various forms of identification, such as a driver's license to assert an entity's ability to operate a motor vehicle, a university degree to assert an entity's educational level, or a passport to enable an entity to travel abroad. In various situations, one entity needs to demonstrate its training, skills, and other qualifications to another entity. For example, when a customer rents a car, the rental company often requires the customer to present their driver's license in person. Verifiable claims would allow such verification to be performed via a computer network.

[0126] For example, such as Figure 5 As shown, the customer is the DID owner 201 associated with DID 205. DID owner 201 has access to the DID management module 503. In some cases, DID owner 201 wants to rent a car from a rental company. Before the rental company agrees to lease the car to the DID owner, it needs to verify the DID owner's driver's license, which is issued by the DMV. Therefore, the DMV is the example claim issuer 502, and the rental company is the example verifier 504.

[0127] like Figure 5 As shown, verifier 504 (e.g., a car rental company) requests DID management module 503 to display a verifiable claim published by claim publisher 502, indicated by arrow 509. DID management module 503 then requests claim publisher 502 to publish the verifiable claim required by verifier 504, indicated by arrow 507. Claim publisher 502 will verify DID 205 of the DID owner. In response to the verification of DID 205, claim publisher 502 publishes a verifiable claim and sends the published verifiable claim to DID management module 503, indicated by arrow 508. Claim publisher 502 will also record the transaction of publishing the verifiable claim in distributed ledger 505, indicated by arrow 511.

[0128] Upon receiving a verifiable claim, the DID management module 503 records the received verifiable claim in the identity center 501, as indicated by arrow 506. The DID management module 503 then sends the recorded verifiable claim to the verifier 504, as indicated by arrow 510. The verifier 504 then accesses the distributed ledger 505 to verify the verifiable claim. During this process, the claim publisher 502, the DID management module 503, and the verifier 504 also authenticate or verify the DID 205 of the DID owner 201. Alternatively or additionally, each of the claim publishers 502 and verifiers 504 is also associated with a DID, and each DID of the claim publishers 502 and verifiers 504 is also authenticated or verified by the DID management module 503.

[0129] In particular, the principles described in this article involve publishing and accessing paired verifiable claims. References will now be made to... Figure 6 and Figure 7 Let's discuss more details regarding "paired" and "verifiable" claims. A "claim" is a statement about a subject. Claims are typically expressed using a subject-property-value relationship. A paired claim is a claim that can only be accessed by one or more specific verifiers. Therefore, even if subjects have the same property value, separate paired claims will be issued for different sets of verifiers.

[0130] Figure 6 Example paired statement 600 is shown. Paired statement 600 includes statement 610 and one or more pre-defined validators 650, including validators 651 and 652. The ellipsis 653 indicates the existence of any natural number of pre-defined validators. Statement 610 and one or more validators 650 form a pair, referred to as paired statement 600. Statement 610 includes subject 620. Subject 620 is associated with one or more attributes 631, 632. For example, attribute 631 is associated with a driver's license, and attribute 632 is associated with an age greater than 21. Each attribute has a corresponding value 641, 642. For example, the driver's license attribute 631 has the value "valid" or "invalid," and the age greater than 21 attribute 632 has a numerical value as the object's age, or a binary value indicating "equal to or greater than 21" or "less than 21." The ellipsis 633, 643 indicate the existence of any number of attributes (and corresponding values) associated with subject 620.

[0131] Figure 7 An example of a verifiable pairwise statement 700 is shown. Verifiable pairwise statement 700 adds additional information to pairwise statement 702 so that the verifier can trust pairwise statement 702. Pairwise statement 702 corresponds to... Figure 6 Paired declarations 600. For example... Figure 7As shown, the verifiable pairwise claim 700 includes a claim ID 701, which uniquely identifies the pairwise claim 702. Claim 700 also includes metadata describing the attributes of the pairwise claim 702, such as publisher (e.g., 502), verifier (e.g., 504), expiration time, cost per access, etc. Furthermore, the verifiable claim 700 includes a publisher signature 704, enabling the publication of the claim to be cryptographically verifiable and ensuring the claim is tamper-proof.

[0132] When the DID management module 503 presents the verifiable pair statement 700 to the verifier 504, the DID management module 503 further organizes a set of one or more verifiable pair statements into a verifiable pair presentation. Figure 8 An exemplary verifiable pairwise presentation 800 is shown. The verifiable pairwise presentation 800 includes one or more verifiable pairwise statements 802, 803, wherein each verifiable pairwise statement corresponds to... Figure 7 Verifiable pairwise statements 700. The ellipsis 804 indicates that any number of verifiable pairwise statements are included in the verifiable pairwise presentation 800. The verifiable pairwise presentation 800 includes a presentation ID 801 that uniquely identifies the pairwise presentation 800. The verifiable pairwise presentation also includes a signature 805 signed by the DID management module 503, enabling the presentation presented by the DID owner 201 (or DID 205) to be password-verified.

[0133] During the process of requesting, publishing, and accessing verifiable pairwise claims, the claim publisher (e.g., Figure 5 502), DID management module (e.g., Figure 5 503 for the validator and 504 for the validator (e.g., Figure 5 504 errors), Identity Center (e.g., Figure 5 501) and distributed ledgers (e.g., Figure 5 Various communications occur between (505). Figures 9A-9C This illustrates several example communication patterns between these entities. (Reference) Figures 9A-9C The statement publisher 902 corresponds to Figure 5 The statement publisher 502, DID management module 903 corresponds to Figure 5 The DID management module 503, verifier 904 corresponds to Figure 5 The validator 504 and the distributed ledger 905 correspond to... Figure 5 The distributed ledger 505 and the identity center 901 correspond to Figure 5 Identity Center 501.

[0134] refer to Figure 9AVerifier 904 sends a request for a verifiable claim to DID management module 903, as indicated by arrow 906. In response to the received request, DID management module 903 verifies the identity of verifier 904 using distributed ledger 905, as indicated by arrow 907. After verifier 904's identity is verified using distributed ledger 905, DID management module 903 then sends a request for a verifiable pair of claims to claim publisher 902, as indicated by arrow 908. The request includes a first DID 205 associated with DID management module 903 and the identity of verifier 904. For example, verifier 905 may be associated with a second DID, and the second DID may also be included in the request.

[0135] When the claim publisher 902 receives a request, it uses the distributed ledger 905 to verify the identity of the first DID 205 and / or the verifier 904 (e.g., the second DID associated with verifier 904), as indicated by arrow 909. After the identity of the first DID 205 and / or the verifier 904 is verified, the claim publisher 902 generates verifiable pairwise claims (e.g., Figure 7 (700), indicated by arrow 910. The claim publisher 902 also records the publication transaction of the verifiable pairwise claim in ledger 905, indicated by arrow 911. Next, the claim publisher 902 sends the generated verifiable pairwise claim to the DID management module 903, indicated by arrow 912.

[0136] The DID management module 903 receives verifiable pairwise claims from the claim publisher 902 and stores the received verifiable pairwise claims in the identity center 901, as indicated by arrow 913. The DID management module 903 then generates verifiable pairwise representations (e.g., Figure 8 The verifiable pair representation (800) is then sent to the verifier 904, as indicated by arrow 914. The verifier 904 receives the verifiable pair representation from the DID management module 903 and then verifies or authenticates it using the distributed ledger 905, as indicated by arrow 915.

[0137] Figure 9B This illustrates another example communication pattern between the claim publisher 902, the DID management module 903, the verifier 904, and the distributed ledger 905. (Example...) Figure 9BAs shown, verifier 904 sends a request for a verifiable claim directly to claim publisher 902, as indicated by arrow 921. The request includes a DID 205 associated with the subject of the requested verifiable claim and the identity of verifier 904 (e.g., the DID associated with verifier 904). After receiving the request, claim publisher 902 verifies the DID 205 associated with the subject of the verifiable claim and / or the identity of the verifier using distributed ledger 905, as indicated by arrow 922. Furthermore, the claim publisher notifies verifier 904 (as associated with the subject of the verifiable claim) that a verifiable claim has been requested, as indicated by arrow 923. In some embodiments, claim publisher 902 requests permission from DID management module 903 to publish such a verifiable claim prior to its publication.

[0138] In response to the verification of DID 205 and / or the identity of the verifier 904, and the receipt of permission from the DID management module 903, the claim publisher 902 generates verifiable paired claims (e.g., Figure 7 (700), indicated by arrow 924. The statement publisher 902 then records the verifiable pairwise statement publication transaction in ledger 905, indicated by arrow 925.

[0139] Subsequently, the statement issuer 902 sends the verifiable statement directly to the verifier 904, as indicated by arrow 926. After receiving the verifiable statement, the verifier 904 verifies and / or authenticates the verifiable statement using the distributed ledger 905, as indicated by arrow 927. In response to the verification and / or authentication of the verifiable statement, the verifier 904 notifies the DID management module 903 of the verification and / or authentication result, as indicated by arrow 928. For example, the verifier 904 is a car rental company, and the statement issuer 902 is the DMV. When the car rental company 904 receives and verifies the statement issued by the DMV 902 proving that the DID owner 201 holds a valid driver's license, the car rental company 904 sends an approval notification to the DID management module 903, allowing the DID owner 201 to complete the car rental transaction with the car rental company 904.

[0140] Figure 9C This further illustrates the communication pattern between the claim publisher 902, the DID management module 903, the verifier 904, the distributed ledger 905, and the identity center 901 when verifiable paired claims have been previously published and stored in the identity center 901. (Reference) Figure 9CVerifier 904 first sends a request for a verifiable claim to DID management module 903, as indicated by arrow 931. Here, DID management module 903 then accesses identity center 901 to see if the requested verifiable claim has been previously published and stored in identity center 901. For example, verifier 904 is a car rental company, and DID owner 201 has previously rented a car from car rental company 904. In response to detecting that a previously published pair of claims is stored in identity center 901, DID management module 903 retrieves the previously published verifiable pair of claims, as indicated by arrow 932. DID management module 903 also generates a verifiable pair representation and sends the verifiable pair representation to verifier 904, as indicated by arrow 933.

[0141] In some embodiments, the published verifiable pairwise statement is encrypted by a key of the statement publisher 902. When the verifier 904 receives the verifiable pairwise statement from the DID management module 903 and attempts to access it, the verifier 904 and / or the DID management module 903 are prompted to send a notification to the statement publisher 902, as indicated by arrow 934. After receiving the notification, the statement publisher 902 uses the distributed ledger 905 to verify the DID 205 associated with the subject of the verifiable pairwise statement and / or the identity of the verifier 904, as indicated by arrow 935. In response to the verification, the statement publisher 902 then sends the decryption key to the verifier 904, as indicated by arrow 936.

[0142] In some embodiments, the claim publisher 902 imposes additional conditions before sending the decryption key to the verifier 904. For example, the verifiable pair claim includes an expiration date, and the claim publisher 902 verifies whether a previously published verifiable pair claim has expired. The claim publisher 902 only sends the decryption key to the verifier 904 if the claim has not expired. When it is determined that a previously published verifiable pair claim has expired, the claim publisher 902 simply notifies the verifier and / or the DID management module 903 that the claim has expired. Alternatively or additionally, the claim publisher 902 requests the verifier 904 and / or the DID management module 903 to pay a predetermined fee to republish the claim. The claim publisher 902 will only republish a new verifiable pair claim with a new expiration date after the DID management module 903 and / or the verifier 904 pay the predetermined fee to the claim publisher 902. Finally, after verifier 904 receives the decryption key or a new verifiable pair of claims, verifier 904 uses the distributed ledger 905 to verify and / or authenticate the claims, as indicated by arrow 937.

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

[0144] Figure 10 illustrates a flowchart of an example method 1000 for publishing verifiable pairwise claims associated with a subject entity and verifiable by one or more verification entities. Method 1000 is implemented at the claim publisher's computing system. The subject entity corresponds to the DID owner 201 associated with the DID management module 503, and the one or more verification entities correspond to... Figure 5 The verifier returned a 504 error. Verifiable paired statements correspond to... Figure 7 Verifiable pairwise declarations 700.

[0145] Method 1000 includes receiving a request for a verifiable claim (1001). The verifiable claim is associated with a subject entity and is verifiable by one or more verification entities. The request is sent from the subject entity or one or more verification entities. For example, as... Figure 9A As shown, the request is sent from the subject entity (e.g., DID management module 903); and as Figure 9B As shown, the request was sent from one or more verification entities (i.e., verifier 904).

[0146] Upon receiving a request for a verifiable claim, the computing system then verifies that the subject entity is associated with the subject of the verifiable claim (1002). For example, the subject entity is a customer who wants to rent a car from a car rental company. The car rental company is an example of one or more verification entities that need to verify whether the customer has a valid driver's license. Since the driver's license is issued by the DMV, the DMV is the claim issuer, which receives the request for the verifiable claim. The DMV verifies whether the customer's DID is associated with the driver's license. In response to the verification, the verifiable claim is then issued (1003).

[0147] A verifiable claim is sent to the subject entity (1004). The verifiable claim is also stored in the identity center associated with the subject entity (1005). In some embodiments, the identity of one or more verifying entities is also verified (1006). Verifiable pairwise claims are then sent to one or more verifying entities (1007). Figure 9A As shown, in some embodiments, verifiable pairwise claims are sent from the subject entity (i.e., DID management module 903) to one or more verification entities. Figure 9B As shown, in some embodiments, verifiable pairwise claims can be sent directly from the claim publisher 902 to one or more verification entities.

[0148] Different embodiments are implemented to issue verifiable claims that are constructed to be verifiable only by one or more verification entities. In some embodiments, the verifiable claim is encrypted with the public key of one or more verification entities, such that the one or more verification entities can decrypt the encrypted verifiable claim using their private key. For example, when one or more verification entities are associated with a second DID, the verifiable claim is encrypted with the public key associated with the second DID.

[0149] In some embodiments, the claim can be verified by the claim publisher's key being encrypted. Figure 11 A flowchart of an example method 1100 for issuing a verifiable claim, which is constructed to be verifiable only by one or more verification entities, is shown. This flowchart corresponds to step 1003 of Figure 10. Figure 11 As shown, method 1100 includes encrypting a verifiable claim using a key from the claim publisher (1101). When the encrypted verifiable claim is accessed by one or more verification entities, the claim publisher receives a notification (1102). This notification is sent by a first computing system (e.g., DID management module 903) and / or a second computing system (e.g., the verifier's computing system 904). In response to the receipt of the notification, the identity of one or more verification entities is verified (1103). In response to the verification, a key is then sent to one or more verification entities (1104), causing one or more verification entities to decrypt the encrypted verifiable claim using the key (1105).

[0150] Figure 12 A flowchart of an example method 1200 for imposing conditions for accessing verifiable pairwise claims is shown. Method 1200 is also implemented at the claim publisher. Method 1200 includes imposing conditions (1210) for accessing verifiable pairwise claims. These conditions include (but are not limited to) an expiration time (1211). Digital assets include verifiable digital assets. Verifiable digital assets are broadly defined as objects having value and / or being consumed only a limited number of times. Digital assets are generated by any entity, or are required to be generated by one or more specific entities, such as a subject entity and / or one or more verification entities. Furthermore, the quantity of digital assets is generated via anonymous digital assets, including but not limited to cryptocurrencies controlled by a distributed ledger. In some cases, a digital asset is any verifiable digital asset.

[0151] The ellipsis 1213 indicates that there are any number of conditions to be imposed. For example, verifying the identity of the requesting entity is also a condition.

[0152] When a verifiable statement is accessed, the statement publisher receives a request from the requesting entity for accessing the verifiable statement (1220). In response to the request, the statement publisher determines whether conditions are met (1230). For example, the statement publisher determines whether the statement has expired and / or whether the verifier or the subject of the statement is required to pay a fee each time the statement is accessed.

[0153] When the condition is met, i.e., determined to be "yes" (1231), the statement publisher grants the verifier access to the verifiable statement (1240). When the condition is not met, i.e., determined to be "no" (1232), the statement publisher denies the verifier access to the verifiable statement (1250). Regardless of whether access to the verifiable statement is granted or denied, the subject entity receives a notification of the result (1260). Furthermore, when access to the verifiable statement is denied (1250), one or more verification entities (i.e., verifiers) perform certain tasks to ensure that the condition is met (1270). For example, when the verifiable statement has expired, one or more verification entities are allowed to pay a fee to have the statement publisher republish the verifiable statement with a new expiry date.

[0154] The principles described herein allow for the specific publication of verifiable claims between a subject entity and one or more specific verification entities. Each of the subject entity and one or more verification entities is associated with an identifier, which is a DID or a centralized identifier. In some embodiments, at least some of the object and / or verification entities are associated with device identifiers, i.e., not directly with human identifiers, such that the identifiers associated with the object and / or verification entity are not considered personally identifiable information. When two entities communicate with each other, they can exchange each other's DIDs, along with one or more verifiable pair claims. Personally identifiable information is included in the verifiable pair claims. Because these verifiable claims are paired, only the two entities involved will know the content of the respective verifiable claims. Therefore, user privacy is further protected.

[0155] Furthermore, when the principles described in this paper are implemented in a decentralized environment, such as using a distributed ledger or blockchain, the DID associated with a device (which is not considered personally identifiable information) is propagated to the distributed ledger under various privacy laws; and personally identifiable information will only appear in encrypted, verifiable pairwise claims, which can only be viewed by the subject entity and the corresponding verification entity.

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

[0157] The invention may be practiced in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A computing system for issuing and managing verifiable claims, comprising: One or more processors; as well as One or more computer-readable media having computer-executable instructions that can be executed by the one or more processors to cause the computing system to: Receive a first request for publishing a first pairwise verifiable claim associated with a subject entity and verifiable by a first verification entity, the first request including at least an encrypted portion using a specific type of cryptography; Based on receiving the first request: The subject entity is verified to be the subject of the first pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography described above; as well as In response to verifying that the subject entity is the subject of the first pairwise verifiable claim, the first pairwise verifiable claim is published to the first verifying entity, including encrypting the first pairwise verifiable claim using a first cryptographic public key associated with the first verifying entity, thereby allowing decryption of the first verifying entity by the first private key; Receive a second request for publishing a second pairwise verifiable claim associated with the subject entity and verifiable by a second verification entity, the second request including at least an encrypted portion using a specific type of cryptography; as well as Based on receiving the second request: The subject entity is verified as the subject of the second pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography. as well as In response to verifying that the subject entity is the subject of the second pairwise verifiable claim, the second pairwise verifiable claim is published to the second verifying entity, including encrypting the second pairwise verifiable claim using a second cryptographic public key associated with the second verifying entity, thereby allowing decryption of the second verifying entity by the second private key; The first pairwise verifiable claim and the second pairwise verifiable claim are published to the corresponding verification entities of the first pairwise verifiable claim and the second pairwise verifiable claim using the same decentralized identifier (DID) of the subject entity.

2. The computing system of claim 1, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: Apply conditions for accessing verifiable claims; and When a requesting entity requests access to the verifiable statement, it is determined whether the condition is met.

3. The computing system of claim 2, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: In response to the determination that the condition is satisfied, the verifiable claim is sent to the subject entity; and This causes the subject entity to pass the verifiable claim to the request entity.

4. The computing system of claim 2, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: In response to the determination that the condition has been met, the verifiable declaration is sent directly to the requesting entity.

5. The computing system according to claim 2, wherein: The conditions include verifying that the identity of the requesting entity is one of a predetermined set of verification entities.

6. The computing system according to claim 5, wherein: At least one verification entity is associated with a decentralized identifier (DID), and Verifying the identity of the requesting entity includes verifying that the requesting entity is the holder of the DID.

7. The computing system of claim 2, wherein the condition includes receiving a certain amount of anonymous digital assets.

8. The computing system of claim 2, wherein the conditions include a predetermined number of times the verifiable claim is allowed to be accessed and / or an expiration time for allowing the verifiable claim to be accessed.

9. The computing system of claim 2, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to encrypt the verifiable statement with one or more keys to create an encrypted verifiable statement.

10. The computing system of claim 9, wherein the one or more keys include a public key of a verification entity, such that the encrypted verifiable claim can only be decrypted by the private key of the verification entity.

11. The computing system of claim 9, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: Send the encrypted verifiable claim to the subject entity; and This causes the subject entity to pass the verifiable claim to the verification entity.

12. The computing system of claim 9, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: Receive a request from the requesting entity for accessing the encrypted verifiable claim; Determine whether the condition is met; and In response to the determination that the condition is met, the requesting entity receives the one or more keys.

13. The computing system of claim 1, wherein the computer-executable instructions are further executable by the one or more processors to cause the computing system to: Apply a second condition for issuing the verifiable statement; and When the request for publishing the verifiable statement is received, it is determined whether the second condition is met.

14. A method in a computing system comprising one or more processors, the method comprising: Receive a first request for publishing a first pairwise verifiable claim associated with a subject entity and verifiable by a first verification entity, the first request including at least an encrypted portion using a specific type of cryptography; Based on receiving the first request: The subject entity is verified to be the subject of the first pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography described above; as well as In response to verifying that the subject entity is the subject of the first pairwise verifiable claim, the first pairwise verifiable claim is published to the first verifying entity, including encrypting the first pairwise verifiable claim using a first cryptographic public key associated with the first verifying entity, thereby allowing decryption of the first verifying entity by the first private key; Receive a second request for publishing a second pairwise verifiable claim associated with the subject entity and verifiable by a second verification entity, the second request including at least an encrypted portion using a specific type of cryptography; as well as Based on receiving the second request: The subject entity is verified as the subject of the second pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography. as well as In response to verifying that the subject entity is the subject of the second pairwise verifiable claim, the second pairwise verifiable claim is published to the second verifying entity, including encrypting the second pairwise verifiable claim using a second cryptographic public key associated with the second verifying entity, thereby allowing decryption of the second verifying entity by the second private key; The first pairwise verifiable claim and the second pairwise verifiable claim are published to the corresponding verification entities of the first pairwise verifiable claim and the second pairwise verifiable claim using the same decentralized identifier (DID) of the subject entity.

15. The method of claim 14, further comprising: Apply conditions for accessing verifiable claims; as well as When a requesting entity requests access to the verifiable statement, it is determined whether the condition is met.

16. The method of claim 15, further comprising: In response to the determination that the condition is met, the verifiable statement is sent to the subject entity; as well as This causes the subject entity to pass the verifiable claim to the request entity.

17. The method of claim 15, further comprising: In response to the determination that the condition has been met, the verifiable declaration is sent directly to the requesting entity.

18. The method of claim 15, wherein: The conditions include verifying that the identity of the requesting entity is one of a predetermined set of verification entities.

19. The method of claim 18, wherein: At least one verification entity is associated with a decentralized identifier (DID), and Verifying the identity of the requesting entity includes verifying that the requesting entity is the holder of the DID.

20. A computer-readable physical storage medium having computer-executable instructions thereon, the computer-executable instructions being configured such that, when executed by one or more processors, the computer-executable instructions cause a computing system to at least: Receive a first request for publishing a first pairwise verifiable claim associated with a subject entity and verifiable by a first verification entity, the first request including at least an encrypted portion using a specific type of cryptography; Based on receiving the first request: The subject entity is verified to be the subject of the first pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography described above; as well as In response to verifying that the subject entity is the subject of the first pairwise verifiable claim, the first pairwise verifiable claim is published to the first verifying entity, including encrypting the first pairwise verifiable claim using a first cryptographic public key associated with the first verifying entity, thereby allowing decryption of the first verifying entity by the first private key; Receive a second request for publishing a second pairwise verifiable claim associated with the subject entity and verifiable by a second verification entity, the second request including at least an encrypted portion using a specific type of cryptography; as well as Based on receiving the second request: The subject entity is verified as the subject of the second pairwise verifiable claim by decrypting the encrypted portion using the specific type of cryptography. as well as In response to verifying that the subject entity is the subject of the second pairwise verifiable claim, the second pairwise verifiable claim is published to the second verifying entity, including encrypting the second pairwise verifiable claim using a second cryptographic public key associated with the second verifying entity, thereby allowing decryption of the second verifying entity by the second private key; The first pairwise verifiable claim and the second pairwise verifiable claim are published to the corresponding verification entities of the first pairwise verifiable claim and the second pairwise verifiable claim using the same decentralized identifier (DID) of the subject entity.

Images