System and method for conducting transactions on a network

Abstract

A system and method for conducting transactions over a network. A first agent and a second agent are provided. The second agent is capable of transacting with a third agent for the use of a service, and the third agent is capable of communicating with a fourth agent. The first agent is operable to communicate with the second agent to facilitate a transaction for the use of the service by the second agent with the third agent. The first agent is further operable to communicate with the fourth agent to facilitate a transaction for the use of the service by the second agent with the third agent.

Description

Technical Field

[0001] The present invention generally relates to digital communications, and more particularly to conducting transactions over a network.

[0002] Self-sovereign identity (SSI) is a concept or model that enables individuals to manage their digital identities. SSI systems are generally decentralized, allowing holders (e.g., individuals or organizations) to generate and maintain a unique identifier known as a decentralized identifier (DID). Credentials issued by an entity, typically an organization, acting as an issuer are provided by a specific party (the "holder") to another party (the "verifier") to verify the identity information contained within the credentials of the specific party. The SSI infrastructure used by issuers, verifiers, and holders is usually open source, but many individual standards are utilized for elements of the technology stack. Providers of SSI infrastructure offer proprietary software such as applications that perform transaction processing.

Summary of the Invention

[0003] This summary is provided to introduce a simplified concept that will be described later in the "Detailed Description of Exemplary Embodiments." This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] A method for conducting a transaction on a network is provided. The method includes receiving, by a first agent, a digitally signed transaction from a second agent, the digitally signed transaction having been received by the second agent from a third agent and including a digital signature. A first verifiable proof is received by the first agent from a fourth agent. The first verifiable proof is sent by the first agent to a fifth agent. The first agent receives, from the fifth agent, an unlock signature for locked credentials provided to the second agent by a sixth agent. The unlock signature is sent by the first agent to the fourth agent.

[0005] A further method for conducting a transaction on a network is provided. The further method includes receiving, by a first agent, a first transaction from a second agent, the first transaction having been initiated by a third agent. The first agent sends a first verifiable proof to a fourth agent. The first agent receives, from the fourth agent, a credential signature for verifiable credentials including one or more data points, the verifiable credentials having been provided to the second agent by a fifth agent for the first transaction and including one or more data points. The credential signature is sent by the first agent to the second agent.

[0006] Another method for conducting transactions on a network is provided, where a first agent sends a request to a second agent to initiate utilization of a service. The first agent receives a request for one or more data points to initiate utilization of the service from the second agent. The first agent sends one or more requirements to the second agent to satisfy the one or more data points. The first agent receives a digitally signed transaction including a digital signature from the second agent. The first agent sends the digitally signed transaction to a third agent. The first agent receives an indication from the third agent that a first verifiable proof for the digitally signed transaction has been received, and the first agent sends a second verifiable proof to the second agent. The second verifiable proof is based on verifiable credentials including one or more data points.

[0007] A system for conducting transactions on a network is provided. This system includes a first agent and a second agent. The second agent is operable to transact with a third agent to utilize a service. The third agent is communicable with a fourth agent. The first agent is operable to communicate with the second agent to facilitate transacting with the third agent for the second agent to utilize the service. The first agent is further operable to communicate with the fourth agent to facilitate transacting with the third agent for the second agent to utilize the service.

[0008] A further system for conducting transactions over a network is provided. This further system includes a first agent and a second agent. The first agent is operable to receive a digitally signed transaction from the second agent, the digitally signed transaction having been received by the second agent from a third agent and including a digital signature. The first agent is also operable to receive a first verifiable proof from a fourth agent and to send the first verifiable proof to a fifth agent. The first agent is further operable to receive an unlock signature for locked credentials provided to the second agent by a sixth agent from the fifth agent and to send the unlock signature to the fourth agent. The second agent is operable to send a request to start utilization of a service to the third agent and to receive a request for one or more data points to start utilization of the service from the third agent. The second agent is also operable to send one or more requirements to satisfy one or more data points to the third agent and to receive a digitally signed transaction from the third agent. The second agent is further operable to send a second verifiable proof to the third agent, the second verifiable proof including one or more data points based on the locked credentials.

[0009] Another system for conducting transactions on a network is provided, which includes a first agent and a second agent. The first agent is operable to receive a first transaction and a second transaction from the second agent, the first transaction being initiated by a third agent and the second transaction including identification data of a fifth agent. The first agent is also operable to receive from the second agent an indication that verifiable credentials have been received by the second agent, the verifiable credentials including one or more data points provided to the second agent by the fifth agent for the first transaction. In response to receiving from the second agent an indication that the verifiable credentials have been received by the second agent, the first agent is further operable to send a first verifiable proof based on the second transaction to a fourth agent. The first agent is further operable to receive a credentials signature for the verifiable credentials from the fourth agent and send this credentials signature to the second agent. The second agent is operable to send a request for verifiable credentials to the fifth agent, the request for verifiable credentials including the second transaction. The second agent is further operable to provide entity identification information to the fifth agent and receive verifiable credentials from the fifth agent.

[0010] Yet another system is provided for conducting transactions over a network, the system including a first agent and a third agent. The first agent is operable to send a request to start utilization of a service to a second agent, receive a request for one or more data points to start utilization of the service from the second agent, and send to the second agent one or more requirements for fulfilling the one or more data points. The first agent is further operable to receive from the second agent a digitally signed transaction including a digital signature, and send the digitally signed transaction to the third agent. The first agent is further operable to receive from the third agent an indication that a first verifiable proof of the digitally signed transaction has been received, and send to the second agent a second verifiable proof, the second verifiable proof being based on verifiable credentials including one or more data points. The third agent is operable to receive the first verifiable proof from a fourth agent and send to the first agent an indication that a first verifiable proof of the digitally signed transaction has been received.

[0011] Yet another method for conducting transactions on a network is provided. This method includes sending a request to start using a service from a second agent to a third agent. The second agent receives a request for one or more data points to start using the service from the third agent and sends a request for locked credentials in response to the request for one or more data points from the third agent to a sixth agent. The second agent receives the locked credentials from the sixth agent and sends one or more requirements to satisfy one or more data points to the third agent. The second agent receives a digitally signed transaction including a digital signature from the third agent. The first agent receives the digitally signed transaction from the second agent. The second agent sends a second verifiable proof to the third agent, and the second verifiable proof includes one or more data points based on the locked credentials. The fourth agent receives the digitally signed transaction and the second verifiable proof from the third agent. The first agent receives a first verifiable proof from the fourth agent and sends the first verifiable proof to a fifth agent. The first agent receives an unlock signature for the locked credentials from the fifth agent and sends the unlock signature to the fourth agent. The fourth agent sends the unlock signature to the third agent.

[0012] Yet another method for conducting transactions over a network is provided, which includes sending a request to initiate utilization of a service from a second agent to a third agent. The second agent receives a request for one or more data points to initiate utilization of the service from the third agent. The second agent sends a request for verifiable credentials including one or more data points to a fifth agent, and the request for verifiable credentials includes a second transaction. A fourth agent receives the second transaction from the fifth agent. A first agent receives a first transaction from the second agent, and the first transaction is initiated by the third agent. The first agent receives a second transaction from the second agent, and the second transaction includes identification data of the fifth agent. The second agent provides entity identification information to the fifth agent. The second agent receives verifiable credentials including one or more data points from the fifth agent. The first agent receives an indication from the second agent that the verifiable credentials have been received by the second agent. In response to receiving from the second agent an indication that the verifiable credentials have been received by the second agent, the first agent sends a first verifiable proof based on the second transaction to the fourth agent. A credentials signature for the verifiable credentials is sent from the fourth agent to the first agent based on the second transaction and the first verifiable proof. The first agent sends the credentials signature to the second agent. The second agent sends a second verifiable proof including one or more data points based on the credentials signature and the verifiable credentials to the third agent. A sixth agent receives an indication from the third agent that the second verifiable proof has been received by the third agent.The first agent receives, from the sixth agent, an indication that the second verifiable proof has been received by the third agent, and the first agent transmits the indication that the second verifiable proof has been received by the third agent to the second agent.

Brief Description of the Drawings

[0013] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings. The figures and the detailed description are illustrative. The figures and the detailed description are not to be regarded as limiting, and other embodiments are possible. Like reference numerals in the figures indicate like elements.

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 7

Figure 8

[0015] The current self-sovereign identity (“SSI”) infrastructure model has limitations with respect to securely processing transactions. For security and monetization purposes, it is desirable to track, record, and audit SSI transactions. This specification describes systems and methods that introduce mechanisms for tracking and monetizing the use of SSI infrastructure and services built on SSI infrastructure. The systems and methods described herein do not require changes to the core requirements of SSI infrastructure, including verifiable credentials and the structure and use of verifiable credentials within SSI exchanges.

[0016] The terms described in this specification are as follows.

[0017] An “issuer” is an entity that issues a verifiable credential or data artifact.

[0018] A “holder” is an entity that holds a verifiable credential or data artifact provided by an issuer entity.

[0019] A "verifier" is an entity that verifies data artifacts provided by a holder as part of a transaction and is a service provider that desires the involvement of the holder.

[0020] A "contract" defines what data artifacts are required from an entity requesting a service by the entity providing the service before the service is provided.

[0021] A "transaction agent" is an application component that provides functions for tracking, communicating, aggregating, and interfacing transactions using credentials.

[0022] A "transaction agent service provider system" is a system (e.g., a software or hardware system) that hosts one or more transaction agents and one or more transaction ledgers on behalf of a holder, issuer, or verifier who selects the implementation of the system. The transaction agent service provider system can play different roles for each of the issuer, holder, and verifier. The transaction agent service provider system is also referred to as a "transaction agent provider", "payment infrastructure", or "platform provider".

[0023] A "payment agent" is a transaction agent that provides a payment function.

[0024] A "sponsor" is an entity that sponsors (e.g., pays for) the issuance of verifiable credentials, thereby granting credit to a user. The sponsor can have the right to receive a majority of the verifier's payment for the verification of the credential. The sponsor can be an independent entity or can be the issuer, the holder's transaction agent service provider system, or the verifier.

