Ledger-based authentication

Abstract

The present disclosure provides devices, systems, and methods that can implement a ledger-based authentication. For example, a method for ledger-based authentication can include sending, by a user device, a user public key to an issuer system and receiving, by the user device, a signed user public key and a user identifier from the issuer system. The user public key can correspond to a user private key. The signed user public key can include the user public key signed using an issuer private key. The signed user public key and the user identifier can be published to a collaborative ledger. The method can further include signing, by the user device using the user private key, a challenge comprising the user identifier to generate a signed challenge. The user device can send the signed challenge to the merchant system to verify an identity of the user.

Description

TITLELEDGER-BASED AUTHENTICATIONTECHNICAL FIELD

[0001] At least some aspects of the present disclosure relate to identify authentication, and more particularly, to identify authentication based on a verifiable credential published to a collaborative ledger.BACKGROUND

[0002] Systems and methods for authenticating parties involved in a transaction often rely on Web2-based technology. For example, in order to conduct a financial transaction, a user may provide account credentials to a merchant system. The merchant system may then forward the account credentials to a centralized institution that stores and manages account credential data for a plurality of users. The centralized institution can verify the account credentials forwarded by the merchant based on the stored account credentials, thereby authenticating the user for the transaction. The merchant may consider the centralized institution to be a trusted institution for managing and verifying users’ account credentials. Thus, the merchant may rely on the authentication service provided by the centralized institution.

[0003] In various industries and countries, there exists an interest in transitioning toward decentralized, Web3-based technologies. For example, some industries and / or countries may seek to provide users with more control and ownership over their data and may therefore disfavor or even prevent centralized institutions from managing and controlling users’ credentials. These countries and / or industries may instead require decentralized control of user data. However, it can be difficult to authenticate and establish trust between parties utilizing decentralized, Web3-based technologies. For example, it can be difficult to authenticate the parties’ identities without a trusted, centralized institution that manages and verifies the parties’ credentials.

[0004] Accordingly, there exists a need for devices, systems, and methods for authenticating parties involved in a transaction that do not rely on a centralized institution for managing the parties’ credentials. The present disclosure provides various solutions that can implement a ledger-based authentication.SUMMARY

[0005] According to one aspect, the present disclosure provides a computer- implemented method. The computer-implemented method can include generating, by a user device associated with a user, a key pair comprising a user public key and a user privatekey. The computer-implemented method can further include sending, by the user device, the user public key to an issuer system and receiving, by the user device, a signed user public key and a user identifier from the issuer system. The signed user public key can include the user public key signed using an issuer private key associated with the issuer system. The signed user public key and the user identifier can be published to a collaborative ledger. The computer-implemented method can further include receiving, by the user device, a request for a challenge from a merchant system; signing, by the user device, the challenge using the user private key to generate a signed challenge; and sending, by the user device, the signed challenge to the merchant system to verify an identity of the user.

[0006] According to another aspect, the present disclosure provides a computer- implemented method. The computer-implemented method can include receiving, by a verification system, a signed user payload from an issuer system. The signed user payload can include a user payload signed using an issuer private key associated with the issuer system. The user payload can include a user public key and a user identifier corresponding to the user public key. The computer-implemented method can further include publishing, by the verification system, the user payload to a collaborative ledger. The computer- implemented method can further include receiving, by the verification system, a request to verify an identity of a user associated with the user identifier. The request can include a signed challenge. The signed challenge can include a challenge signed using a user private key corresponding to the user public key. The computer-implemented method can further include verifying, by the verification system, the identity of the user based on the signed challenge and the user payload published to the collaborative ledger and sending, by the verification system, a verification message based on verifying the identity of the user.

[0007] According to yet another aspect, the present disclosure provides a computer- implemented. The computer-implemented method can include generating, by an issuer system, an issuer key pair comprising an issuer public key and an issuer private key. The computer-implemented method can further include receiving, by the issuer system, a user public key generated by a user device. The computer-implemented method can further include generating, by the issuer system, a user identifier corresponding to the user public key and signing, by the issuer system using the issuer private key, a user payload comprising the user public key and the user identifier to generate a signed user payload. The computer-implemented method can further include sending, by the issuer system, the signed user payload to the user device and publishing, by the issuer system, the signed user payload to a collaborative ledger.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the description, for purposes of explanation and not limitation, specific details are set forth, such as particular aspects, procedures, techniques, etc. to provide a thorough understanding of the present technology. However, it will be apparent to one skilled in the art that the present technology may be practiced in other aspects that depart from these specific details.

[0009] The accompanying drawings, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate aspects of concepts that include the claimed disclosure and explain various principles and advantages of those aspects.

[0010] The apparatuses and methods disclosed herein have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various aspects of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0011] FIG. 1 is a block diagram of a ledger-based authentication system for authenticating an identity of a first party for transacting with a second party, according to at least one aspect of the present disclosure.

[0012] FIG. 2 is a block diagram of a ledger-based authentication system for authenticating an identity of a user for transacting with a merchant, according to at least one aspect of the present disclosure.

[0013] FIG. 3 is a block diagram of a ledger-based authentication system, according to at least one aspect of the present disclosure.

[0014] FIG. 4 is a flow diagram of a method for ledger-based authentication that can be performed by a user device, according to at least one aspect of the present disclosure.

[0015] FIG. 5 is a flow diagram of a method for ledger-based authentication that can be performed by a verification system, according to at least one aspect of the present disclosure.

[0016] FIG. 6 is a flow diagram of a method for ledger-based authentication that can be performed by an issuer system, according to at least one aspect of the present disclosure.

[0017] FIG. 7 is a block diagram of a computer apparatus with data processing subsystems or components, according to at least one aspect of the present disclosure.

[0018] FIG. 8 is a diagrammatic representation of an example system that includes a host machine, according to at least one aspect of the present disclosure.

[0019] Corresponding reference characters indicate corresponding parts throughout the several views. The exemplifications set out herein illustrate various aspects of the present disclosure, in one form, and such exemplifications are not to be construed as limiting the scope of the disclosure in any manner.DESCRIPTION

[0020] Before explaining various forms of devices, systems, and methods for ledgerbased authentication, it should be noted that the illustrative forms disclosed herein are not limited in application or use to the details of construction and arrangement of components illustrated in the accompanying drawings and description. The illustrative forms may be implemented or incorporated in other forms, variations, and modifications, and may be practiced or carried out in various ways. Further, unless otherwise indicated, the terms and expressions utilized herein have been chosen for the purpose of describing the illustrative forms for the convenience of the reader and are not for the purpose of limitation thereof. Also in the following description, it is to be understood that terms such as “forward,” “rearward,” “left,” “right,” “above,” “below,” “upwardly,” “downwardly,” and the like are words of convenience and are not to be construed as limiting terms.

[0021] As described above, systems and methods for authenticating parties involved in a transaction, such as financial transaction, often rely on a centralized institution that manages the parties’ (e.g., users’) credentials and provides authentication services based on those credentials. There exists an interest in transitioning away from employing centralized institutions for managing users’ data and instead employing decentralized technologies. However, it can be difficult to authenticate and establish trust between parties to a transaction utilizing decentralized technologies, for example, because it can be difficult to authenticate the parties’ identities without a trusted, centralized institution that manages and verifies the parties’ credentials. Accordingly, there exists a need for alternate devices, systems, and methods for authenticating parties involved in a transaction.

[0022] The present disclosure provides various devices, systems, and methods that can implement a ledger-based authentication. For example, in one aspect, a ledger-based authentication system is disclosed. The ledger-based authentication system can include a collaborative ledger. A plurality of different issuer systems can publish verifiable credentials to the collaborative ledger. The verifiable credentials published to the collaborate ledger can correspond to different users. In addition to publishing the verifiable credentials to thecollaborative ledger, the issuer systems can provision the verifiable credentials to user devices associated with the corresponding users. Thus, the collaborative ledger, collaboratively constructed based on receiving the users’ verifiable credentials from the different issuers, can manage the verifiable credentials (e.g., rather than a centralized institution).

[0023] Continuing with the example ledger-based authentication system discussed immediately above, the users can present their verifiable credentials to other parties to establish their identity. For example, a user may wish to conduct a transaction with a merchant. The user, via the user device, can send the verifiable credential to a merchant system associated with the merchant. The merchant system can forward the user’s verifiable credential to a third party, and the third party can compare the verifiable credential presented by the user to the verifiable credential published to the collaborative ledger. Based on identifying a match between the verifiable credentials, the third party system can send a message to the merchant system confirming that the user’s identity is authentic. Based on receiving the confirmed authentication of the user’s identity, the merchant system can proceed with the transaction.

[0024] The devices, systems, and methods provided herein can provide numerous benefits. For example, the collaborative ledger can provide a decentralize platform for managing users’ credentials. The users’ credentials do not need to be managed and verified by a centralized institution. Furthermore, users can choose from a plurality of different issuers for obtaining their verifiable credential. Thus, users can assume ownership over their data.

[0025] As another example, the devices, systems, and methods provided herein can provide a solution for achieving identity authentication and minimum viable trust on a decentralized platform. The users’ identities can be initially verified by the issuers and, based on this identity verification, the issuers can provision the verifiable credentials to the users and published the verifiable credentials to the collaborative ledger. A party wishing to receive authentication of an identity of one of the users can request that user present the user’s verifiable credential. The user’s verifiable credential can then be verified based on the corresponding credential published to the collaborative ledger, authenticating the user to the other party and establishing minimum viable trust for conducting the transaction.

[0026] As yet another example, the devices, systems, and methods provided herein can enable numerous different types of identity-dependent transactions to be conducted based on establishing a party’s (e.g., a user’s) identity via ledger-based authentication. For example, the devices, systems, and methods provided herein can enable transactions suchas identity-based new flows, identity-based treasury as a service, identity-based open banking, identity-based real time liquidity management, identity-based instant settlement, and identity-based payment (e.g., all without relying on a centralized institution to manage the credentials of the parties to the transactions).

[0027] FIG. 1 is a block diagram of a ledger-based authentication system 100, according to at least one aspect of the present disclosure. The ledger-based authentication system 100 can include a first party device 102, a second party device 104, an issuer system 106, and a collaborative ledger 108.

[0028] The first party device 102 can be associated with a first party and the second party device 104 can be associated with a second party. The first party and the second party may wish to conduct a transaction using the first party device 102 and the second party device 104. The second party may require authentication of the first party’s identity to establish trust for conducting the transaction. In one aspect of the disclosure, the first party may be a user and / or a consumer and the second party may be a merchant. In another aspect, the first party may be a first user and the second party may be a second user.

[0029] As used herein, a “transaction” can refer to any type of interaction between at least two parties that can be executed based on authentication of one or more than one of the parties’ identities. A transaction can be a financial transaction, such as, for example, a payment transaction, and investment transaction, a banking transaction, a treasury-as-a service transaction, a settlement transaction, and / or a transfer of a digital asset and / or liability. A transaction can be an informational transaction, such as, for example, a first party receiving or otherwise being granted access to digital information by a second party. A transaction can be a smart contract transaction.

[0030] As used herein, a “party” can refer to any entity involved in a transaction. For example, a party can be a user, a consumer, a merchant, a bank, and / or a wallet provider.

[0031] As used herein, a “user” can refer to an individual. In some aspects, a user may be associated with one or more personal accounts, identifiers, and / or devices. A user may also be referred to as a consumer.

[0032] As used herein, a “system” can refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and / or the like).

[0033] As used herein, a “user device” or a “party device” can refer to a computing device, such as, for example, a portable electronic device. A “portable electronic device” can refer to any electronic device that is portable and operated by a user and / or a party.Examples of portable electronic devices include smartphones and other mobile phones (e.g., cellular phones), tablet computers, laptop computers, netbooks, personal music players, e- readers, hand-held specialized readers, mobile Wi-Fi devices, handheld gaming systems, navigation systems, storage devices, portable media players, wearable devices (e.g., fitness bands, smart watches, headphones, earbuds), various electronic devices included in automobiles, and any other electronic device that a user may transport, carry, and / or wear. Other portable electronic devices can include robotic devices, remote-controlled devices, personal-care appliances, and so on. A “user device” or a “party device” can also refer to a device within a system associated with a user or a party.

[0034] Referring again to FIG. 1, the issuer system 106 can be associated with an issuer. The issuer, via the issuer system 106, can generate a verifiable credential that can be used to authenticate the first party’s identity to the second party. As explained further below, the issuer system 106 can provision the verifiable credential to the first party device 102 and can also publish the verifiable credential to the collaborative ledger 108. The first party device 102 can present the verifiable credential it receives from the issuer system 106 to the second party device 104. The second party device 104 can receive authentication of the first party’s identity based on the verifiable credential it receives form the first party device 102 and the verifiable credential that is published to the collaborative ledger 108. Although FIG. 1 depicts a single issuer system 106, the ledger-based authentication system 100 can include a plurality of different issuer systems that can provision verifiable credentials to different parties (e.g., different users) and publish the verifiable credentials to the collaborative ledger 108 (e.g., similar to the ledger-based authentication system 300 of FIG. 3).

[0035] As used herein, an “issuer” can refer to any entity that issues (e.g., generates, provisions) a verifiable credential for identity authentication of a party to a transaction. An issuer may be a bank, such as, for example, a bank that may also issue accounts (e.g., a credit account, a debit account, a credit card account, a debit card account, and / or the like) to a user for conducting transactions (e.g., payment transactions). In some aspects, an issuer may not be a bank. An issuer can be any entity that provides verifiable credentials as a service.