[0025] A "locked credential" is a verifiable credential (VC) that can be shared by the holder but cannot be verified by the verifier without being unlocked. Unlocking can be by encryption (e.g., the verifier needs to receive a cryptographic key to unlock the content of the credential or a part of the content), or it can be policy-based (e.g., the verifier's agent complies with a policy and unlocks the credential for verification only after procedural conditions such as payment being confirmed are met).

[0026] An "unlocked credential" is a verifiable credential that has been previously obtained from the issuer and can be shared by the holder, and can be used multiple times by the holder without paying a fee to the issuer or notifying the issuer of such use for a transaction where the credential is required.

[0027] A "co-protocol" is an interaction between two entities (e.g., the holder, verifier, or issuer) within a payment scheme for an action that requires payment.

[0028] A "use case" is a real-world example of how users, consumers, and computers interact with a service or service provider.

[0029] A "transaction scheme" or "payment scheme" is a set of interactions between entities in a transactional agent system to accomplish a use case.

[0030] "Transaction" or "txn" refers to an exchange between two parties, whether for a fee or for free, involving, for example, a service provided by one party to another requester, such as a purchase order.

[0031] A "cryptographic system flow" is a system flow that describes a transaction data exchange in which the protections provided by the system are cryptographically enforced, i.e., a verifiable credential cannot be used in a transaction without the cryptographic proof necessary to verify a signature on the credential.

[0032] "Policy system flow" means a system flow that describes transaction data exchange, and the protections provided by the system are enforced by policies that are defined and deployed throughout the system, i.e., a verifiable credential cannot be used in a transaction without verification that the credential complies with policies agreed upon among entities in the system.

[0033] As described herein, references to a "first," "second," or "third" component (e.g., a "first agent," a "second agent"), or a "particular" or "certain" component or implementation (e.g., a "particular user," a "certain user," a "particular computing device," a "particular implementation") are not used to imply a sequential or numerical limitation or limitation of quality, but rather are used to distinguish or identify various components and implementations.

[0034] Referring to FIG. 1, a process flow and system 200 effective in a network environment are shown. A third-party data artifact issuer 24, such as a community of data artifact issuers 24, provides data artifacts (e.g., verifiable credentials) to a holder agent 42. The holder agent 42 can be provided in the form of a software agent that includes a digital wallet that holds the issued data artifacts belonging to the users of the holder agent 42 (i.e., the "holders"), as well as software applications and a network stack necessary to support the use of the digital wallet.

[0035] The primary issuer 32 can also provide data artifacts to the holder agent 42. The composite issuer 34 collaborates with other issuers including the third-party data artifact issuer 24 and the ID&V entity 26 within the ID&V (identification and verification) community to create data artifacts for the holder agent 42. The gateway issuer 36 issues data artifacts to the holder agent 42 on behalf of the ID&V entity 26. The primary issuer 32, the composite issuer 34, and the gateway issuer 36 are enabled by, for example, the same entity that enables the software agents that form the holder agent 42. The verifier agent 52 interfaces with the holder agent 42 to verify the data artifacts.

[0036] Referring to FIG. 2, a self-sovereign identity (“SSI”) system 300 is provided. For privacy reasons, when implementing verifiable credentials, it is not desirable for the holder and the issuer (e.g., via the holder agent 42 and the issuer agent 22) to communicate directly. For illustrative purposes, if a driver's license issued by a state's department of motor vehicles (“DMV”) is a verifiable credential and is used by the holder to gain access to various nightclubs, the holder may not want the DMV to know that they went to a nightclub to verify the driver's license. The SSI system 300 supports the privacy of the holder via the transaction layer 304 by enabling the holder, via the holder agent 42, to use verifiable credentials (even if they are locked credentials) without the credential issuer knowing where the credentials were used. The SSI system 300 further supports cryptographically tracking the proof of transactions via the transaction layer 304, for example, for the purpose of auditing and tracking payments related to the transaction.

[0037] The base layer 302 defines the base components of the SSI system 300. The transaction layer 304 defines components that handle payment processing related to transactions and includes an issuer transaction agent 62, a holder transaction agent 72, and a verifier transaction agent 82. The infrastructure layer 306 defines the services necessary to support the base layer 302 and the transaction layer 304. The infrastructure layer includes an issuer transaction infrastructure 90, a holder transaction infrastructure 92, and a verifier transaction infrastructure 94.

[0038] The base layer includes the issuer agent 22, which includes one or more of the third-party data artifact issuer 24, the ID&V entity 26, the primary issuer 32, the composite issuer 34, or the gateway issuer 36. The starting point of a transaction occurs when a holder corresponding to the holder agent 42 having an existing issued verifiable credential attempts to use a verified service. The data flow between the holder agent 42, the verifier agent 52, and one or more transaction agents 62, 72, 82 is based on per-transaction payments.

[0039] An issue for the SSI system 300 occurs when providers of software and services enabling transactions or services via the SSI system 300 want to track, audit, and monetize the transactions or services, for example, to enhance the security and usability of the system and protect the privacy of the use by the holders of the credentials. Referring to FIGS. 2 and 3, as a solution to the issue, the transaction agent architecture introduces three functional roles into the process flow defined in the SSI system 300 and the system 200, enabling the process flow and the system 400. These three functional roles include the roles of the transaction agents realized by the issuer transaction agent 62, the holder transaction agent 72, and the verifier transaction agent 82.

[0040] The issuer transaction agent 62 provides the issuer agent 22 with tracking of transactions in which the issuer transaction agent 62 is involved, including monetization, based on transactions of the holder and verifier (respectively via the holder agent 42 and the verifier agent 52), without the issuer's (via the issuer agent 22) involvement in the transaction by returning the transaction to the issuer agent 22. The issuer agent 22 can include one or more of a third-party data artifact issuer 24, an ID&V entity 26, a primary issuer 32, a composite issuer 34, or a gateway issuer. The holder transaction agent 72 provides tracking of transactions in which the holder transaction agent 72 is involved, which includes monetization returned to a service provider, such as a security service provider, that enables the holder agent 42 (e.g., a software agent) to provide the holder agent 42 (e.g., a software agent service). The verifier transaction agent 82 provides the verifier agent 52 with monetization of transactions, including transaction billing and tracking services for transactions in which the verifier transaction agent 82 is involved. The issuer transaction agent 62, the holder transaction agent 72, and the verifier transaction agent 82 maintain separate communication and tracking lines to enable system security and usability and to protect the privacy of the holder's credential usage.

[0041] Process flow and system 400 includes a flow for each transaction represented by steps 402 through 414. At step 402, the Holder Agent 42 sends a transaction, which includes, for example, the verifiable credentials of the holder of the Holder Agent 42, to the Verifier Agent 52. The Verifier Agent 52 signs the transaction and returns it to the Holder Agent (step 404). The Holder Agent 42 sends the signed transaction to the Holder Transaction Agent 72 (step 406). The Holder Transaction Agent 72 verifies the signature, for example, by applying the public key of the Verifier Agent (step 408). The Holder Transaction Agent 72 creates a transaction ledger entry (step 410). The Holder Transaction Agent 72 sends back to the Holder Agent 42 a proof of the transaction (a "transaction proof") (step 412). The Holder Agent 42 sends the transaction proof to the Verifier Agent 52 (step 414).

[0042] Process flow and system 400 further includes an asynchronous batch process flow and system represented by steps 450 through 454. At step 450, the Holder Transaction Agent 72 sends an invoice to the Verifier Transaction Agent 82. The Verifier Transaction Agent 82 sends a payment to the Holder Transaction Agent 72 (step 452), and the Holder Transaction Agent 72 pays the Issuer Transaction Agent 62 (step 454).

[0043] Referring to FIG. 4, an exemplary transaction scheme system 500 (e.g., a payment scheme system) according to the SSI system 300 is provided. The transaction scheme system 500 enables the cryptographic tracking of transaction proofs, for example, for the purpose of auditing and tracking payments related to transactions. The transaction scheme system 500 enables a series of data flows between the issuer agent 22, the holder agent 42, the verifier agent 52, the issuer transaction agent 62, the holder transaction agent 72, and the verifier transaction agent 82. The transaction scheme system 500 is operable on one or more wired or wireless networks, including wireless data networks such as local area networks (LANs), wide area networks (WANs), the Internet, mobile phone networks, Wi-Fi TM or 3G / 4G / 5G cellular networks, or a computer network including a combination thereof.

[0044] The issuer transaction agent service provider system 60 includes the issuer transaction agent 62, and an issue ledger 66 that records the record management communication from the issuer transaction agent 62 and enables the issuer transaction agent 62 to access the record management communication. The issuer transaction agent service provider system 60 further includes an issuer agency transaction agent 64 for sending and receiving agency-related communications.

[0045] The Holder Transaction Agent Service Provider System 70 includes a Holder Transaction Agent 72 and a Transaction Ledger 76 that records record management communications from the Holder Transaction Agent 72 and enables the Holder Transaction Agent 72 to access the record management communications. The Holder Transaction Agent Service Provider System 70 further includes a Holder Agency Transaction Agent 74 for transmitting and receiving agency-related communications between the Issuer Agency Transaction Agent 64 and the Verifier Agency Transaction Agent 84.

[0046] The Verifier Transaction Agent Service Provider System 80 includes a Verifier Transaction Agent 82 and a Verified Ledger 86 that records record management communications from the Verifier Transaction Agent 82 and enables the Verifier Transaction Agent 82 to access the record management communications. The Verifier Transaction Agent Service Provider System 80 further includes a Verifier Agency Transaction Agent 84 for transmitting and receiving agency-related communications with the Holder Agency Transaction Agent 74.

[0047] The network-connectable processor-compatible Issuer System 20 enables an Issuer Agent 22. The network-connectable processor-compatible Holder Device 40 enables a Holder Agent 42. The Holder Agent 42 can be provided to the Holder Device 40, for example, as a stand-alone application or as a plug-in, add-on, or extension to an existing application, such as a web browser. The network-connectable processor-compatible Verifier System 50 enables a Verifier Agent 52. The Verifier Agent 52 can be provided to the Verifier System 50, for example, as a stand-alone application or as a plug-in, add-on, or extension to an existing application, such as a web browser plug-in.

[0048] The data flows enabled by the transaction scheme system 500 include those shown in Table 1 below.

[0049]

Table 1

[0050] Here, a series of co - protocols are defined that are used as part of the payment scheme within a transaction agent system that includes the SSI system 300. The co - protocols described track and monetize the use of verifiable credentials while the SSI system 300 is used in multiple scenarios. The co - protocols described support real - time tracking of transactions in which verifiable credentials are used, regardless of the costs or payments required to support those transactions. The co - protocols can be classified into either a credential payment category or a service payment category.

[0051] The credential payment category is one in which payment occurs during or after the use of transaction credentials. The service payment category is one in which payment occurs during or after the use of services performed by the service provider by the holder. Except for the specific service - providing use cases described below, it is assumed that verifiers do not receive payment for participating in the use of the SSI infrastructure. In the case of use cases in the credential payment category, the advantages for verifiers include higher - quality data, reduced data acquisition costs, and reduced transaction friction.

[0052] In an exemplary first coprotocol corresponding to the credential payment category, the holder agent 42 requests verifiable credentials from the issuer agent 22, and the issuer agent 22 requests payment prior to issuance. In the first coprotocol, the holder of the holder agent 42 is the payer and the issuer agent 22 is the recipient. For example, a holder (e.g., a consumer) implementing the holder agent 42 wishes to use an Internet service that requires specific verifiable credentials from an issuer implementing the issuer agent 22, and the holder must pay to obtain the verifiable credentials before starting a transaction with the service, and the service implements the verifier agent 52.

[0053] In an exemplary second coprotocol corresponding to the credential payment category, the holder agent 42 requests a service as part of a transaction that requires verifiable credentials, and the issuer agent 22 requests payment before providing an unlock signature that enables the verifier agent 52 implemented by the service to utilize the verifiable credentials. In the second coprotocol, the verifier of the verifier agent 52 is the payer and the issuer agent 22 is the recipient. For example, a subscription media streaming service (Netflix TM etc.) implementing the verifier agent 52 makes a payment to the issuer agent 22 that provides the credential information of a consumer (the holder of the holder agent 42) used as part of the subscription sign-up process.

[0054] In an exemplary third coprotocol corresponding to the credential payment category, in a transaction with a verifier of the verifier agent 52 that requires a verifiable credential, a service is used by the holder of the holder agent 42, and the system provider of the holder agent 42 requests payment for using the SSI system 300 as part of the transaction. In the third coprotocol, the verifier of the verifier agent 52 is the payer, and the system provider of the holder agent 42 is the recipient. For example, a credit card company system provides a service to the holder (e.g., a consumer) of the holder agent 42, and the credit card company system receives payment from the verifier (e.g., a vendor of a product or service) of the verifier agent 52.

[0055] In an exemplary fourth coprotocol corresponding to the credential payment category, in a transaction with a verifier of the verifier agent 52 that requires a verifiable credential already owned by the holder agent 42, a service is used by the holder of the holder agent 42, and the holder receives payment from the verifier by providing the verifiable credential. In the fourth coprotocol, the verifier of the verifier agent 52 is the payer, and the holder of the holder agent 42 is the recipient. For example, the holder is a royalty program purchaser, and the verifier (e.g., a royalty program administrator) pays the holder for providing a verifiable credential as part of a verified purchase transaction based on the royalty program.

[0056] In an exemplary fifth coprotocol corresponding to the service payment category, the service provided by the verifier of the verifier agent 52 is used by the holder of the holder agent 42, and the holder desires to pay for the service using the same transaction tracking mechanism used for credential tracking instead of using that mechanism for service tracking. In the fifth coprotocol, the holder (e.g., the buyer) of the holder agent 42 is the payer, and the verifier (e.g., the seller) of the verifier agent 52 is the recipient. For example, the holder (e.g., the consumer) of the holder agent 42 subscribes to a subscription media streaming service (e.g., Netflix TM ) and desires to pay for the subscribed media streaming service using a transaction agent system including the SSI system 300.

[0057] In an exemplary sixth coprotocol corresponding to the service payment category, the service provided by the verifier of the verifier agent 52 is used by the holder of the holder agent 42. This service enables various payment mechanisms supported by the verifier, but the holder desires to be able to select which payment method is preferred during a particular transaction between the holder and the verifier. In the fifth coprotocol, the holder (e.g., the buyer) of the holder agent 42 is the payer, and the verifier (e.g., the seller) of the verifier agent 52 is the recipient. For example, the holder (e.g., the consumer) of the holder agent 42 subscribes to a subscription media streaming service (e.g., Netflix TM ) and desires to pay for the subscribed media streaming service using a third-party payment service (e.g., PayPal TM ) instead of a credit card while using the same transaction agent system (e.g., the SSI system 300) used to establish the subscription.

[0058] In an exemplary seventh coprotocol corresponding to the credential payment category, the holder agent 42 requests verifiable credentials from the issuer agent 22, and the issuer agent 22 requests payment prior to issuance. In the second coprotocol, the sponsor of the holder of the holder agent 42 is the payer, and the issuer agent 22 is the recipient.

[0059] A transaction agent system including the SSI system 300 supports various payment schemes. The payment schemes described rely on the same architectural components included in the SSI system 300 and emphasize how the architectural components interact with each other as part of a transaction to support various coprotocols that can be combined to support a payment scheme.

[0060] Three exemplary payment schemes are summarized in Table 2.

Table 2

[0061] Two scenarios are described for the exemplary payment schemes in Table 2. The first scenario describes how the payment scheme supports the establishment of new verifiable credentials, and the second scenario describes how subsequent transactions utilize existing verifiable credentials (lock or unlock). In the third payment scheme, payment for new verifiable credentials is made using the second payment scheme before proceeding to the third payment scheme. Advantageous preconditions for the first, second, and third payment schemes include the existence of the issuer agent 22, the holder agent 42, and the verifier agent 52, support for the SSI infrastructure of the SSI system 300, and the existence of a transaction infrastructure including the transaction agents 62, 72, 82.

[0062] The following are four exemplary use cases defined to highlight the relative advantages and disadvantages of each payment scheme in Table 2. The first use case involves providing proof of identity to sign up for an online service. The second use case involves providing proof of education for an employment application. The third use case involves providing proof of age to access a social club. The fourth use case involves providing proof of an authorized purchaser of a particular product when a user (i.e., purchaser) writes a review of the product / service.

[0063] In the first payment scheme of Table 2, the verifier pays the issuer for each verification of the locked credentials. The first payment scheme implements a transaction agent in the credential verification process. The payment condition of the first payment scheme includes the requirement to pay for each verification of the transaction. Referring to FIGS. 5A and 5B, two exemplary scenarios to which the first payment scheme is applied are represented by process flow and system 600 and process flow and system 700, respectively. In the process flow and system 600 of FIG. 5A, a new verifiable credential is requested from the issuer agent 22. The precondition of the process flow and system 600 includes the requirement that the holder agent 42 does not possess a previous verifiable credential. In the process flow and system 700 of FIG. 5B, the holder agent 42 already possesses a verifiable credential previously received from the issuer agent 22.

[0064] Process flows and systems 600, 700 enable a method for conducting transactions over a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to process flows and systems 600 and process flows and systems 700, the first agent is depicted as the Holder Transaction Agent 72, the second agent is depicted as the Holder Agent 42, the third agent is depicted as the Verifier Agent 52, the fourth agent is depicted as the Verifier Transaction Agent 82, the fifth agent is depicted as the Issuer Transaction Agent 62, and the sixth agent is depicted as the Issuer Agent 22. The depiction of the plurality of agents with respect to process flows and systems 600, 700 is exemplary in nature, and process flows and systems 600, 700 are not limited by the specific naming of each agent.

[0065] Referring to FIG. 5A, a process flow and system 600 effective in a network environment are shown. A holder, via a holder agent 42 (i.e., the second agent), desires to initiate a transaction for service utilization from a provider, and a provider functioning as a verifier via a verifier agent 52 (i.e., the third agent) desires to verify the holder. The holder agent 42 requests services from the verifier agent 52 (step 602). The verifier agent 52 specifies to the holder agent 42 which of one or more data points, such as attributes regarding the transaction (e.g., attributes of verifiable credentials), are required in a request for data regarding the transaction (e.g., a presentation request) (step 604), and the one or more data points define conditions of a transaction (e.g., a contract) similar to contract terms. The data points can include, for example, one or more of the holder's surname, given name, date of birth, credit card number, social security number, or passport number. In response to the data request from the verifier agent 52, the holder agent 42 requests verifiable credentials from an issuer agent 22 (i.e., the sixth agent) (step 606). In its request, the holder agent 42 does not need to disclose the identity of the verifier agent 52 to the issuer agent 22, but the holder agent 42 can present the data points required by the verifier agent 52.

[0066] The Holder Agent 42 and the Issuer Agent 22 interact (step 608) to satisfy the conditions that the Issuer Agent 22 needs to meet in order to be compliant to issue the requested verifiable credentials, based on the use case, the type of credentials, and the level of assurance. For example, in the case of "KYC" (know-your-client) type verifiable credentials, the holder of the Holder Agent 42 may be required to present a driver's license or other ID with their face to the camera. The Issuer Agent 22 sends to the Holder Agent 42 the locked credentials of the holder (i.e., the locked verifiable credentials) and a cryptographic commitment, which is information that enables the Transaction Agent to pay a fee for verification. The cryptographic commitment is related to the locked credentials and includes information for the Verifier Agent 52 to use to contact the Issuer Agent 22. The cryptographic commitment guarantees that the locked credentials are usable by the Holder Agent 42 and enables the Verifier Agent 52 to verify the locked credentials after payment or other requirements via the Verifier Transaction Agent 82 are completed. The cryptographic commitment can be provided as a partial signature of the locked credentials. The cryptographic commitment can include cost information and payment information regarding the cost of the locked credentials.

[0067] The holder agent 42 sends a response (e.g., a response to a presentation request) including one or more requirements of the data requested by the verifier agent 52 to the verifier agent 52 to meet one or more data points for a transaction (e.g., a contract) to be initiated (step 612). The one or more requirements provided by the holder agent 42 include, for example, one or more of a price, a service level agreement (“SLA”), or a policy for the requested data. If the one or more requirements are accepted by the verifier agent 52, the verifier agent 52 responds by updating the transaction to generate a signed transaction that confirms that the one or more requirements are accepted, and the verifier agent sends a response including the signed transaction to the holder agent 42 (step 614). The signed transaction includes data of the issuer agent 22 (e.g., the digital identity of the issuer agent 22).

[0068] The signed (i.e., "updated") transaction containing the data of the issuer agent 22 (e.g., the digital identity of the issuer agent 22) obtained by the holder agent 42 from the verifier agent 52 in step 614, and the cryptographic commitment obtained by the holder agent 42 from the issuer agent 22 in step 610 are sent (step 616) by the holder agent 42 to the holder transaction agent 72 (i.e., the first agent). The holder transaction agent 72 beneficially verifies the signature of the signed transaction (step 617), for example, by applying the public key associated with the verifier agent 52. The signed (i.e., "updated") transaction received by the holder transaction agent 72 from the holder agent 42 in step 616 is written (step 618) by the holder transaction agent 72 to the transaction ledger 76. The confirmation of the storage of the signed transaction in the transaction ledger 76 is sent (step 620) by the holder transaction agent 72 to the holder agent 42. The holder agent 42 sends (step 622) to the verifier agent 52 a locked verifiable proof based on the locked credentials (e.g., including the locked credentials) containing one or more data points ("data point proofs") requested by the verifier agent 52. The data point proof includes the presentation of the one or more requested data points and one or more locked proofs associated with the one or more requested data points.

[0069] The holder agent 42 confirms to the holder transaction agent 72 the fact that the verifier agent 52 has sent the data point proof (step 624), whereby the payment part of the transaction becomes available by the action of the holder transaction agent 72. The verifier agent 52 sends the signed transaction and the data point proof received from the holder agent 42 to the verifier transaction agent 82 (i.e., the fourth agent) (step 626).

[0070] The verifier transaction agent 82 saves the signed transaction and the data point proof in the verified ledger 86 (step 628) and triggers the start of payment. The verifier transaction agent 82 sends the payment and the payment certificate to the issuer agent 22 to the holder transaction agent 72 (step 630). The payment and the payment certificate of the issuer agent 22 that the holder transaction agent anonymizes and does not disclose the identity of the payer (the "payment proof") are relayed by the holder transaction agent 72 to the issuer transaction agent 62 (i.e., the fifth agent) (step 632). The issuer transaction agent 62 saves the payment proof in the issuance ledger 66 (step 634) and enables the unlocking signature of the locked credentials associated with the data point proof to be sent back to the verifier agent 52 via the holder transaction agent 72 and the verifier transaction agent 82.

[0071] The issuer transaction agent 62 sends to the holder transaction agent 72 a unlock signature of the locked credential associated with the data point proof associated with the signed transaction, for relaying to the verifier agent 52 (step 636). The holder transaction agent 72 relays the unlock signature received from the issuer agent 22 for the locked credential to the verifier transaction agent 82 (step 638). The verifier transaction agent 82 sends the unlock signature received from the issuer agent 22 for the locked credential to the verifier agent 52 and unlocks the data point proof associated with the signed transaction (step 640). Subsequently, the verifier agent 52 uses the unlock signature of the locked credential to unlock the data point proof received from the holder agent 42 for the signed transaction (step 642)

[0072] The verifier agent 52 sends a notification to the effect that the transaction has been successfully completed to the verifier transaction agent 82 (step 644), enabling the verifier transaction agent 82 to relay the completion status and also enabling the verifier transaction agent 82 to update the verified ledger 86 with the completion status. The verifier transaction agent 82 updates the verified ledger 86 with the completion status (step 646). The verifier transaction agent 82 notifies the holder transaction agent 72 that the transaction has been completed (step 648). Thereafter, the holder transaction agent 72 updates the transaction ledger 76 with the completion status (step 650).

[0073] The Holder Transaction Agent 72 notifies the Holder Agent 42 that the transaction has been completed (step 652), and the Holder Agent 42 may choose to display the update to the user or system. The Holder Transaction Agent 72 notifies the Issuer Transaction Agent 62 that the transaction has been completed (step 654), and the Issuer Transaction Agent 62 updates the Issuance Ledger 66 with the completion status (step 656).

[0074] Steps 618, 620, 624, and 628 provide an additional level of integrity to ensure that the SSI System 300 can detect problems and / or indicate progress throughout the process flow and sequence of the System 600. System implementation may choose to skip one or more of steps 618, 620, 624, and 628 for optimization purposes without losing the exchange of the overall results of the transaction.

[0075] Referring to FIG. 5B, a process flow and system 700 effective in a network environment is shown. A holder, via the Holder Agent 42 (i.e., the second agent), wishes to initiate a transaction for the use of services from a provider, and a provider, functioning as a verifier via the Verifier Agent 52 (i.e., the third agent), wishes to verify the holder. The Holder Agent 42 requests services from the Verifier Agent 52 (step 702). The Verifier Agent 52 specifies to the Holder Agent 42 which of one or more data points, such as attributes regarding the transaction (e.g., attributes of verifiable credentials), are required in the request for transaction data (e.g., a presentation request), and the one or more data points define the conditions of a transaction (e.g., a contract) similar to the contract terms. The data points can include, for example, one or more of the holder's surname, given name, date of birth, credit card number, social security number, or passport number.

[0076] The Holder Agent 42 sends a response (e.g., a response to a presentation request) including one or more requirements regarding the data requested by the Verifier Agent 52 to the Verifier Agent 52 to satisfy one or more data points of a transaction (e.g., a contract) to be initiated (step 706). The one or more requirements provided by the Holder Agent 42 include, for example, one or more of a price for the requested data, a service level agreement ("SLA"), or a policy. If the one or more requirements are accepted by the Verifier Agent 52, the Verifier Agent 52 responds by updating the transaction to generate a signed transaction that confirms that the one or more requirements are accepted, and the Verifier Agent 52 sends a response including the signed transaction to the Holder Agent 42 (step 708). The signed transaction includes data of the Issuer Agent 22 (e.g., the digital identity of the Issuer Agent 22).

[0077] Data of the issuer agent 22 (e.g., the digital identity of the issuer agent 22), and cryptographic commitments obtained from the issuer agent 22 at a previous time point, the signed (i.e., "updated") transaction obtained by the holder agent 42 from the verifier agent 52 at step 708 is sent by the holder agent 42 to the holder transaction agent 72 (step 710). The holder transaction agent 72 beneficially verifies the signature of the signed transaction, for example, by applying the public key associated with the verifier agent 52 (step 711). The signed (i.e., "updated") transaction received by the holder transaction agent 72 from the holder agent 42 at step 710 is written by the holder transaction agent 72 to the transaction ledger 76 (step 712). Confirmation of the storage of the signed transaction to the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 714). The holder agent 42 sends a locked verifiable proof based on locked credentials (e.g., including locked credentials) to the verifier agent 52, including one or more data points ( "data point proofs") requested by the verifier agent 52 (step 716). The data point proof includes a presentation of one or more requested data points and a locked proof associated with the requested data points.

[0078] The holder agent 42 confirms to the holder transaction agent 72 the fact that the verifier agent 52 has sent the data point proof (step 718), and thus, by the action of the holder transaction agent 72, the payment part of the transaction becomes available. The verifier agent 52 sends the signed transaction and the data point proof received from the holder agent 42 to the verifier transaction agent 82 (i.e., the fourth agent) (step 720).

[0079] The verifier transaction agent 82 saves the signed transaction and the data point proof in the verified ledger 86 (step 722) and triggers the start of payment. The verifier transaction agent 82 sends the payment and the payment certificate to the holder transaction agent 72 for the issuer agent 22 (step 724). The holder transaction agent relays the payment and the payment certificate (the "payment proof") that anonymizes the payment and does not disclose the identity of the payer to the issuer agent 22 to the issuer transaction agent 62 through the holder transaction agent 72 (step 726). The issuer transaction agent 62 saves the payment proof in the issuance ledger 66 (step 728) and can send back to the verifier agent 52 the unlock signature of the locked credentials associated with the data point proof via the holder transaction agent 72 and the verifier transaction agent 82.

[0080] The issuer transaction agent 62 sends to the holder transaction agent 72 an unlock signature for the locked credentials associated with the data point proof associated with the signed transaction, for relaying to the verifier agent 52 (step 730). The holder transaction agent 72 relays the unlock signature received from the issuer agent 22 for the locked credentials to the verifier transaction agent 82 (step 732). The verifier transaction agent 82 sends the unlock signature received from the issuer agent 22 for the locked credentials to the verifier agent 52 and unlocks the data point proof associated with the signed transaction (step 734). Subsequently, the verifier agent 52 uses the unlock signature for the locked credentials to unlock the data point proof received from the holder agent 42 for the signed transaction (step 736).