[0036] As used herein, a “collaborative ledger” can refer to a digital data structure that stores data. Different systems associated with different entities can publish data, such as verifiable credentials, to a collaborative ledger. For example, a collaborative ledger can store verifiable credentials published to the collaborative ledger by different issuer systems. Multiple systems may query or otherwise access data stored on a collaborative ledger. For example, systems other than the issuer systems may query a collaborative ledger to accessverifiable credentials stored thereon for authenticating the identity of party and / or a user. A collaborative ledger can have a decentralized or distributed configuration, for example, rather being controlled by a designated (e.g., centralized) system. In some aspects, a collaborative ledger may be or otherwise comprise a blockchain.

[0037] Referring again to FIG. 1, the disclosure now turns to an example method implemented across the ledger-based authentication system 100 for authenticating the first party’s identity. According to the method, the first party device 102 can request 110 a verifiable credential from the issuer system 106. For example, the first party device 102 may generate a first party key pair comprising a first party public key and a corresponding first party private key. The request 110 for the verifiable credential by the first party device 102 can include the first party public key. Additionally or alternatively, the request 110 for the verifiable credential by the first party device 102 can include identity and verification (ID&V) data for the first party. The ID&V data can include identity documents, biometric data, account data, and / or other data that can be used by the issuer system 106 to verify the identity of the first party. In some aspects, the issuer system 106 executes an ID&V process with the first party device 102 to verify the first party’s identity.

[0038] Based on receiving the request 110, the issuer system 106 can generate the verifiable credential and provision 112 the verifiable credential to the first party device 102. For example, the issuer system 106 can generate and / or retrieve an issuer key pair comprising an issuer public key and a corresponding issuer private key. The issuer system 106 can certify the first party public key by signing the first party public key using the issuer private key (e.g., encrypting the first party public key using the issuer private key by applying the first party public key and the issuer private key to a cryptographic algorithm) to generate a signed first party public key. The verifiable credential can comprise the signed first party pubic key. In some aspects, the issuer system 106 can generate a first party identifier for the first party. The first party identifier can comprise a string of characters unique to the first party. The verifiable credential can comprise the first party identifier. Thus, the verifiable credential provisioned 112 by the issuer system 106 can comprise the signed first party public key and / or the first party identifier.

[0039] The issuer system 106 can publish 114 the verifiable credential to the collaborative ledger 108. In some aspects, the issuer system 106 can have write access to the collaborative ledger 108 such the issuer system 106 can add the verifiable credential (e.g., the signed first party public key and / or the first party identifier) directly to the collaborative ledger 108. In some aspects, the issuer system 106 can send the verifiable credential to a verification system (e.g., similar to the verification system 210 of FIG. 2) and the verification system can publish 114 the verifiable credential to the collaborative ledger108. In some aspects, the collaborative ledger 108 can manage or otherwise store the issuer public key. The issuer public key can be used to decrypt data signed using the issuer private key (e.g., to decrypt the signed first party public key and / or a signed payload comprising the first party public key and the first party identifier).

[0040] The second party may require authentication of the first party’s identity (e.g., in order to conduct a transaction). To achieve the authentication, the first party device 102 can present 116 (e.g., send) the verifiable credential to the second party device 104. For example, the second party device 104 can request a challenge from the first party device 102. The challenge can include the verifiable credential (e.g., the first party public key signed with the issuer private key and / or the first party identifier). The first party device 102 can sign the challenge using the first party private key (e.g., encrypt the challenge using the first party private key by applying the challenge and the first party private key to a cryptographic algorithm). Thus, the verifiable credential presented 116 to the second party device 104 can comprise the signed challenge.

[0041] The verifiable credential presented 116 to the second party device 104 can be compared to the verifiable credential published 114 to the collaborative ledger 108 to authenticate the identity of the first entity. In some aspects, the second party device 104 may directly query 118 the collaborative ledger 108 to obtain the authentication.

[0042] In some aspects, the second party device 104 can relay the verifiable credential to a third party system (e.g., a system similar to the third party system 212 of FIG. 2). The third party system can query 118 the collaborative ledger 108 and return the query result to the second party device 104. For example, the second party device 104 can relay the signed challenge from the first party device 102 to the third party system. The third party system can query the collaborative ledger 108 to retrieve the first party public key. The third party system can use the first party public key from the collaborative ledger 108 to decrypt the signed challenge (e.g., signed with the first party private key), thereby accessing the signed first party public key (e.g., signed with the issuer private key) and / or the first party identifier. The third party system can query collaborative ledger 108 to retrieve the issuer public key. The third party system can use the issuer public key from the collaborative ledger 108 to decrypt the signed first party public key (e.g., signed with the issuer private key), thereby accessing the first party public key. The third party system can authenticate the identity of the first entity by comparing the first party public key published to the collaborative ledger 108 to the first party public key accessed by decrypting the signed challenge from the first party device 102. Based on identifying a match between the first party public keys, the third party can send a message to the second party device 104 indicating that the identity of the first party is authenticated (e.g., confirming that the first part owns the first party identifier).

[0043] Based on authenticating the identity of the first party, the first party device 102 and the second party device 104 can conduct 120 a transaction. Accordingly, the identity of the first party can be authenticated based on a verifiable credential published to a collaborative ledger 108. Furthermore, as noted above, the ledger-based authentication system 100 can include a plurality of different issuer systems that can publish verifiable credentials corresponding to different parties to the collaborative ledger 108. Thus, the ledger-based authentication system 100 can enable the authentication of parties’ identities base on decentralized control of the parties’ verifiable credentials (e.g., without the involvement of a centralized institution that manages, controls, and performs identity authentication of the parties’ verifiable credentials).

[0044] FIG. 2 is a block diagram of a ledger-based authentication system 200, according to at least one aspect of the present disclosure. The ledger-based authentication system 200 can include a user device 202, a merchant system 204, an issuer system 206, a verification system 210, and a third party system 212.

[0045] In various aspects, the ledger-based authentication system 200 can be similar to the ledger-based authentication system 100 of FIG. 1. For example, the user device 202 can be similar to the first party device 102, the merchant system 204 can be similar to the second party device 104, the issuer system 206 can be similar to the issuer system 106, and the collaborative ledger 208 can be similar to the collaborative ledger 108. Any of the features of the ledger-based authentication system 100 disclosed herein can be similarly implemented with the ledger-based authentication system 200, and vice versa.

[0046] The user device 202 can be associated a user. The merchant system 204 can be associated with a merchant. The user may wish to conduct a transaction (e.g., a purchase transaction) with the merchant. The merchant may require authentication of the user’s identity to execute the transaction. The issuer system 206 can be associated with an issuer. As explained further below, the issuer system 206 can provision a verifiable credential to the user device 202 and cause the verifiable credential to be published to the collaborative ledger 208. The user device 202 can present the verifiable credential to the merchant system 204. The merchant system 204, via the third party system 212, can obtain authentication of the user identity based on the verifiable credential received from the user device 202 and the verifiable credential that is published to the collaborative ledger 208. Although FIG. 2 depicts a single issuer system 206, the ledger-based authentication system 200 can include a plurality of different issuer systems for provisioning and publishing verifiable credentials for a plurality of different users (e.g., similar to the ledger-based authentication system 300 of FIG. 3).