[0081] The verifier agent 52 sends a notification to the verifier transaction agent 82 that the transaction has been successfully completed (step 738), enabling the verifier transaction agent 82 to relay the completion status and enabling the verifier transaction agent 82 to update the verified ledger 86 with the completion status. The verifier transaction agent 82 updates the verified ledger 86 with the completion status (step 740). The verifier transaction agent 82 notifies the holder transaction agent 72 that the transaction has been completed (step 742). Thereafter, the holder transaction agent 72 updates the transaction ledger 76 with the completion status (step 744).

[0082] The Holder Transaction Agent 72 notifies the Holder Agent 42 that the transaction has been completed (step 746), and the Holder Agent 42 may choose to display the update to the user or the system. The Holder Transaction Agent 72 notifies the Issuer Transaction Agent 62 that the transaction has been completed (step 748), and the Issuer Transaction Agent 62 updates the Issuance Ledger 66 with the completion status (step 750).

[0083] Steps 712, 714, 718, and 722 provide an additional level of integrity to ensure that the SSI System 300 can detect problems and / or indicate progress throughout the process flow and the flow sequence of the System 700. System implementation may choose to skip one or more of steps 712, 714, 718, and 722 for optimization purposes without losing the exchange of the overall results of the transaction.

[0084] The scenarios represented by the process flow and Systems 600, 700 enable the second and third coproto cols described above. In the second coproto col, the Holder Agent 42 requests a service as part of a transaction that requires verifiable credentials, and the Issuer Agent 22 requests payment before the Issuer Agent 22 provides an unlock signature that enables the Verifier Agent 52 to use the verifiable credentials. In the second coproto col, the verifier of the Verifier Agent 52 is the payer and the Issuer Agent 22 is the recipient. In the third coproto col, in a transaction with the verifier of the Verifier Agent 52 that requires verifiable credentials, the service is used by the holder of the Holder Agent 42, and the system provider of the Holder Agent 42 requests payment for using the SSI System 300 as part of the transaction. In the third coproto col, the verifier of the Verifier Agent 52 is the payer and the system provider of the Holder Agent 42 is the recipient.

[0085] The scenarios represented by process flows and systems 600, 700 are particularly suitable for applications that support the first use case described herein, which includes providing identity proof for online service sign-up. The scenarios represented by process flows and systems 600, 700 are even more suitable for applications that support the fourth use case described herein, which includes providing proof of an identified purchaser of a particular product when a user (i.e., purchaser) writes a review of the product / service. With respect to the fourth use case, the issuer agent 22 can motivate a particular incident response platform ("IRPs") to be unable to verify the verifiable credentials (e.g., if the IRPs publish a bad review). Alternatively, other use cases can be supported by the scenarios represented by process flows and systems 600, 700.

[0086] In the second payment scheme of Table 2, for each issuance of a verifiable credential, the holder pays the issuer. The second payment scheme implements a transaction agent for the execution of the credential process. The payment conditions of the second payment scheme include the requirement to pay for each issuance of a verifiable credential used within a transaction. Referring to FIGS. 6A and 6B, two exemplary scenarios to which the second payment scheme is applied are represented by process flow and system 800 and process flow and system 900, respectively. In the process flow and system 800 of FIG. 6A, a new verifiable credential is requested from the issuer agent 22. The preconditions of the first process flow and system 800 include the requirement that the holder does not have a previous verifiable credential. In the process flow and system 900 of FIG. 6B, the holder agent 42 already has a verifiable credential previously received from the issuer agent 22.

[0087] Process flows and systems 800, 900 enable a method for conducting transactions over a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to process flow and system 800, and process flow and system 900, the first agent is depicted as the Holder Transaction Agent 72, the second agent is depicted as the Holder Agent 42, the third agent is depicted as the Verifier Agent 52, the fourth agent is depicted as the Issuer Transaction Agent 62, the fifth agent is depicted as the Issuer Agent 22, and the sixth agent is depicted as the Verifier Transaction Agent 82. The depiction of the plurality of agents with respect to process flows and systems 800, 900 is exemplary in nature, and process flows and systems 800, 900 are not limited by the particular naming of each agent.

[0088] Referring to FIG. 6A, a process flow and system 800 effective in a network environment is shown. A holder, via the Holder Agent 42 (i.e., the second agent), desires to initiate a transaction to utilize services from a provider, and a provider functioning as a verifier via the Verifier Agent 52 (i.e., the third agent) desires to verify the holder. The Holder Agent 42 requests services from the Verifier Agent 52 (step 802). The Verifier Agent 52 initiates a new transaction (hereinafter, a "free transaction") that is not subject to costs imposed by the issuer or costs imposed by the holder, by sending a start notification to the Verifier Transaction Agent 82 (i.e., the sixth agent) (step 804). The Verifier Transaction Agent 82 saves the notification of the free transaction in the verified ledger 86 in the form of an update to the transaction (step 806).

[0089] The verifier transaction agent 82 notifies the verifier agent 52 that the free transaction has been successfully stored in the verified ledger 86 so that the verifier agent 52 can start processing the presentation request (step 808). The verifier agent 52 specifies, to the holder agent 42, one or more data points (e.g., attributes of the verifiable credential) required in the presentation request of the free transaction (step 810). The presentation request defines the conditions of the free transaction, and the free transaction is similar to, for example, a contract. The holder agent 42 requests the verifiable credential from the issuer agent 22 (i.e., the fifth agent), and the holder agent 42 initiates a signed credential request transaction that includes payment for the issuance of the verifiable credential (step 812). The issuer agent 22 sends the signed credential request transaction from the holder agent 42 to the issuer transaction agent 62 (i.e., the fourth agent) (step 814). The issuer transaction agent 62 verifies the digital signature of the digitally signed transaction, for example, by applying the public key of the holder agent 42 (step 815).

[0090] The issuer transaction agent 62 stores the signed credential request transaction in the issuance ledger 66 (step 816). The issuer transaction agent 62 sends a confirmation of the storage of the signed credential request transaction (step 818) to enable the issuer agent 22 to continue the exchange with the holder agent 42 and to issue the verifiable credential to the holder agent 42.

[0091] The signed credential request transaction between the holder agent 42 and the issuer agent 22, including the fleet transaction obtained by the holder agent 42 from the verifier agent 52 at step 810 and the data of the issuer agent 22 (e.g., the digital identity of the issuer agent 22), is sent by the holder agent 4 to the holder transaction agent 72 (i.e., the first agent) in the form of an update of the transaction (step 820). The fleet transaction and the credential request transaction received at step 820 by the holder transaction agent 72 are written by the holder transaction agent 72 to the transaction ledger 76 in the form of an update of the transaction (step 822). The confirmation of the storage of the fleet transaction and the credential request transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 824).

[0092] The Holder Agent 42 and the Issuer Agent 22 interact (step 826) to satisfy the conditions that the requested verifiable credential needs to meet in order for the Issuer Agent 22 to be able to issue it, based on the use case, the type of credential, and the level of assurance. For example, in the case of a verifiable credential of the Know Your Customer (「KYC」) type, the holder of the Holder Agent 42 may be required to present a driver's license or other ID with a camera along with their face. The Issuer Agent 22 sends to the Holder Agent 42 a cryptographic commitment, which is the verifiable credential of the holder and information enabling the Transaction Agent to pay a fee for verification, and which is related to the verifiable credential and contains information for the Verifier Agent 52 to use to contact the Issuer Agent 22. The cryptographic commitment can be provided as a partial signature of the verifiable credential that guarantees that the verifiable credential is usable by the Holder Agent 42 and enables the Verifier Agent 52 to verify the verifiable credential after the payment or other requirements by the holder via the Holder Transaction Agent 72 are completed. The cryptographic commitment can include cost and payment information regarding the cost of the verifiable credential.

[0093] Holder agent 42 notifies holder transaction agent 72 of the fact that issuer agent 22 has sent the verifiable credentials to holder agent 42 and holder agent 42 has received the verifiable credentials (step 830). As a result, the payment portion of the credential request transaction becomes available by the operation of holder transaction agent 72. Holder transaction agent 72 sends a payment and a payment certificate for issuer agent 22 to issuer transaction agent 62 (step 832). Issuer transaction agent 62 sends a credential signature (sent from issuer agent 22) for the verifiable credentials associated with the credential request transaction to holder transaction agent 72 for holder transaction agent 72 to relay to holder agent 42 (step 834). Holder transaction agent 72 sends the credential signature from issuer transaction agent 62 to holder agent 42 to enable the use of the verifiable credentials associated with the credential request transaction (step 836).