[0047] The verification system 210 can comprise or otherwise implement the collaborative ledger 208. In some aspects, verification system 210 can host the collaborative ledger 208. In some aspects, the collaborative ledger 208 may be hosted by a plurality of distributed nodes corresponding to a plurality of different systems or devices. The verification system 210 can establish communications with the issuer system 206, enabling the issuer system 206 to publish data to the collaborative ledger 208 and / or enabling the verification system 210 to receive requests from the issuer system 206 to publish data to the collaborative ledger 208. The verification system 210 can establish communications with the third party system 212, enabling the third party system 212 to execute queries based on data stored to the collaborative ledger 208 and / or enabling the verification system 210 to receive requests from the third party system 212 for the verification system 210 to execute queries based on data stored to the collaborative ledger 208.

[0048] Referring still to FIG. 2, the disclosure now turns to an example method implemented across the ledger-based authentication system 200 for authenticating the user’s identity. According to the method, the user device 202 can generate a key pair comprising a user public key and a corresponding user private key 214. In some aspects, the user device 202 may execute an issuer application (e.g., an application made available for download to the user device 202 by an issuer associated with issuer system 206) that causes the user device 202 to generate the user public key and the user private key 214.

[0049] The user device 202 (e.g., based on instructions of the issuer application) can send the user public key 216 to the issuer system 206. The user public key 216 may be included in a message sent to the issuer system 206 requesting that the issuer system 206 provision a verifiable credential to the user device 202. The message may include ID&V data that can be used by the issuer system 206 to verify the identity of the user and / or to execute an ID&V process.

[0050] The issuer system 206 can generate and / or store its own issuer key pair comprising an issuer public key and an issuer private key 218. Based on receiving the user public key 216, the issuer system 206 can sign the user public key 216 using the issuer private key (e.g., encrypt the user public key using the issuer private key by applying the user public key and the issuer private key to a cryptographic algorithm) to generate a signed user public key (e.g., thereby certifying the user public key). Further, the issuer system 206 can generate a user identifier for the user. The user identifier can comprise a string of characters unique to the user. The issuer system 206 can send a payload comprising the signed user public key and the user identifier 220 to the user device 202. The payload comprising the signed user public key and the user identifier can serve as a verifiable credential.

[0051] The issuer system 206 can send the signed user public key and the user identifier 220 to the verification system 210. In some aspects, the issuer system 206 may hash the signed user pubic key and / or the user identifier 220 and send the hashed data to the verification system 210 to preserve privacy.

[0052] The verification system 210 can receive the signed user pubic key and the user identifier 220 form the issuer system 206. In some aspects, the verification system 210 and / or the collaborative ledger 208 can store or otherwise manage the issuer public key. Thus, in some aspects, the verification system 210 can verify that the signed user public key and the user identifier 220 are from the issuer system 206 by decrypting the signed user public key (e.g., signed with the issuer private key) using the issuer public key. The verification system 210 can publish the user public key and the user identifier 220 to the collaborative ledger 208. In other aspects, the verification system 210 can publish the signed user public key and the user identifier 220 to the collaborative ledger 208.

[0053] The merchant may require authentication of the user identity, for example, in order to establish trust for conducting a transaction. To initiate the authentication process, the merchant system 204 can send a request for a challenge to the user device 202. The user device 202 can receive the request for the challenge from the merchant system 204. The user device 202 (e.g., based on instructions of the issuer application) can generate and sign the challenge. The challenge can include the signed user public key (e.g., signed with the issuer private key) and the user identifier 220 provisioned by the issuer system 206. The user device can sign the challenge using its own user private key and send the resulting signed challenge 224 to the merchant system 204.

[0054] The merchant system 204 can receive the signed challenge 224 from the user device 202. The merchant system 204 can forward the signed challenge 224 to the third party system 212. The third party system 212 can act as a bridge between the merchant system 204 and the verification system 210 to facilitate authentication of the user’s identity based on the signed challenge 224 and the collaborative ledger 208.

[0055] Based on receiving the signed challenge 224 from the merchant system 204, the third party system 212 can submit a ledger query 228 to the verification system 210. In some aspects, the verification system 210 can execute the ledger query 228. In other aspects, the third party system 212 can have access to the collaborative ledger 208 and can execute the ledger query 228.

[0056] In some aspects, the ledger query 228 can include instructions to retrieve the user public key published to the collaborative ledger and use the retrieved user public key to decrypt the signed challenge (e.g., signed with the user private key), thereby accessing thesigned user public key (e.g., signed with the issuer private key) and the user identifier. In some aspects, the user identity can be authenticated based on (i) the signed user public key and the user identifier assessed by decrypting the signed challenge 224 and (ii) the signed user public key and the user identifier 220 published to the collaborative ledger 208.

[0057] In some aspects, the ledger query 228 can further include instructions to retrieve the issuer public key from the verification system 210 and / or collaborative ledger 208 and use the issuer public key to decrypt the signed user public key included in the challenge (e.g., signed with the issuer private key), thereby accessing the user public key. The ledger query can further include instructions to authenticate the identity of the user (e.g., verify that the user owns the user identifier) based on comparing (i) the user public key published to the collaborative ledger 208 and (ii) the user public key accessed by decrypting the signed challenge from the user device 202.

[0058] The ledger query 228 can return a query result 230. The query result 230 can include (i) a confirmed authentication of the user identity (e.g., confirming the user owns the user identifier) based on the user public keys matching or (ii) an unconfirmed authentication of the user identity based on the user public keys not matching. In some aspects, the query result 230 can be sent to the third party system 212 (e.g., if the verification system 210 executes the ledger query 228). The third party system 212 can send the query result 230 to the merchant system 204.

[0059] Based on the query result 230, the merchant system 204 can determine whether or not to conduct a transaction with the user and / or the user device 202. For example, if the query result 230 comprises a confirmed authentication of the user identity, the merchant system 204 may determine that trust has been established and may proceed with the transaction. If the query result 230 comprises an unconfirmed authentication of the user identity (e.g., no authentication), the merchant system 204 may determine that it will not proceed with the transaction.

[0060] In some aspects, the merchant system 204 can generate a merchant key pair comprising a merchant public key and a merchant provide key 234. Likewise, in some aspects, the third party system 212 can generate a third party key pair comprising a third party public key and a third party private key 236.

[0061] The verification system 210 and / or the collaborative ledger can manage or otherwise store the public keys for some or all of the entities comprised in the ledger-based authentication system 200 (e.g., the user public key, the merchant public key, the issuer public key, the third party public key). Any communication sent by an entity of the ledgerbased authentication system 200 may be signed using the sending entity’s private key.Because the verification system 210 and / or the collaborative ledger 208 can manage or otherwise store the sending entity’s public key, the verification system 210 and / or the collaborative ledger 208 can use the sending entity’s public key to decrypt the sending entity’s signature to verify that the message originated from the sending entity. For example, before forwarding the signed challenge 224 to the third party system 212, the merchant system 204 may certify the signed challenge 224 with its own signature using the merchant private key. The merchant public key stored by the verification system 210 and / or the collaborative ledger 208 can be used to confirm that the signed challenge 224, further signed with the merchant private key, was forwarded by the merchant system 204.

[0062] FIG. 3 is a block diagram of a ledger-based authentication system 300, according to at least one aspect of the present disclosure. The ledger-based authentication system 300 can include a plurality of user devices 202 (e.g., 202i. 2022, . . . 202n), a plurality of merchant systems 204 (e.g., 204i. 2042, . . . 204n), a plurality of issuer systems 206 (e.g., 206i. 2062, . . . 206n), a verification system 210, and a plurality of third party systems 212 (e.g., 212i. 2122, . . . 212n). In various aspects, the ledger-based authentication system 300 can be similar to the ledger-based authentication system 200 of FIG. 2, with corresponding reference characters indicate corresponding devices and system. As noted above, the ledger-based authentication system 200 can be similar to the ledger-based authentication system 100 of FIG. 1. Any of the features of the ledger-based authentication system 100 and / or the ledger-based authentication system 200 disclosed herein can be similarly implemented with the ledger-based authentication system 300, and vice versa.

[0063] The different user devices 202 of the ledger-based authentication system 300 can correspond to different users. Likewise, different issuer systems 206 of the ledger-based authentication system 300 can correspond to different issuers. The users can choose any one or more than one of the issuers and corresponding issuer systems 206 as a verifiable credential (e.g., signed user public key and user identifier) provider. Furthermore, each of the issuer systems 206 can send any of the verifiable credentials it provisions to user devices 202 to the verification system 210 to be published on the collaborative ledger 208. The merchants can choose any one or more than one of the third parties and corresponding third party systems 212 to provide user identity authenticating services based on the verifiable credentials published to the collaborative ledger 208. Thus, FIG. 3 illustrates that the ledger-based authentication system 300 can provide users and merchants with control to select the providers(s) of its choice for services related to identity authentication.Furthermore, FIG. 3 illustrates that the ledger-based authentication system 300 can serve as a decentralized platform for identity authentication that does not require a centralized institution to provide minimum viable trust between parties to a transaction.

[0064] Any of the user devices 202, the merchant systems 204, the issuer systems 206, the verification system 210, and the third party systems 212 can interconnect (e.g., establish a connection to communicate) via the network 240. The network 240 may include one or more wired and / or wireless networks. For example, the network 240 may include a cellular network (e.g., a long-term evolution (LTE) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and / or the like, and / or a combination of these or other types of networks.

[0065] The number and arrangement of devices, systems, and networks shown in the ledger-based authentication system 300 of FIG. 3 are provided as an example. There may be additional devices, systems, and / or networks; fewer devices, systems, and / or networks, different devices, systems, and / or networks, or differently arranged devices, systems, and / or networks than those shown in FIG. 3. Furthermore, two or more systems shown in FIG. 3 may be implemented within a single system and / or device, or a single system shown in FIG. 3 may be implemented as multiple, distributed devices and / or systems. Additionally or alternatively, a set of devices (e.g., one or more devices) of the ledger-based authentication system 300 may perform one or more functions described as being performed by another set of devices of ledger-based authentication system 300.

[0066] FIG. 4 is a flow diagram of a method 400 for ledger-based authentication, according to at least one aspect of the present disclosure. The method 400 may be performed by any of the party devices and / or user devices disclosed herein, such as, for example, the user device 202 of FIG. 2.

[0067] Referring to FIG. 4, and also to FIG. 2, according to the method 400, the user device 202 can generate 402 a key pair comprising a user public key and a user private key 214. The user device 202 can send 404 the user public key 216 to the issuer system 206. The user device 202 can receive 406 a signed user public key and a user identifier 220 from the issuer system 206. The signed user public key can include the user public key 216 signed using an issuer private key associated with the issuer system 206. The signed user public key and the user identifier 220 can be published to the collaborative ledger 208.

[0068] Still referring to FIG. 4, and also to FIG. 2, according to the method 400, the user device 202 can receive 408 a request for a challenge from the merchant system 204. The user device 202 can sign 410 the challenge using the user private key to generate a signedchallenge 224. The user device 202 can send 412 the signed challenge to the merchant system 204 to verify an identity of the user.

[0069] According to some aspects of the method 400, the user device 202 can execute a financial transaction with the merchant system 204 based on the user identifier.

[0070] According to some aspects of the method 400, the challenge comprises the signed user public key and / or the user identifier. The user device can sign 410 the challenge using the user private key to generate the signed challenge 224 by applying the signed user public key, the user identifier, and the user private key to a cryptographic algorithm.

[0071] According to some aspects of the method 400, the signed challenge 224 can include a signature that is verifiable based on the user public key published to the collaborative ledger 208.

[0072] According to some aspects of the method, the user device 202 sends identity and verification data to the issuer system 206

[0073] FIG. 5 is a flow diagram of a method 500 for ledger-based authentication, according to at least one aspect of the present disclosure. The method 500 may be performed by any of the verification systems disclosed herein, such as, for example, the verification system 210 of FIG. 2.

[0074] Referring to FIG. 5, and also to FIG. 2, according to the method 500, the verification system 210 can receive 502 a signed user payload (e.g., the signed user public key and a user identifier 220) from the issuer system 206. The signed user payload can include a user payload (e.g., the user public key and the user identifier) signed using an issuer private key associated with the issuer system 206. The verification system can publish 504 the user payload (e.g., user identifier and the user public key) to the collaborative ledger 208.

[0075] Still referring to FIG. 5, and also to FIG. 2, according to the method 500, the verification system 210 can receive 506 a request (e.g., the ledger query 228) to verify an identity of the user associated with the user identifier. The request can include the signed challenge 224. The signed challenge can include a challenge signed using the user private key corresponding to the user public key. The verification system 210 can verify 508 the identity of the user based on the signed challenge 224 and the user payload published to the collaborative ledger 208. The verification system 210 can send 510 a verification message (e.g., the query result 230) based on verifying the identity of the user.

[0076] According to some aspects of the method 500, the verification system 210 receives an issuer public key corresponding to the issuer private key from the issuer system206 and publishes the issuer public key to the collaborative ledger 208. The verification system 210 can extract the user payload from the signed user payload (e.g., signed with the issuer private key) using the issuer public key.

[0077] According to some aspects of the method 500, the challenge comprises the user public key and / or the user identifier.

[0078] According to some aspects of the method 500, the verification system 210 verifies 508 the identity of the user based on the signed challenge 224 and the user payload published to the collaborative ledger 208 by: (i) extracting the challenge from the signed challenge (e.g., signed with the user private key) based on the user public key (e.g., from the user payload) published to the collaborative ledger 208 and (ii) comparing the challenge to the user identifier and the user public key (e.g., from the user payload) published to the collaborative ledger 208. Extracting the challenge from the signed challenge based on the user public key can include applying the signed challenge 224 and the user public key to a cryptographic algorithm.

[0079] According to some aspects of the method 500, the collaborative ledger 208 can be or can otherwise comprise a blockchain.

[0080] According to some aspects of the method 500, the request to verify the identity of the user associated with the user identifier received 506 by the verification system 210 is from the merchant system 204. The verification system 210 may receive the request from the third party system 212, which can act as a bridge between the merchant system 204 and the verification system 210. The verification system 210 can send 510 the verification message to the third party system 212.

[0081] FIG. 6 is a flow diagram of a method for ledger-based authentication, according to at least one aspect of the present disclosure. The method 600 may be performed by any of the issuer systems disclosed herein, such as, for example, the issuer system 206 of FIG. 2.

[0082] Referring to FIG. 6, and also to FIG. 2, according to the method 600, the issuer system 206 can generate 602 an issuer key pair comprising an issuer public key and an issuer private key 218. The issuer system 206 can receive 604 the user public key 216 generated by the user device 202. The issuer system can generate 606 a user identifier corresponding to the user public key. The issuer system can sign 608 a user payload (e.g., the user public key and the user identifier) to generate a signed user payload. The issuer system 206 can send 610 the signed payload to the user device 202 and publish 612 the signed payload to the collaborative ledger 208.

[0083] According to some aspect of the method 600, the issuer the issuer public key to the collaborative ledger 208.

[0084] FIG. 7 is a block diagram of a computer apparatus 3000 comprising data processing subsystems or components, according to at least one aspect of the present disclosure. The subsystems shown in FIG. 7 are interconnected via a system bus 3010. Additional subsystems such as a printer 3018, keyboard 3026, fixed disk 3028 (or other memory comprising computer readable media), monitor 3022, which is coupled to a display adapter 3020, and others are shown. Peripherals and input / output (I / O) devices, which couple to an I / O controller 3012 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as a serial port 3024. For example, the serial port 3024 or external interface 3030 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 3010 allows the central processor 3016 to communicate with each subsystem and to control the execution of instructions from system memory 3014 or the fixed disk 3028, as well as the exchange of information between subsystems. The system memory 3014 and / or the fixed disk 3028 may embody a computer readable medium.

[0085] FIG. 8 is a diagrammatic representation of an example computing system 4000 that includes a host machine 4002 within which a set of instructions to perform various aspects of any one or more of the methodologies discussed herein may be executed, such as, for example, the method 400 of FIG. 4, the method 500 of FIG. 5, and / or the method 600 of FIG 6, according to at least one aspect of the present disclosure. In various aspects, the host machine 4002 operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the host machine 4002 may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The host machine 4002 may be a computer or computing device, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a portable music player (e.g., a portable hard drive audio device such as an Moving Picture Experts Group Audio Layer 3 (MP3) player), a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0086] The example computing system 4000 includes the host machine 4002, running ahost operating system (OS) 4004 on a processor or multiple processor(s) / processor core(s) 4006 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), and various memory nodes 4008. The host OS 4004 may include a hypervisor 4010 which is able to control the functions of and / or communicate with a virtual machine (“VM”) 4012 running on machine readable media. The VM 4012 also may include a virtual CPU or vCPU 4014. The memory nodes 4008 may be linked or pinned to virtual memory nodes or vNodes 4016. When the memory node 4008 is linked or pinned to a corresponding vNode 4016, then data may be mapped directly from the memory nodes 4008 to the corresponding vNode 4016.