[0094] The Holder Agent 42 sends a verifiable presentation of the fleet transaction to the Verifier Agent 52 (step 838), and the verifiable presentation includes verifiable credentials that include one or more data points requested by the Verifier Agent 52 and one or more proofs corresponding to the one or more requested data points. In response to receiving the verifiable presentation that includes verifiable credentials, the Verifier Agent 52 sends a verifiable presentation completion status to the Verifier Transaction Agent 82, notifying the Verifier Transaction Agent 82 that the verifiable presentation has been received from the Holder Agent 42 and that the fleet transaction with the Holder Agent 42 has been completed (step 840). The Verifier Transaction Agent 82 saves the verifiable presentation completion status that includes the fleet transaction completion information in the verified ledger 86 in the form of an update of the transaction (step 842). The Verifier Transaction Agent 82 sends a notice to the Holder Transaction Agent 72 that the verifiable presentation has been delivered to the Verifier Agent 52 and that the fleet transaction has been completed (step 844).

[0095] The Holder Transaction Agent 72 notifies the Holder Agent 42 that the verifiable presentation has been delivered and that the fleet transaction has been completed (step 846). The Holder Transaction Agent 72 updates the transaction ledger 76 with the completion status of the fleet transaction indicating that the fleet transaction has been completed (step 848).

[0096] The scenario represented by process flow and system 800 enables the first co - protocol and the fourth co - protocol as described above. In the first co - protocol, the holder agent 42 requests verifiable credentials from the issuer agent 22, and the issuer agent 22 requests pre - payment. The process flow and system 800 enable the holder to pay the issuer. Further steps can be configured such that the verifier pays the holder in advance or returns the money that the holder has paid or is to be paid to the issuer. In the fourth co - protocol, in a transaction between the holder agent 42 and a verifier of the verifier agent 52 that requires verifiable credentials already owned by the holder agent 42, the service is used by the holder of the holder agent 42, and the holder receives payment from the verifier by providing the verifiable credentials as part of the transaction.

[0097] Referring to FIG. 6B, a process flow and system 900 effective in a network environment are shown. The holder, via the holder agent 42 (i.e., the second agent), wishes to initiate a transaction for service utilization from the provider, and the provider, functioning as a verifier via the verifier agent 52 (i.e., the third agent), wishes to verify the holder. The holder agent 42 requests services from the verifier agent 52 (step 902). The verifier agent 52 initiates a new transaction (hereinafter, a "free transaction") that is not subject to costs imposed by the issuer or costs imposed by the holder, by sending a start notification to the verifier transaction agent 82 (i.e., the sixth agent) (step 904). The verifier transaction agent 82 saves the notification of the free transaction in the verified ledger 86 in the form of an update of the transaction (step 906).

[0098] The verifier transaction agent 82 notifies the verifier agent 52 that the free transaction has been successfully stored in the verified ledger 86 so that the verifier agent 52 can start processing the presentation request (step 908). The verifier agent 52 specifies one or more required data points (e.g., attributes of verifiable credentials) in the presentation request of the free transaction to the holder agent 42 (step 910). The presentation request defines the conditions of the free transaction, and the free transaction is similar to, for example, a contract.

[0099] In step 910, the free transaction obtained by the holder agent 42 from the verifier agent 52 is sent by the holder agent 42 to the holder transaction agent 72 (i.e., the first agent) in the form of an update of the transaction (step 912). In step 912, the free transaction received by the holder transaction agent 72 is written by the holder transaction agent 72 to the transaction ledger 76 in the form of an update of the transaction (step 914). The confirmation of the storage of the free transaction in the transaction ledger 76 is sent by the holder transaction agent 72 to the holder agent 42 (step 916).

[0100] The holder agent 42 sends a verifiable presentation of the fleet transaction to the verifier agent 52 (step 918). The verifiable presentation includes verifiable credentials that include one or more data points requested by the verifier agent 52 and one or more proofs corresponding to the one or more requested data points. In response to receiving the verifiable presentation that includes verifiable credentials, the verifier agent 52 sends the completion status of the verifiable presentation to the verifier transaction agent 82, notifying the verifier transaction agent 82 that the verifiable presentation has been received from the holder agent 42 and that the fleet transaction with the holder agent 42 has been completed (step 920). The verifier transaction agent 82 stores the verifiable presentation completion status that includes the fleet transaction completion information in the verified ledger 86 in the form of an update to the transaction (step 922). The verifier transaction agent 82 sends a notification to the holder transaction agent 72 that the verifiable presentation has been delivered to the verifier agent 52 and that the fleet transaction has been completed (step 924).

[0101] The holder transaction agent 72 notifies the holder agent 42 that the verifiable presentation has been delivered and that the fleet transaction has been completed (step 926). The holder transaction agent 72 updates the transaction ledger 76 with the completion status of the fleet transaction indicating that the fleet transaction has been completed (step 928).

[0102] The scenario represented by process flow and system 900 is particularly suitable for application to the first use case described herein, which includes providing identity proof for sign-up to an online service. It may seem unusual and unacceptable that a new credential holder has to pay for identity credentials during service sign-up (if they don't already have identity credentials) under process flow and system 800. However, a holder of existing verifiable credentials that meet the verifier's requirements can provide unlocked credentials under process flow and system 900 to enable sign-up to an online service. Further, the scenarios represented by process flow and systems 800, 900 are particularly suitable for applications that support the exemplary second use case (i.e., providing educational certificates), the third use case (i.e., providing proof of age for access to a social club), and the fourth use case (i.e., providing proof of being an authorized purchaser of a particular product when a user writes a product / service review) described herein. Alternatively, other use cases can be supported by the scenarios represented by process flow and systems 800, 900.

[0103] In the third payment scheme of Table 2, the transaction agent is involved in the transaction where the verifier pays the holder. The payment conditions of the third payment scheme include the requirement to pay the holder for each transaction for the verifiable credentials used within the transaction. Referring to FIG. 7, an exemplary scenario where the third payment scheme is applied is represented by a process flow and system 1000 effective in a network environment. If the third payment scheme is applied and the holder does not yet have the required verifiable credentials, the process steps defined in process flow and system 800 for obtaining the verifiable credentials are executed, followed by the process steps of process flow and system 1000.

[0104] Process flow and system 1000 enables a method of conducting transactions on a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. As described with respect to process flow and system 1000, the first agent is depicted as the holder agent 42, the second agent is depicted as the verifier agent 52, the third agent is depicted as the holder transaction agent 72, the fourth agent is depicted as the verifier transaction agent 82, the fifth agent is depicted as the issuer agent 22, and the sixth agent is depicted as the issuer transaction agent 62. The depiction of the plurality of agents with respect to process flow and system 1000 is essentially exemplary, and process flow and system 1000 is not limited by the specific naming of each agent.

[0105] In process flow and system 1000, the holder, via the holder agent 42 (i.e., the first agent), wishes to initiate a transaction for the use of services from the provider, and the provider, functioning as a verifier via the verifier agent 52 (i.e., the second agent), wishes to verify the holder. The holder agent 42 requests services from the verifier agent 52 (step 1002). The verifier agent 52 initiates a new transaction (hereinafter, a "payment transaction") that enables payment by the verifier to the holder by sending a start notification to the verifier transaction agent 82 (i.e., the fourth agent) (step 1004). The verifier transaction agent 82 saves the notification of the payment transaction in the verified ledger 86 in the form of an update of the transaction (step 1006).

[0106] The verifier transaction agent 82 notifies the verifier agent 52 that the payment transaction has been successfully stored in the verified ledger 86, enabling the verifier agent 52 to start processing the presentation request (step 1008). The verifier agent 52 specifies, in the presentation request for the payment transaction, one or more data points (e.g., attributes of the verifiable credentials) required, and the presentation request defines the conditions of the payment transaction, which is similar to, for example, a contract (step 1010). The holder agent 42 sends a response to the presentation request for the verifier agent 52's payment transaction, including one or more requirements regarding the data requested by the verifier agent 52 to meet one or more data points for the initiated payment transaction (e.g., contract). One or more requirements provided by the holder agent 42 include, for example, one or more of the price for the requested data, a service level agreement ("SLA"), or a policy. If one or more requirements are accepted by the verifier agent 52, the verifier agent 52 responds by updating the payment transaction to generate a signed payment transaction that confirms the acceptance of the one or more requirements, and the verifier agent 52 sends a response including the signed payment transaction to the holder agent 42 (step 1014).

[0107] In step 1014, the signed (i.e., updated) payment transaction obtained by the Holder Agent 42 from the Verifier Agent 52 is sent by the Holder Agent 42 to the Holder Transaction Agent 72 (i.e., the third agent) (step 1016). The Holder Transaction Agent 72 beneficially verifies the signature of the signed payment transaction, for example, by applying the public key associated with the Verifier Agent 52 (step 1017). In step 1016, the signed (i.e., updated) payment transaction received by the Holder Transaction Agent 72 from the Holder Agent 42 is written by the Holder Transaction Agent 72 to the Transaction Ledger 76 (step 1018). Confirmation of the storage of the signed payment transaction in the Transaction Ledger 76 is sent by the Holder Transaction Agent 72 to the Holder Agent 42 (step 1020).

[0108] The Verifier Transaction Agent 82 sends a payment confirmation for the signed payment transaction to the Holder Transaction Agent 72 (step 1022). The Holder Transaction Agent 72 sends confirmation to the Holder Agent 42 that payment has been received from the Verifier via the Verifier Transaction Agent 82 for the payment transaction (step 1024).

[0109] The Holder Agent 42 sends a verifiable presentation of the payment transaction to the Verifier Agent 52 (step 1026). The verifiable presentation includes verifiable credentials that contain one or more data points requested by the Verifier Agent 52 and one or more proofs corresponding to the one or more requested data points. In response to receiving the verifiable presentation that includes verifiable credentials, the Verifier Agent 52 sends the completion status of the verifiable presentation to the Verifier Transaction Agent 82, notifying the Verifier Transaction Agent 82 that the verifiable presentation has been received from the Holder Agent 42 and the payment transaction between the Holder Agent 42 and itself has been completed (step 1028). The Verifier Transaction Agent 82 saves the verifiable presentation completion status that includes the payment transaction completion information in the verified ledger 86 in the form of an update of the transaction (step 1030). The Verifier Transaction Agent 82 sends a notice to the Holder Transaction Agent 72 that the verifiable presentation ("VP" (verifiable presentation)) has been delivered to the Verifier Agent 52 and the payment transaction has been completed (step 1032).

[0110] The Holder Transaction Agent 72 notifies the Holder Agent 42 that the verifiable presentation has been delivered and the payment transaction has been completed (step 1034). The Holder Transaction Agent 72 updates the transaction ledger 76 with the completion status of the payment transaction indicating that the payment transaction has been completed (step 1036).

[0111] The scenario represented by the process flow and system 1000 enables the fourth co - protocol described above. In the fourth co - protocol, in a transaction where the verifier agent 52 requires a verifiable credential already owned by the holder agent 42, the service is used by the holder of the holder agent 42, and the holder receives payment from the verifier by providing the verifiable credential as part of the transaction. The scenario represented by the process flow and system 1000 is particularly suitable for applications that support the fourth use - case described herein (i.e., providing proof of being a certified purchaser of a particular product when a user writes a review of a product / service). Alternatively, other use - cases can also be supported by the scenario represented by the process flow and system 1000.

[0112] In addition to the above description, referring to FIG. 5A, the process flow and system 600 enables a first method for conducting transactions on a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. The first method is described with reference to the steps and elements of the process flow and system 600 where the first agent is depicted as the holder transaction agent 72, the second agent is depicted as the holder agent 42, the third agent is depicted as the verifier agent 52, the fourth agent is depicted as the verifier transaction agent 82, the fifth agent is depicted as the issuer transaction agent 62, and the sixth agent is depicted as the issuer agent 22. The depiction of the plurality of agents with respect to the process flow and system 600 is essentially exemplary, and the process flow and system 600 is not limited by the specific naming of each agent.

[0113] A first method for conducting a transaction on a network includes receiving a digitally signed transaction by a holder transaction agent 72 (i.e., the first agent) from a holder agent 42 (i.e., the second agent), the digitally signed transaction being received by the holder agent 42 from a verifier agent 52 (i.e., the third agent) and including a digital signature (step 616). The holder transaction agent 72 verifies the digital signature beneficially (step 617). A first verifiable proof (e.g., a payment proof, a payment certificate) from a verifier transaction agent 82 (i.e., the fourth agent) is received by the holder transaction agent 72 (step 630). The first verifiable proof is transmitted by the holder transaction agent 72 to an issuer transaction agent (i.e., the fifth agent) (step 632). An unlock signature for the locked credentials provided to the holder agent 42 by the issuer agent 22 (i.e., the sixth agent) is received by the holder transaction agent 72 from the issuer transaction agent (step 636), and the unlock signature is transmitted by the holder transaction agent 72 to the verifier transaction agent 82 (step 638).

[0114] The first method further includes: sending a request to start using a service by the holder agent 42 to the verifier agent 52 (step 602); receiving, by the holder agent 42 from the verifier agent 52, a request for one or more data points that support verification of the entity starting to use the service (step 604); and sending, by the holder agent 42 to the verifier agent 52, one or more requirements for satisfying the one or more data points (step 612). For example, the entity can include one or both of a user of the holder agent 42 or an organization associated with the user of the holder agent 42. The one or more requirements can include, for example, one or more of price, a service level agreement (“SLA”), or a policy. The data points can include, for example, one or more of a surname, a given name, a date of birth, a credit card number, a social security number, a passport number. A digitally signed transaction is received by the holder agent 42 from the verifier agent 52 (step 614), and a second verifiable proof (e.g., a data point proof) is sent by the holder agent 42 to the verifier agent 52, and the second verifiable proof includes one or more data points based on locked credentials (step 622). For example, the second verifiable proof can include locked credentials that include one or more data points. The first method can further include updating a ledger by the holder transaction agent 72 based on the digitally signed transaction received from the holder agent 42 (step 618).

[0115] The first method further includes responding to a request for one or more data points from the verifier agent 52 by sending a request for locked credentials from the holder agent 42 to the issuer agent 22 (step 606), receiving the locked credentials from the issuer agent 22 by the holder agent 42 (step 610), and generating, by the holder agent 42, a second verifiable proof based on the locked credentials (step 622). A request for entity identification information from the issuer agent 22 is received by the holder agent 42, and the holder agent 42 obtains the entity identification information from the user, and the entity identification information can be sent by the holder agent 42 to the issuer agent 22 (step 608). The entity identification information can include, for example, a driver's license, a business license, a passport, a social security card, and the like.

[0116] The first method further includes receiving, by the verifier transaction agent 82 from the verifier agent 52, the digitally signed transaction and the second verifiable proof (step 626), and sending, by the verifier transaction agent 82 to the verifier agent 52, the unlock signature (step 640). The ledger can be updated by the verifier transaction agent 82 based on the digitally signed transaction and the second verifiable proof (step 628). The unlock signature is received by the verifier agent 52 from the verifier transaction agent 82 (step 640), the second verifiable proof is unlocked by the verifier agent 52 using the unlock signature (step 642), and the verifier agent 52 enables the use of the service in response to the unlocking of the second verifiable proof by the verifier agent 52.

[0117] In addition to the above description, referring to FIG. 6A, a process flow and system 800 enables a second method for conducting transactions on a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. The second method is described with reference to the steps and elements of process flow and system 800 where the first agent is depicted as the Holder Transaction Agent 72, the second agent is depicted as the Holder Agent 42, the third agent is depicted as the Verifier Agent 52, the fourth agent is depicted as the Issuer Transaction Agent 62, the fifth agent is depicted as the Issuer Agent 22, and the sixth agent is depicted as the Verifier Transaction Agent 82. The depiction of the plurality of agents with respect to process flow and system 800 is exemplary in nature, and process flow and system 800 is not limited by the specific naming of each agent.

[0118] A second method of conducting a transaction on a network includes receiving, by a holder transaction agent 72 (i.e., a first agent), a first transaction (e.g., a free transaction) from a holder agent 42 (i.e., a second agent) (step 820), the first transaction being initiated by a verifier agent 52 (i.e., a third agent). A first verifiable proof (e.g., a payment certificate) is transmitted by the holder transaction agent 72 to an issuer transaction agent 62 (i.e., a fourth agent) (step 832). The second method further includes receiving, by the holder transaction agent 72 from the issuer transaction agent 62, a credential signature for a verifiable credential including one or more data points provided to the holder agent 42 by an issuer agent 22 (i.e., a fifth agent) for the first transaction (step 834), and transmitting the credential signature by the holder transaction agent 72 to the holder agent 42 (step 836).

[0119] The second method further includes receiving, by the holder transaction agent 72 from the holder agent 42, a second transaction (e.g., a credential request transaction) including identification data of the issuer agent 22 (step 820), and transmitting, by the holder transaction agent 72 to the issuer transaction agent 62, a first verifiable proof based on the second transaction (step 832).

[0120] The second method is to send a request for a verifiable credential from the holder agent 42 to the issuer agent 22, the request for the verifiable credential including a second transaction (step 812), and further including providing entity identification information from the holder agent 42 to the issuer agent 22 (step 826). The verifiable credential is received by the holder agent 42 from the issuer agent 22 (step 828). An indication that the verifiable credential has been received by the holder agent 42 is received by the holder transaction agent 72 from the holder agent 42 (step 830). The sending of a first verifiable proof (e.g., a payment certificate) from the holder transaction agent 72 to the issuer transaction agent 62 (step 832) is in response to the receipt by the holder transaction agent 72 of an indication that the verifiable credential has been received by the holder agent 42 from the holder agent 42.

[0121] The second method further includes sending a request to start using the service from the holder agent 42 to the verifier agent 52 (step 802), and receiving a request for one or more data points to start using the service from the verifier agent 52 by the holder agent 42 (step 810). A credential signature is applied by the holder agent 42 to the verifiable credential to generate a signed credential including one or more data points (step 837), and the signed credential including one or more data points is sent by the holder agent 42 to the verifier agent 52 (step 838). A second verifiable proof including one or more data points is generated by the holder agent 42 based on the signed credential (step 837). The second verifiable proof including one or more data points may be sent by the holder agent 42 to the verifier agent 52 (step 838). The second verifiable proof is generated by the holder agent 42 and sent to the verifier agent 52 as a verifiable presentation (「VP」) including, for example, the signed credential.

[0122] The second method further includes the verifier transaction agent 82 receiving from the verifier agent 52 a display indicating that the second verifiable proof has been received by the verifier agent 52 (step 840). The display indicating that the second verifiable proof has been received by the verifier agent 52 is received by the holder transaction agent 72 from the verifier transaction agent 82 (step 844). The display indicating that the second verifiable proof has been received by the verifier agent 52 is sent by the holder transaction agent 72 to the holder agent 42 (step 846).

[0123] The second method further includes updating the ledger by the holder transaction agent 72 based on a second transaction (e.g., a credential request transaction) from the holder agent 42 (step 822), and updating the ledger by the holder transaction agent 72 based on an indication that a second verifiable proof has been received by the verifier agent 52 (step 848).

[0124] The second method further includes receiving, by the issuer transaction agent 62, a second transaction (e.g., a credential request transaction) from the issuer agent 22 (step 814), and transmitting, by the issuer transaction agent 62, a credential signature to the holder transaction agent 72 based on the second transaction and a first verifiable proof (e.g., a payment certificate) (step 834). The second transaction can include a digitally signed transaction, and the issuer transaction agent 62 can verify the digitally signed transaction (step 815).

[0125] Referring to FIG. 7 in addition to the above description, the process flow and system 600 enable a third method for conducting transactions over a network by a plurality of agents including a first agent, a second agent, a third agent, and a fourth agent. The third method is described with reference to the steps and elements of the process flow and system 1000 in which the first agent is depicted as the holder agent 42, the second agent is depicted as the verifier agent 52, the third agent is depicted as the holder transaction agent 72, and the fourth agent is depicted as the verifier transaction agent 82. The depiction of the plurality of agents with respect to the process flow and system 1000 is exemplary in nature, and the process flow and system 1000 are not limited by the specific naming of each agent.

[0126] A third way to conduct a transaction on a network is to send a request to start using a service from a holder agent 42 (i.e., the first agent) to a verifier agent 52 (i.e., the second agent) (step 1002), receive a request for one or more data points to start using the service from the verifier agent 52 by the holder agent 42 (step 1010), and send one or more requirements to satisfy the one or more data points from the holder agent 42 to the verifier agent 52 (step 1012). A digitally signed transaction (e.g., a payment transaction) including a digital signature is received by the holder agent 42 from the verifier agent 52 (step 1014). The digitally signed transaction is sent by the holder agent 42 to a holder transaction agent 72 (i.e., the third agent) (step 1016). An indication that a first verifiable proof (e.g., a payment proof, a payment certificate) of the digitally signed transaction has been received is received by the holder agent 42 from the holder transaction agent 72 (step 1024), and the holder agent 42 sends a second verifiable proof to the verifier agent 52, and the second verifiable proof is based on verifiable credentials including one or more data points (step 1026).

[0127] A third way to conduct a transaction on a network further includes receiving a first verifiable proof (e.g., a payment proof, a payment certificate) from a verifier transaction agent 82 (i.e., the fourth agent) by the holder transaction agent 72 (step 1022), and sending an indication that the first verifiable proof of the digitally signed transaction has been received from the holder transaction agent 72 to the holder agent 42 by the holder transaction agent 72 (step 1024).

[0128] The second verifiable proof beneficially includes the verifiable credential. The second verifiable proof can be sent as a verifiable presentation ("VP") that includes the verifiable credential (step 1026). A third way to conduct a transaction on the network is for the verifier transaction agent 82 to receive from the verifier agent 52 an indication that the second verifiable proof has been received by the verifier agent 52 in order to complete the digitally signed transaction (step 1028), for the holder transaction agent 72 to receive from the verifier transaction agent 82 an indication that the second verifiable proof has been received by the verifier agent 52 (step 1032), and for the holder transaction agent 72 to send to the holder agent 42 an indication that the second verifiable proof has been received by the verifier agent 52 (step 1034).

[0129] Referring to FIG. 4 in addition to the above description, the process flows and systems 600, 700, 800, 900, 1000 are implemented by a transaction scheme system 500 for conducting transactions on a network by a plurality of agents including a first agent, a second agent, a third agent, a fourth agent, a fifth agent, and a sixth agent. With respect to the transaction scheme system 500, the first agent is depicted as the holder transaction agent 72, the second agent is depicted as the holder agent 42, the third agent is depicted as the verifier agent 52, the fourth agent is depicted as the verifier transaction agent 82, the fifth agent is depicted as the issuer transaction agent 62, and the sixth agent is depicted as the issuer agent 22. The first computing device is depicted as the holder transaction agent service provider system 70, and the second computing device is depicted as the holder device 40. The depictions of the plurality of agents, devices, and ledgers with respect to the transaction scheme system 500 are essentially exemplary, and the transaction scheme system is not limited by the specific naming of each agent, device, or ledger.

[0130] The transaction scheme system 500 is configured to conduct transactions over a network and includes an owner transaction agent 72 (i.e., the first agent) and an owner agent 42 (i.e., the second agent). The owner agent 42 is operable to transact with a verifier agent 52 (i.e., the third agent) for using a service. The verifier agent 52 is communicable with a verifier transaction agent 82 (i.e., the fourth agent). The owner transaction agent 72 is operable to communicate with the owner agent 42 to facilitate a transaction between the owner agent 42 and the verifier agent 52 for using the service, and the owner transaction agent 72 is operable to communicate with the verifier transaction agent 82 to facilitate a transaction between the owner agent 42 and the verifier agent 52 for using the service.

[0131] The owner transaction agent 72 is further operable to transact with an issuer transaction agent 62 (i.e., the fifth agent) regarding the signature of a verifiable credential to facilitate a transaction between the owner agent 42 and the verifier agent 52 for using the service. The owner agent 42 is further operable to transact with an issuer agent 22 (i.e., the sixth agent) regarding a verifiable credential to facilitate a transaction between the owner agent 42 and the verifier agent 52 for using the service, and the issuer agent 22 is communicable with the issuer transaction agent 62. The owner agent 42 is further operable to send the verifiable credential to the verifier agent 52.

[0132] The holder transaction agent 72 is further operable to send the signature of the verifiable credential to the verifier transaction agent 82. The verifier transaction agent 82 included in the transaction scheme system 500 is operable to send the signature of the verifiable credential to the verifier agent 52. The transaction scheme system 500 further includes a transaction ledger 76, and the holder transaction agent 72 is operable to update the transaction ledger 76 based on a transaction by the holder agent 42 for service use. The transaction scheme system 500 further includes a verified ledger 86, and the verifier transaction agent 82 is operable to update the verified ledger 86 based on a transaction by the holder agent 42 for service use.

[0133] The transaction scheme system 500 further includes a holder transaction agent service provider system 70 in which the holder transaction agent 72 is enabled (i.e., a first computing device), and a holder device 40 in which the holder agent 42 is enabled (i.e., a second computing device).

[0134] The transaction scheme system 500 further includes an issuer transaction agent 62, which provides the signature of the verifiable credential to the holder transaction agent 72 and is operable to transact with the holder transaction agent 72 to facilitate a transaction between the verifier agent 52 for service utilization by the holder agent 42. The verifier transaction agent 82 is operable to receive the signature of the verifiable credential from the holder transaction agent 72 and transmit the signature of the verifiable credential to the verifier agent 52. The holder agent 42 is further operable to transact with the issuer agent 22 regarding the verifiable credential to facilitate a transaction between the verifier agent 52 for service utilization by the holder agent 42. The holder agent 42 is further operable to transmit the verifiable credential to the verifier agent 52.

[0135] The holder agent 42 is further operable to transmit a request for the verifiable credential to the issuer agent 22. The issuer transaction agent 62 is operable to receive the request for the verifiable credential from the issuer agent 22, receive the verifiable proof from the holder transaction agent 72, and based on the request for the verifiable credential and the verifiable proof, is further operable to transmit the signature of the verifiable credential to the holder transaction agent 72.

[0136] FIG. 8 abstractly shows the functionality of an exemplary computer system 2000 on which the systems, methods, and processes described herein may be implemented. For example, the issuer system 20, the holder device 40, the verifier system 50, the issuer transaction agent service provider system 60, the holder transaction agent service provider system 70, and the verifier transaction agent service provider system 80 may each be embodied by a particular computer system 2000. The computer system 2000 may be provided in the form of a personal computer, laptop, handheld mobile communication device, mainframe, distributed computing system, or other suitable computer configuration. Exemplary subject matter may be described herein as computer-executable instructions, for example, in the form of program modules, which may include programs, routines, objects, data structures, components, or architectures configured to perform particular tasks or implement particular abstract data types. The computer-executable instructions may be represented, for example, by instructions 2024 executable by the computer system 2000.

[0137] The computer system 2000 can operate as a stand-alone device or can be connected to other machines (e.g., network connection). In a networked deployment, the computer system 2000 can operate with the capabilities of a server or a client machine in a server-client network environment and as a peer machine in a peer-to-peer (or distributed) network environment. Also, the computer system 2000 can be considered to include a set (or sets) of instructions for executing one or more of the methodologies described herein, the set (or sets) of instructions being executed by a collection of machines acting individually or in concert.

[0138] It will be understood by those skilled in the art that the systems, methods, and processes described herein can be implemented using other computer systems including, but not limited to, network - connectable personal computers, minicomputers, mainframe computers, handheld mobile communication devices, multiprocessor systems, microprocessor - based or programmable electronic devices, and smartphones. Such computer systems can further be configured as a distributed computer environment where program modules are enabled and tasks are executed by processing devices linked on a computer network, and the program modules can be located in both local and remote memory storage devices.

[0139] The exemplary computer system 2000 includes a processor 2002, such as a central processing unit (CPU) or a graphics processing unit (GPU), main memory 2004, and static memory 2006 that communicate via a bus 2008. To display data to a user of the computer system 2000, a display device 2010, such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a cathode ray tube (CRT), is provided. The display device 2010 can be configured to receive data input from a user via, for example, a touch screen of a resistive film type or a capacitance type. The character input device 2012 can be provided in the form of a physical keyboard, or alternatively, as a program module that enables a user interactive simulated keyboard on the display device 2010 using, for example, a touch screen of a resistive film type or a capacitance type. An audio input device 2013, such as a microphone, enables voice language input that can be converted by the processor 2002 into text input via an instruction 2024. The pointing / selecting device 2014 is provided in the form of, for example, a computer mouse, or is enabled via a touch screen of a resistive film type or a capacitance type of the display device 2010. A data drive 2016, a signal generator 2018, such as an audio speaker, and a network interface 2020 can be provided. A positioning system 2017 is also provided, which includes, for example, a GPS receiver and porting hardware.

[0140] Instructions 2024 and data structures, such as software instructions, that embody or use the systems, methods, and processes described herein are stored on a computer-readable medium 2022 and are accessible via the data drive 2016. Further, when the instructions 2024 are executed, the instructions 2024 can reside, completely or partially, within the main memory 2004 or within the processor 2002 for a particular period of time. The main memory 2004 and the processor 2002 are also regarded as computer-readable media in this manner.

[0141] The computer-readable medium 2022 is shown as one medium, but the computer-readable medium 2022 can be considered to include one or more media in, for example, a centralized or distributed database that stores the instructions 2024, or a related cache and server. The computer-readable medium 2022 can store, encode, or carry instructions for machine execution, cause a machine to execute any one or more of the methodologies described herein, or store, encode, or carry data structures used by or related to such instructions, and can be considered to include any tangible medium capable of doing so. Further, the term "computer-readable storage medium" can be considered to include, but is not limited to, solid-state memory, optical media, and magnetic media that can store information in a non-transitory manner. The computer-readable medium can include, for example, non-volatile memory such as semiconductor memory devices (e.g., magnetic disks such as internal hard disks and removable disks, magneto-optical disks, CD-ROM and DVD-ROM disks, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory devices).

[0142] The instructions 2024 can be transmitted or received via a computer network using a signal transmission medium via a network interface 2020 that operates under one or more known transfer protocols such as, for example, FTP, HTTP, or HTTPs. Examples of computer networks include local area networks (LANs), wide area networks (WANs), the Internet, cellular phone networks, POTS (Plain Old Telephone) networks, and, for example, Wi-Fi TMand wireless data networks such as 3G / 4G / 5G cellular networks. The term "computer-readable signal medium" can be considered to include any transient non-tangible medium that can store, encode, or carry instructions for machine execution, including digital or analog communication signals, or other non-tangible media for facilitating the communication of such instructions.

[0143] The features and elements are described above in specific combinations, but those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.

[0144] Although the embodiments have been described in detail above, these embodiments are non-limiting and should be regarded as merely illustrative. Modifications and extensions can be developed, and all such modifications are considered to be within the scope defined by the appended claims.

Claims

1. Receiving, by a first agent, a digitally signed transaction from a second agent, wherein the digitally signed transaction is received by the second agent from a third agent and includes a digital signature; Receiving, by the first agent, a first verifiable proof from a fourth agent; Sending, by the first agent, the first verifiable proof to a fifth agent; Receiving, by the first agent, an unlock signature of locked credentials provided to the second agent by a sixth agent from the fifth agent; Sending, by the first agent, the unlock signature to the fourth agent; A method for conducting a transaction on a network comprising the above.

2. Sending, by the second agent, a request to the third agent to initiate use of a service; Receiving, by the second agent, from the third agent a request for at least one data point to support verification of the entity initiating the use of the service; Sending, by the second agent, to the third agent at least one requirement for satisfying the at least one data point; Receiving, by the second agent, the digitally signed transaction from the third agent; Sending, by the second agent, to the third agent a second verifiable proof, wherein the second verifiable proof is based on the locked credentials and includes the at least one data point. The method according to claim 1, further comprising the above.

3. The method according to claim 2, further comprising updating, by the first agent, a ledger based on the digitally signed transaction received from the second agent.

4. In response to the request for the at least one data point from the third agent, sending, by the second agent, a request for the locked credentials to the sixth agent; receiving, by the second agent, the locked credentials from the sixth agent; further comprising: generating, by the second agent, the second verifiable proof based on the locked credentials, the method according to claim 2.

5. receiving, by the second agent, a request for entity identification information from the sixth agent; obtaining, by the second agent, the entity identification information from a user; further comprising: transmitting, by the second agent, the entity identification information to the sixth agent, the method according to claim 4.

6. receiving, by the fourth agent, the digitally signed transaction and the second verifiable proof from the third agent; further comprising: transmitting, by the fourth agent, the unlock signature to the third agent, the method according to claim 4.

7. further comprising: updating, by the fourth agent, a ledger based on the digitally signed transaction and the second verifiable proof, the method according to claim 6.

8. receiving, by the third agent, the unlock signature from the fourth agent; further comprising: unlocking, by the third agent, the second verifiable proof using the unlock signature, the method according to claim 6.

9. further comprising: enabling, by the third agent, the use of the service in response to the unlocking of the second verifiable proof by the third agent, the method according to claim 8.

10. The method according to claim 5, wherein the entity identification information includes at least one of a driver's license, a business license, a passport, or a social security card.

11. The method according to claim 4, wherein the second verifiable proof includes the locked credentials.

12. The method according to claim 2, wherein the at least one data point includes at least one of a surname, a given name, a date of birth, a credit card number, a social security number, or a passport number.

13. The method according to claim 2, wherein the at least one requirement includes at least one of price, service level agreement (SLA), or policy.

14. The method according to claim 2, wherein the entity includes at least one of a user of the second agent or an organization associated with the user of the second agent.

15. The method according to claim 1, wherein the first verifiable proof includes a payment proof.

16. The method according to claim 1, further comprising verifying the digital signature by the first agent.

17. Sending a request to the third agent by the second agent to start using the service; Receiving a request for at least one data point to start using the service from the third agent by the second agent; Sending at least one requirement to the third agent by the second agent to meet the at least one data point; Receiving the digitally signed transaction from the third agent by the second agent; The method according to claim 1, further comprising sending the locked credentials including the at least one data point to the third agent by the second agent.

18. Receiving a first transaction from a second agent by a first agent, wherein the first transaction is initiated by a third agent; Sending a first verifiable proof from the first agent to a fourth agent; Receiving a credential signature for verifiable credentials including at least one data point from the fourth agent by the first agent, wherein the verifiable credentials include the at least one data point provided from a fifth agent to the second agent for the first transaction; Sending the credential signature from the first agent to the second agent; A method for conducting transactions on a network comprising.

19. Receiving, by the first agent from the second agent, a second transaction including identification data of the fifth agent The method according to claim 18, further comprising: transmitting, by the first agent to the fourth agent, the first verifiable proof based on the second transaction

20. Transmitting, by the second agent to the fifth agent, a request for the verifiable credentials, wherein the request for the verifiable credentials includes the second transaction Providing, by the second agent to the fifth agent, entity identification information Receiving, by the second agent from the fifth agent, the verifiable credentials The method further comprises: receiving, by the first agent from the second agent, an indication that the verifiable credentials have been received by the second agent The method according to claim 19, wherein transmitting, by the first agent to the fourth agent, the first verifiable proof is in response to receiving, by the first agent from the second agent, the indication that the verifiable credentials have been received by the second agent

21. Transmitting, by the second agent to the third agent, a request to start using a service Receiving, by the second agent from the third agent, a request for the at least one data point to start using the service Applying, by the second agent, a credential signature to the verifiable credentials to generate a signed credential including the at least one data point Generating, by the second agent, a second verifiable proof including the at least one data point based on the signed credential The method according to claim 20, further comprising: transmitting, by the second agent to the third agent, the second verifiable proof including the at least one data point

22. The method according to claim 21, further comprising transmitting, by the second agent, the second verifiable proof to the third agent as a verifiable presentation including the signed credentials.

23. Receiving, by a sixth agent, from the third agent, an indication that the second verifiable proof has been received by the third agent; Receiving, by the first agent, from the sixth agent, the indication that the second verifiable proof has been received by the third agent; The method according to claim 22, further comprising transmitting, by the first agent, the indication that the second verifiable proof has been received by the third agent to the second agent.

24. Updating, by the first agent, a ledger based on the second transaction from the second agent; The method according to claim 23, further comprising updating, by the first agent, the ledger based on the indication that the second verifiable proof has been received by the third agent.

25. Transmitting, by the second agent, a request to start using a service to the third agent; Receiving, by the second agent, from the third agent, a request for the at least one data point to start using the service; Applying, by the second agent, a credential signature to the verifiable credentials to generate signed credentials including the at least one data point; The method according to claim 20, further comprising transmitting, by the second agent, the signed credentials including the at least one data point to the third agent.

26. Receiving, by the fourth agent, the second transaction from the fifth agent; The method according to claim 20, further comprising transmitting, by the fourth agent, the credential signature to the first agent based on the second transaction and the first verifiable proof.

27. The second transaction includes a digitally signed transaction, and the method further comprises verifying the digitally signed transaction by the fourth agent, the method according to claim 26.

28. The method according to claim 19, further comprising updating a ledger by the first agent based on the second transaction from the second agent.

29. Sending a request to start using a service from a first agent to a second agent; Receiving, by the first agent, a request for at least one data point for starting to use the service from the second agent; Sending, by the first agent, at least one requirement for fulfilling the at least one data point to the second agent; Receiving, by the first agent, a digitally signed transaction including a digital signature from the second agent; Sending, by the first agent, the digitally signed transaction to a third agent; Receiving, by the first agent, a display indicating that a first verifiable proof of the digitally signed transaction has been received from the third agent; Sending, by the first agent, a second verifiable proof to the second agent, the second verifiable proof being based on verifiable credentials including the at least one data point; A method of conducting a transaction on a network comprising.

30. Receiving, by the third agent, the first verifiable proof from a fourth agent; The method according to claim 29, further comprising sending, by the third agent, the display indicating that the first verifiable proof of the digitally signed transaction has been received to the first agent.

31. The method according to claim 29, wherein the second verifiable proof includes the verifiable credentials.

32. The method according to claim 29, further comprising transmitting the second verifiable proof as a verifiable presentation including the verifiable credentials.

33. Receiving, by a fourth agent, from the second agent, a display indicating that the second verifiable proof has been received by the second agent; Receiving, by the third agent, from the fourth agent, the display indicating that the second verifiable proof has been received by the second agent; The method according to claim 29, further comprising transmitting, by the third agent, the display indicating that the second verifiable proof has been received by the second agent to the first agent.

34. A system for conducting transactions over a network, comprising a first agent and a second agent, wherein the second agent conducts a transaction with a third agent for utilization of a service, and the third agent is operable to communicate with a fourth agent; wherein the first agent communicates with the second agent to facilitate the transaction between the second agent and the third agent for utilization of the service; A system operable to communicate with a fourth agent to facilitate the transaction between the second agent and the third agent for utilization of the service.

35. The system according to claim 34, wherein the first agent is further operable to conduct a transaction with a fifth agent for signing of verifiable credentials to facilitate the transaction between the second agent and the third agent for utilization of the service.

36. The system according to claim 35, wherein the second agent is further operable to conduct a transaction with a sixth agent for the verifiable credentials to facilitate the transaction between the second agent and the third agent for utilization of the service, and the sixth agent is communicable with the fifth agent.

37. The system according to claim 36, wherein the second agent is further operable to send the verifiable credentials to the third agent.

38. The system according to claim 37, wherein the first agent is further operable to send the signature for the verifiable credentials to the fourth agent.

39. The system according to claim 38, further comprising the fourth agent, wherein the fourth agent is operable to send the signature for the verifiable credentials to the third agent.

40. The system according to claim 34, further comprising a ledger, wherein the first agent is operable to update the ledger based on the transaction by the second agent for the use of the service.

41. The system according to claim 37, further comprising the fourth agent and a ledger, wherein the ledger is operable to be updated based on the transaction by the second agent for the use of the service.

42. A first computing device on which the first agent is enabled, A second computing device on which the second agent is enabled, the system according to claim 34.

43. A fifth agent operable to transact with the first agent to provide a signature of verifiable credentials to the first agent to facilitate the transaction between the third agent and the second agent for the use of the service, The fourth agent, which receives the signature of the verifiable credentials from the first agent and is operable to send the signature of the verifiable credentials to the third agent, further comprising: The second agent is further operable to transact with a sixth agent for the verifiable credentials to facilitate the transaction between the second agent and the third agent for the use of the service. The system according to claim 34, wherein the second agent is further operable to send the verifiable credential to the third agent. **Claim 44** The second agent is further operable to send a request for the verifiable credential to the sixth agent, The fifth agent further, receives the request for the verifiable credential from the sixth agent, receives a verifiable proof from the first agent, and is operable to send the signature of the verifiable credential to the first agent based on the request for the verifiable credential and the verifiable proof. The system according to claim 43. **Claim 45** A system comprising a first agent and a second agent for conducting a transaction over a network, wherein the first agent receives a digitally signed transaction from the second agent, the digitally signed transaction being received by the second agent from a third agent and including a digital signature, receives a first verifiable proof from a fourth agent, sends the first verifiable proof to a fifth agent, receives an unlock signature of locked credentials provided to the second agent by a sixth agent from the fifth agent, and is operable to send the unlock signature to the fourth agent, wherein the second agent sends a request to the third agent to start using a service, receives a request for at least one data point to start using the service from the third agent, sends at least one requirement to the third agent to satisfy the at least one data point, receives the digitally signed transaction from the third agent, and is operable to send a second verifiable proof to the third agent, the second verifiable proof being based on the locked credentials and including the at least one data point. A system. **Claim 46** The system further comprising the fourth agent, wherein the second agent In response to the request for the at least one data point from the third agent, send a request for the locked credentials to the sixth agent, Receive the locked credentials from the sixth agent, Further operable to generate the second verifiable proof based on the locked credentials, The fourth agent, Receive the digitally signed transaction and the second verifiable proof from the third agent, The system according to claim 45, further operable to send the unlock signature to the third agent. **Claim 47** The system according to claim 45, further comprising a first computing device enabled by the first agent and a second computing device enabled by the second agent. **Claim 48** A system for conducting transactions over a network, comprising a first agent and a second agent, wherein the first agent Receives a first transaction and a second transaction from the second agent, the first transaction being initiated by a third agent, the second transaction including identification data of a fifth agent, Receives an indication from the second agent that verifiable credentials have been received by the second agent, the verifiable credentials including at least one data point provided to the second agent by the fifth agent for the first transaction, In response to receiving, by the first agent from the second agent, the indication that the verifiable credentials have been received by the second agent, send a first verifiable proof based on the second transaction to a fourth agent, Receives a credentials signature for the verifiable credentials from the fourth agent, Operable to send the credentials signature to the second agent, The second agent Sends a request for the verifiable credentials to the fifth agent, the request for the verifiable credentials including the second transaction, ​ Provide the entity identification information to the fifth agent, A system operable to receive the verifiable credentials from the fifth agent.

49. The second agent Sends a request to the third agent to start using the service, Receives a request for the at least one data point to start using the service from the third agent, Applies the credential signature to the verifiable credentials to generate signed credentials including the at least one data point, Generates a second verifiable proof including the at least one data point based on the signed credentials, The system according to claim 48, further operable to send the second verifiable proof including the at least one data point to the third agent.

50. Further comprising a sixth agent, the sixth agent Is operable to receive from the third agent a display indicating that the second verifiable proof has been received by the third agent, The first agent Receives the display indicating that the second verifiable proof has been received by the third agent from the sixth agent, The system according to claim 49, further operable to send the display indicating that the second verifiable proof has been received by the third agent to the second agent.

51. A system comprising a first agent and a third agent for conducting transactions over a network, wherein the first agent Sends a request to start using a service to a second agent, Receives a request for at least one data point to start using the service from the second agent, Sends at least one requirement to the second agent to satisfy the at least one data point, Receives a digitally signed transaction including a digital signature from the second agent, Sends the digitally signed transaction to a third party agent, Receive a display indicating that the first verifiable proof of the digitally signed transaction has been received from the third agent, Be operable to send a second verifiable proof to the second agent, the second verifiable proof being based on verifiable credentials including at least one data point, The third agent, Receive the first verifiable proof from a fourth agent, A system operable to send a display indicating that the first verifiable proof of the digitally signed transaction has been received to the first agent. **Claim 52** Sending a request to start using a service from a second agent to a third agent, Receiving a request for at least one data point for starting the use of the service from the third agent by the second agent, In response to the request for the at least one data point from the third agent, sending a request for locked credentials from the second agent to a sixth agent, Receiving the locked credentials from the sixth agent by the second agent, Sending at least one requirement for satisfying the at least one data point from the second agent to the third agent, Receiving a digitally signed transaction including a digital signature from the third agent by the second agent, Receiving the digitally signed transaction from the second agent by a first agent, Sending a second verifiable proof from the second agent to the third agent, the second verifiable proof being based on the locked credentials and including the at least one data point, Receiving the digitally signed transaction and the second verifiable proof from the third agent by a fourth agent, Receiving a first verifiable proof from the fourth agent by the first agent, Transmitting the first verifiable proof by the first agent to a fifth agent; Receiving an unlock signature of the locked credential from the fifth agent by the first agent; Transmitting the unlock signature by the first agent to a fourth agent; Transmitting the unlock signature by the fourth agent to a third agent, a method for conducting a transaction on a network comprising the foregoing.

53. Transmitting a request to start using a service by a second agent to a third agent; Receiving a request for at least one data point for starting to use the service from the third agent by the second agent; Transmitting a request for verifiable credentials including the at least one data point by the second agent to a fifth agent, wherein the request for the verifiable credentials includes a second transaction; Receiving the second transaction from the fifth agent by a fourth agent; Receiving a first transaction from the second agent by a first agent, wherein the first transaction is initiated by the third agent; Receiving the second transaction from the second agent by the first agent, wherein the second transaction includes identification data of the fifth agent; Providing entity identification information by the second agent to the fifth agent; Receiving the verifiable credentials including the at least one data point from the fifth agent by the second agent; Receiving from the second agent by the first agent an indication that the verifiable credentials have been received by the second agent; In response to receiving, by the first agent, the indication that the verifiable credential has been received by the second agent from the second agent, send, by the first agent, a first verifiable proof based on the second transaction to the fourth agent; Send, by the fourth agent, a credential signature for the verifiable credential based on the second transaction and the first verifiable proof to the first agent; Send, by the first agent, the credential signature to the second agent; Send, by the second agent, a second verifiable proof including the at least one data point based on the credential signature and the verifiable credential to the third agent; Receive, by the sixth agent, from the third agent, an indication that the second verifiable proof has been received by the third agent; Receive, by the first agent, from the sixth agent, the indication that the second verifiable proof has been received by the third agent; Send, by the first agent, the indication that the second verifiable proof has been received by the third agent to the second agent; A method for conducting a transaction on a network comprising the above.

Images