[0087] All the various components shown in host machine 4002 may be connected with and to each other, or communicate to each other via a bus (not shown) or via other coupling or communication channels or mechanisms. The host machine 4002 may further include a video display, audio device or other peripherals 4018 (e.g., a liquid crystal display [LCD], alpha-numeric input device(s) including, e.g., a keyboard, a cursor control device, e.g., a mouse, a voice recognition or biometric verification unit, an external drive, a signal generation device, e.g., a speaker,) a persistent storage device 4020 (also referred to as disk drive unit), and a network interface device 4022. The host machine 4002 may further include a data encryption module (not shown) to encrypt data. The components provided in the host machine 4002 are those typically found in computer systems that may be suitable for use with aspects of the present disclosure and are intended to represent a broad category of such computer components that are known in the art. Thus, the example computing system 4000 can be a server, minicomputer, mainframe computer, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.

[0088] The disk drive unit 4024 also may be a Solid-state Drive (SSD), a hard disk drive (HDD) or other includes a computer or machine-readable medium on which is stored one or more sets of instructions and data structures (e.g., data / instructions 4026) embodying or utilizing any one or more of the methodologies or functions described herein. The data / instructions 4026 also may reside, completely or at least partially, within the main memory node 4008 and / or within the processor(s) 4006 during execution thereof by the host machine 4002. The data / instructions 4026 further may be transmitted or received over a network 4028 via the network interface device 4022 utilizing any one of several well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP)).

[0089] The processor(s) 4006 and memory nodes 4008 also may comprise machine-readable media. The term "computer-readable medium" or “machine-readable medium” should be taken to include a single medium or multiple medium (e.g., a centralized or distributed database and / or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable medium" shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the host machine 4002 and that causes the host machine 4002 to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such a set of instructions. The term ’’computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. Such media may also include, without limitation, hard disks, floppy disks, flash memory cards, digital video disks, random access memory (RAM), read-only memory (ROM), and the like. The example aspects described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.

[0090] One skilled in the art will recognize that Internet service may be configured to provide Internet access to one or more computing devices that are coupled to the Internet service, and that the computing devices may include one or more processors, buses, memory devices, display devices, input / output devices, and the like. Furthermore, those skilled in the art may appreciate that the Internet service may be coupled to one or more databases, repositories, servers, and the like, which may be utilized to implement any of the various aspects of the disclosure as described herein.

[0091] The computer program instructions also may be loaded onto a computer, a server, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0092] Suitable networks may include or interface with any one or more of, for instance, a local intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a virtual private network (VPN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM(Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Furthermore, communications may also include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS (Global Positioning System), CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an IEEE 802.11 -based radio frequency network. The network 4028 can further include or interface with any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking.

[0093] In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and / or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.

[0094] The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the host machine 4002, with each server 4030 (or at least a plurality thereof) providing processor and / or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.

[0095] It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire, and fiber optics, among others, including the wires that comprise one aspect of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) andinfrared (IR) data communications. Common forms of computer-readable media include, for example, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH EPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.

[0096] Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.

[0097] Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the "C" programming language, Go, Python, or other programming languages, including assembly languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0098] Examples of the devices, systems, and methods according to various aspects of the present disclosure are provided below in the following numbered clauses. An aspect of any of the devices(s), method(s), and / or system(s) may include any one or more than one, and any combination of, the numbered clauses described below.

[0099] Clause 1: A computer-implemented method, comprising: generating, by a user device associated with a user, a key pair comprising a user public key and a user private key; sending, by the user device, the user public key to an issuer system; receiving, by the user device, a signed user public key and a user identifier from the issuer system, wherein the signed user public key includes the user public key signed using an issuer private key associated with the issuer system, and wherein the signed user public key and the user identifier are published to a collaborative ledger; receiving, by the user device, a request for a challenge from a merchant system; signing, by the user device, the challenge using the user private key to generate a signed challenge; and sending, by the user device, the signedchallenge to the merchant system to verify an identity of the user.

[0100] Clause 2: The method of Clause 1 , further comprising, executing, by the user device, a financial transaction with the merchant system based on the user identifier.

[0101] Clause 3: The method of any of Clauses 1-2, wherein the challenge comprises the signed user public key.

[0102] Clause 4: The method of any of Clauses 1-3, wherein the challenge comprises the user identifier.

[0103] Clause 5: The method of any of Clauses 1-4, wherein the signing the challenge using the user private key to generate the signed challenge comprises applying the signed user public key, the user identifier, and the user private key to a cryptographic algorithm.

[0104] Clause 6: The method of Clauses 1-5, wherein the signed challenge comprises a signature that is verifiable based on the user public key.

[0105] Clause 7: The method of Clauses 1-6, wherein sending the user public key to the issuer system comprises, sending, by the user device, the user public key and user identity and verification data to the issuer system.

[0106] Clause 8: A computer-implemented method, comprising: receiving, by a verification system, a signed user payload from an issuer system, wherein the signed user payload includes a user payload signed using an issuer private key associated with the issuer system, and wherein the user payload comprises a user public key and a user identifier corresponding to the user public key; publishing, by the verification system, the user payload to a collaborative ledger; receiving, by the verification system, a request to verify an identity of a user associated with the user identifier, wherein the request comprises a signed challenge, and wherein the signed challenge includes a challenge signed using a user private key corresponding to the user public key; verifying, by the verification system, the identity of the user based on the signed challenge and the user payload published to the collaborative ledger; and sending, by the verification system, a verification message based on verifying the identity of the user.

[0107] Clause 9: The computer-implemented method of Clause 8, further comprising: receiving, by the verification system, an issuer public key corresponding to the issuer private key from the issuer system; and publishing, by the verification system, the issuer public key to the collaborative ledger.

[0108] Clause 10: The computer-implemented method of Clause 9, further comprising extracting, by the verification system, the user payload from the signed user payload usingthe issuer public key published to the collaborative ledger.

[0109] Clause 11 : The computer-implemented method of any of Clauses 8-10, wherein the challenge comprises the user public key.

[0110] Clause 12: The method of any of Clauses 8-11, wherein the challenge comprises the user identifier.

[0111] Clause 13: The method of any of Clauses 8-12, wherein the verifying the identity of the user based on the signed challenge and the user payload published to the collaborative ledger comprises: extracting, by the verification system, the challenge from the signed challenge based on the user public key from the user payload published to the collaborative ledger; and comparing, by the verification system, the challenge to the user identifier and the user public key from the user payload published to the collaborative ledger.

[0112] Clause 14: The method of Clause 13, wherein the extracting the challenge from the signed challenge based on the user public key comprises applying the signed challenge and the user public key to a cryptographic algorithm.

[0113] Clause 15: The method of any of Clauses 8-14, wherein the collaborative ledger comprises a blockchain.

[0114] Clause 16: The method of any of Clauses 8-15, wherein the request to verify the identity of the user associated with the user identifier is from a merchant system.

[0115] Clause 17: The method of Clause 16, wherein the receiving the request to verify the identity of the user associated with the user identifier comprises receiving, by the verification system, the request from a third-party system acting as an bridge between the merchant system and the verification system.

[0116] Clause 18: The method of Clause 17, wherein the sending the verification message based on verifying the identity of the user comprises sending, by the verification system, the verification message to the third-party system.

[0117] Clause 19: A computer-implemented method, comprising: generating, by an issuer system, an issuer key pair comprising an issuer public key and an issuer private key; receiving, by the issuer system, a user public key generated by a user device; generating, by the issuer system, a user identifier corresponding to the user public key; signing, by the issuer system using the issuer private key, a user payload comprising the user public key and the user identifier to generate a signed user payload; sending, by the issuer system, the signed user payload to the user device; and publishing, by the issuer system, the signed user payload to a collaborative ledger.

[0118] Clause 20: The method of Clause 19, further comprising publishing, by the issuer system, the issuer public key to the collaborative ledger.

[0119] Further, it is understood that any one or more of the following-described forms, expressions of forms, examples, can be combined with any one or more of the other following-described forms, expressions of forms, and examples.

[0120] While several forms have been illustrated and described, it is not the intention of Applicant to restrict or limit the scope of the appended claims to such detail. Numerous modifications, variations, changes, substitutions, combinations, and equivalents to those forms may be implemented and will occur to those skilled in the art without departing from the scope of the present disclosure. Moreover, the structure of each element associated with the described forms can be alternatively described as a means for providing the function performed by the element. Also, where materials are disclosed for certain components, other materials may be used. It is therefore to be understood that the foregoing description and the appended claims are intended to cover all such modifications, combinations, and variations as falling within the scope of the disclosed forms. The appended claims are intended to cover all such modifications, variations, changes, substitutions, modifications, and equivalents.

[0121] As used herein, a “server” may include one or more computing devices which can be individual, stand-alone machines located at the same or different locations, may be owned or operated by the same or different entities, and may further be one or more clusters of distributed computers or “virtual” machines housed within a datacenter. It should be understood and appreciated by a person of skill in the art that functions performed by one “server” can be spread across multiple disparate computing devices for various reasons. As used herein, a “server” is intended to refer to all such scenarios and should not be construed or limited to one specific configuration. Further, a server as described herein may, but need not, reside at (or be operated by) a merchant, a payment network, a financial institution, a healthcare provider, a social media provider, a government agency, or agents of any of the aforementioned entities. The term “server” also may refer to or include one or more processors or computers, storage devices, or similar computer arrangements that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computers, e.g., servers, or other computerized devices, e.g., point-of-sale devices, directly or indirectly communicating in the network environment may constitute a “system,” such as a merchant's point-of-sale system.Reference to “a server” or “a processor,” as used herein, may refer to a previously recitedserver and / or processor that is recited as performing a previous step or function, a different server and / or processor, and / or a combination of servers and / or processors. For example, as used in the specification and the claims, a first server and / or a first processor that is recited as performing a first step or function may refer to the same or different server and / or a processor recited as performing a second step or function.

[0122] As used herein, a “server computer” may describe a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. The server computer may be associated with an entity such as a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. In some embodiments or aspects, the server computer may provide and / or support payment network cloud service.

[0123] Reference to “a device,” “a server,” “a processor,” and / or the like, as used herein, may refer to a previously recited device, server, or processor that is recited as performing a previous step or function, a different server or processor, and / or a combination of servers and / or processors. For example, as used in the specification and the claims, a first server or a first processor that is recited as performing a first step or a first function may refer to the same or different server or the same or different processor recited as performing a second step or a second function.

[0124] One or more components may be referred to herein as “configured to,” “configurable to,” “operable / operative to,” “adapted / adaptable,” “able to,” “conformable / conformed to,” etc. Those skilled in the art will recognize that “configured to” can generally encompass active-state components and / or inactive-state components and / or standby-state components, unless context requires otherwise.

[0125] Those skilled in the art will recognize that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitationis intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to claims containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and / or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

[0126] The term “substantially,” “about,” or “approximately” as used in the present disclosure, unless otherwise specified, means an acceptable error for a particular value as determined by one of ordinary skill in the art, which depends in part, on how the value is measured or determined. In certain aspects, the term “substantially,” “about,” or “approximately” means within 1, 2, 3, or 4 standard deviations. In certain aspects, the term “substantially,” “about,” or “approximately” means within 50%, 20%, 15%, 10%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1%, 0.5%, or 0.05% of a given value or range.

[0127] In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those within the art that typically a disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms unless context dictates otherwise. For example, the phrase “A or B” will be typically understood to include the possibilities of “A” or “B” or “A and B.”

[0128] With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flow diagrams are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated, or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise.

[0129] It is worthy to note that any reference to “one aspect,” “an aspect,” “an exemplification,” “one exemplification,” and the like means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, appearances of the phrases “in one aspect,” “in an aspect,” “in an exemplification,” and “in one exemplification” in various places throughout the specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more aspects.

[0130] As used herein, the singular form of “a,” “an,” and “the” include the plural references unless the context clearly dictates otherwise.

[0131] Any patent application, patent, non-patent publication, or other disclosure material referred to in this specification and / or listed in any Application Data Sheet is incorporated by reference herein, to the extent that the incorporated materials is not inconsistent herewith. As such, and to the extent necessary, the disclosure as explicitly set forth herein supersedes any conflicting material incorporated herein by reference. Any material, or portion thereof, that is said to be incorporated by reference herein, but which conflicts with existing definitions, statements, or other disclosure material set forth herein will only be incorporated to the extent that no conflict arises between that incorporated material and the existing disclosure material.

[0132] In summary, numerous benefits have been described which result from employing the concepts described herein. The foregoing description of the one or more forms has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed. Modifications or variations are possible in light of the above teachings. The one or more forms were chosen and described in order to illustrate principles and practical application to thereby enable one of ordinary skill in the art to utilize the various forms and with various modifications as are suited to the particular use contemplated. It is intended that the claims submitted herewith define the overall scope.

Claims

CLAIMSWhat is claimed is:

1. A computer-implemented method, comprising: generating, by a user device associated with a user, a key pair comprising a user public key and a user private key; sending, by the user device, the user public key to an issuer system; receiving, by the user device, a signed user public key and a user identifier from the issuer system, wherein the signed user public key includes the user public key signed using an issuer private key associated with the issuer system, and wherein the signed user public key and the user identifier are published to a collaborative ledger; receiving, by the user device, a request for a challenge from a merchant system; signing, by the user device, the challenge using the user private key to generate a signed challenge; and sending, by the user device, the signed challenge to the merchant system to verify an identity of the user.

2. The method of Claim 1, further comprising, executing, by the user device, a financial transaction with the merchant system based on the user identifier.

3. The method of Claim 1, wherein the challenge comprises the signed user public key.

4. The method of Claim 3, wherein the challenge comprises the user identifier.

5. The method of Claim 4, wherein the signing the challenge using the user private key to generate the signed challenge comprises applying the signed user public key, the user identifier, and the user private key to a cryptographic algorithm.

6. The method of Claim 5, wherein the signed challenge comprises a signature that is verifiable based on the user public key.

7. The method of Claim 1 , wherein sending the user public key to the issuer system comprises, sending, by the user device, the user public key and user identity and verification data to the issuer system.

8. A computer-implemented method, comprising: receiving, by a verification system, a signed user payload from an issuer system,wherein the signed user payload includes a user payload signed using an issuer private key associated with the issuer system, and wherein the user payload comprises a user public key and a user identifier corresponding to the user public key; publishing, by the verification system, the user payload to a collaborative ledger; receiving, by the verification system, a request to verify an identity of a user associated with the user identifier, wherein the request comprises a signed challenge, and wherein the signed challenge includes a challenge signed using a user private key corresponding to the user public key; verifying, by the verification system, the identity of the user based on the signed challenge and the user payload published to the collaborative ledger; and sending, by the verification system, a verification message based on verifying the identity of the user.

9. The computer-implemented method of Claim 8, further comprising: receiving, by the verification system, an issuer public key corresponding to the issuer private key from the issuer system; and publishing, by the verification system, the issuer public key to the collaborative ledger.

10. The computer-implemented method of Claim 9, further comprising extracting, by the verification system, the user payload from the signed user payload using the issuer public key published to the collaborative ledger.

11. The computer-implemented method of Claim 10, wherein the challenge comprises the user public key.

12. The method of Claim 11, wherein the challenge comprises the user identifier.

13. The method of Claim 12, wherein the verifying the identity of the user based on the signed challenge and the user payload published to the collaborative ledger comprises: extracting, by the verification system, the challenge from the signed challenge based on the user public key from the user payload published to the collaborative ledger; and comparing, by the verification system, the challenge to the user identifier and the user public key from the user payload published to the collaborative ledger.

14. The method of Claim 13, wherein the extracting the challenge from the signed challenge based on the user public key comprises applying the signed challenge and theuser public key to a cryptographic algorithm.

15. The method of Claim 8, wherein the collaborative ledger comprises a blockchain.

16. The method of Claim 8, wherein the request to verify the identity of the user associated with the user identifier is from a merchant system.

17. The method of Claim 16, wherein the receiving the request to verify the identity of the user associated with the user identifier comprises receiving, by the verification system, the request from a third-party system acting as an bridge between the merchant system and the verification system.

18. The method of Claim 17, wherein the sending the verification message based on verifying the identity of the user comprises sending, by the verification system, the verification message to the third-party system.

19. A computer-implemented method, comprising: generating, by an issuer system, an issuer key pair comprising an issuer public key and an issuer private key; receiving, by the issuer system, a user public key generated by a user device; generating, by the issuer system, a user identifier corresponding to the user public key; signing, by the issuer system using the issuer private key, a user payload comprising the user public key and the user identifier to generate a signed user payload; sending, by the issuer system, the signed user payload to the user device; and publishing, by the issuer system, the signed user payload to a collaborative ledger.

20. The method of Claim 19, further comprising publishing, by the issuer system, the issuer public key to the collaborative ledger.

Images