Using contactless cards to securely share personal data stored on the blockchain

Abstract

A system, method, and apparatus for securely sharing data stored on a blockchain are provided. [Solution] In a system 100 having a verification system including a contactless card, a merchant device, a mobile device, and a verification service, the contactless card receives a request to provide a data element from the device. An applet on the contactless card encrypts the data element and wallet address, generates a signature for the request, and sends the signature and encrypted data to the mobile device. The mobile device sends the signature and encrypted data to the verification service. The verification service verifies the signature with a public key. A node in the blockchain creates a block in the blockchain. The block includes a verification instruction for the signature, the requested data element, and the wallet address. The encrypted data element corresponding to the data element is decrypted with the public key. The device receives the decrypted data element from the wallet address.

Description

[Technical field]

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 359,980, entitled “USE OF CONTACTLESS CARDS TO SECURELY SHARE PERSONAL DATA STORED IN A BLOCKCHAIN,” filed March 20, 2019, the contents of which are incorporated herein by reference in their entirety.

[0002] SUMMARY OF THE DISCLOSURE Embodiments herein relate generally to sharing data, and more specifically, to securely sharing personal data stored on a blockchain using contactless cards. [Background technology]

[0003] Users often need to share personal data with merchants, government officials, and other entities. However, using traditional techniques often exposes more personal data than necessary. For example, when purchasing an age-restricted item, only the person's age needs to be provided. However, scanning a driver's license at the point of sale may expose additional data, such as the individual's name, address, and driver's license number. Summary of the Invention

[0004]

[0005] The embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for using contactless cards to securely share personal data stored in a blockchain. In one example, a communication interface of the contactless card may receive a request from a card reader of a merchant device to provide a user data element to a wallet address associated with the merchant. An applet executing in a memory of the contactless card may encrypt an indication of the user data element and the wallet address based on a private key stored in the memory of the contactless card. The applet may generate a digital signature for the request based on the private key and transmit the digital signature and the encrypted indication of the user data element and the wallet address to a card reader of a mobile device via the communication interface of the contactless card. The mobile device may transmit the digital signature and the encrypted indication of the user data element and the wallet address to a verification service. The verification service may verify the digital signature based on a public key associated with the private key of the contactless card. A node in the blockchain may generate a block in the blockchain corresponding to the request in response to verification by the verification service, the block comprising the digital signature, the requested data element, and an indication of verification of the wallet address associated with the merchant. The encrypted data element corresponding to the user data element may be decrypted using the public key, and the merchant's device may receive the decrypted data element from a wallet address associated with the merchant to fulfill the request. [Brief description of the drawings]

[0005] [Figure 1] 1 illustrates an embodiment of a system. [Figure 2A] It gives an example of using contactless cards to securely share personal data stored on the blockchain. [Figure 2B] It gives an example of using contactless cards to securely share personal data stored on the blockchain. [Figure 2C]It gives an example of using contactless cards to securely share personal data stored on the blockchain. [Diagram 3] 1 illustrates a logical model of an exemplary blockchain. [Figure 4] Shows a logical model of messages stored on the blockchain. [Diagram 5] 1 illustrates an embodiment of a first logic flow. [Figure 6] 1 illustrates a second logic flow embodiment. [Figure 7] 13 illustrates a third logic flow embodiment. [Figure 8] 1 illustrates an embodiment of a computing architecture. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] The embodiments disclosed herein provide techniques for securely publishing personal data stored on a blockchain using a contactless card. Generally, a merchant device may store data describing one or more elements of personal data requested from a user. For example, the merchant device may request the user to provide a name and date of birth. In response, the user may tap the contactless card to the merchant device and receive data describing the requested elements of the user data (e.g., name and date of birth). An applet running on the contactless card may generate an encrypted payload using a private key and sign the encrypted payload using the private key. The encrypted payload may generally instruct the merchant to publish and / or verify the requested data to a wallet address associated with the merchant. The applet may then transmit the signed encrypted payload to the user's mobile device. The user's mobile device may then transmit the received data over a network (e.g., the Internet) to a validation service. The validation service may store a corresponding instance of the private key and decrypt the encrypted data using the stored private key. The validation service may further validate the digital signature received from the mobile device. A block may be added to the blockchain to reflect the requested transaction (e.g., publishing the name and date of birth). The merchant device may then receive the data from the blockchain and decrypt the data using the corresponding key, thereby publishing the requested data to the merchant device without publishing any additional data of the user.

[0007] As an advantage, the embodiments disclosed herein leverage contactless cards to expose and / or verify personal information stored on a blockchain. The embodiments disclosed herein provide a fast, efficient and secure technique for exposing and / or verifying one or more specific data elements as needed, rather than exposing all personal information. Doing so increases the security of the personal data and allows for more efficient processing of user data by requesting devices.

[0008] With general reference to the notation and nomenclature used herein, one or more portions of the following detailed description may be presented in terms of program procedures executed on a computer or network of computers. These procedure descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is herein, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are operations requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0009] Further, these operations are often referred to in terms such as adding or comparing, which are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein forming part of one or more of the embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein and written in accordance with the teachings herein, and / or include apparatus or digital computers specially constructed for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for these various machines will be apparent from the description given.

[0010] Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It will be apparent, however, that the novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate the description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0011] FIG. 1 illustrates a schematic diagram of an exemplary system 100 corresponding to the disclosed embodiments. As shown, the system 100 includes one or more contactless cards 101, one or more mobile devices 110, one or more verification systems 120, one or more merchant devices 130, and one or more blockchains 140. The contactless card 101 is representative of any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, etc. The contactless card 101 may include one or more chips for a communication interface 108, such as a radio frequency identification (RFID) chip, configured to communicate with the mobile device 110 via near field communication (NFC), EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an exemplary communication interface, the present disclosure is equally applicable to other types of wireless communication, such as EMV standard, Bluetooth, and / or Wi-Fi. The mobile device 110 is representative of any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, etc.

[0012] Merchant device 130 represents any type of device configured to communicate with a payment card, such as a payment terminal, a card reader, a mobile device, a computing device, etc. Merchant device 130 is associated with a merchant wallet address 131-1 and one or more cryptographic merchant keys 132. In general, merchant device 130 may communicate with contactless card 101 via card interface 118-2. Similarly, mobile device 110 communicates with contactless card 101 via card interface 118-1. Card interface 118 (including card interfaces 118-1 and 118-2) may be any type of communication interface, such as a wireless communication interface (e.g., NFC, Bluetooth, and / or RFID), a magnetic stripe reader, and / or a slot configured to communicate data from memory 102 of contactless card 101.

[0013] As shown, the contactless card's memory 102 includes one or more applets 103, a private key 104, a transaction key 105, a public key 106, and a digital signature 107. The applets 103 represent executable code that may execute on a processor (not shown) of the contactless card 101 and that is configured to perform any number and type of operations. For example, the applets 103 may include a first applet 103 (referred to herein as a "selection applet") that selects one of the other applets 103 based on the type of function to be performed by the contactless card 101. For example, when processing a transaction request, the selection applet 103 may select a second applet 103 (referred to herein as a "transaction applet") that will process the transaction using the contactless card 101. In such an embodiment, the transaction applet 103 may select a transaction key 105 to generate cryptographic data for processing the transaction. The transaction may be posted to a first instance of a blockchain 140, which is a blockchain of transactions. As another example, when processing a request to provide user data 141 stored in the blockchain 140, the selection applet 103 may select a third applet 103 (referred to herein as a “user data applet”) to process the request to provide the user data 141. In such an embodiment, the user data applet 103 may select a private key 104 to process the request to provide the user data 141. Such a transaction may be posted to a second instance of the blockchain 140, which is a blockchain for storing the user data 141.

[0014] In some embodiments, contactless card 101 may include a single private key (e.g., private key 104 and / or one of transaction keys 105) used to generate encrypted data for transactions and user data requests. In some such embodiments, contactless card 101 may include a single applet 103 that generates encrypted data for transactions and user data requests using the single private key. The particular number and / or type of applets and / or encryption keys used herein should not be considered limiting of the disclosure.

[0015] For example, a user associated with a contactless card 101 may attempt to purchase an age-restricted item from a merchant. The merchant device 130 of the merchant may require verification of the user's age before allowing the user to purchase the item. The user may tap the contactless card 101 to the merchant device 130, thereby bringing the contactless card 101 close enough to the card interface 118-2 of the merchant device 130 to enable NFC data transfer between the communication interface 108 of the contactless card 101 and the card interface 118-2 of the merchant device 130. In other embodiments, the user may insert the contactless card 101 into the card interface 118-2 of the merchant device 130. The merchant device 130 may transmit request data including at least the merchant wallet address 131-1, a request token (not shown) identifying the request, and an indication of one or more requested elements of user data 141 (e.g., at least the customer's age). The elements of user data may be user data 141 stored on the blockchain 140. In some embodiments, the user data 141 is stored in a cloud-based database. However, this disclosure is applicable to all types of data storage technologies.

[0016] In some embodiments, the merchant device 130 may initiate a request to receive user data 141 and / or to verify user data 141. In other embodiments, the mobile device 110 initiates a transaction to provide and / or verify user data 141. Any entity within the system 100 may initiate a given request to receive user data 141 and / or a transaction to provide user data 141, so the particular entity that initiates the communication should not be considered limiting of disclosure.

[0017] In response to receiving the release and / or verification request from the merchant device 130, the selection applet 103 may determine that the type of request is associated with a request to provide user data 141. Thus, the selection applet 103 may select the user data applet 103 and provide the received data to the user data applet 103. The user data applet 103 may then select a private key 104 to generate encrypted data used to verify the release of the requested user data elements. For example, the encryption function of the user data applet 103 may use the private key 104 to encrypt the merchant wallet address 131-1, the request token, and an indication of the requested data elements. In some embodiments, additional data elements may be encrypted using the private key 104, such as an account identifier for the contactless card 101, an identifier for the user, etc. Additionally, the user data applet 103 may use the private key 104 and the encryption function to generate a digital signature 107. The digital signature 107 is used to verify that the user has approved the release of the requested user data 141 from the blockchain 140.

[0018] The user data applet 103 may then transmit the encrypted data (including the digital signature 107) to the account application 113 of the mobile device 110 in response to tapping the contactless card 101 to the mobile device 110. The user may tap the contactless card 101 to the mobile device 110, thereby bringing the contactless card 101 close enough to the card interface 118-1 of the mobile device 110 to enable NFC data transfer between the communication interface 108 of the contactless card 101 and the card interface 118-1 of the mobile device 110. Generally, the account application 113 allows a user to perform various account-related operations, such as viewing account balances, processing payments, and publishing user data 141. In some embodiments, a user must authenticate using authentication credentials to access the account application 113. For example, the authentication credentials may include a username and password, a biometric identifier (e.g., a fingerprint, an iris scan, etc.). The mobile device 110 is generally under the control of an operating system (not shown). Examples of operating systems include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems.

[0019] The account application 113 may then transmit the wallet address 131-2 associated with the user and the data received from the contactless card 101 to a verification service 121 of one or more verification systems 120. The verification service 121 may then verify the digital signature 107 using a key from a verification key 122 and a signature verification algorithm. The verification key 122 may include a copy of the private key 104 and the public key 106 of the contactless card 101. The verification service 121 may decrypt the digital signature 107 using the verification key 122 (e.g., the public key 106) and the signature verification algorithm to verify the digital signature 107. Additionally, the verification service 121 may decrypt encrypted data generated by the contactless card 101 using one of the verification keys 122 (e.g., a copy of the private key 104 of the contactless card 101). In some embodiments, the verification service 121 may determine whether the decrypted data includes an expected value (e.g., a customer identifier, an account identifier, etc.) before releasing the requested data. Thus, for example, if the verification service 121 cannot verify the digital signature 107 and / or decrypt the encrypted data, the verification service 121 may refrain from releasing the requested data.

[0020] Once the digital signature 107 has been verified and / or the encrypted data generated by the contactless card 101 has been decrypted, the verification service 121 may cause a computational node to generate a block in the blockchain 140 that reflects the publication of the requested user data 141. For example, the block in the blockchain 140 may include an encrypted indication of the user's (or other user and / or account identifier's) wallet address 131-2, merchant wallet address 131-1, the request token, the public key 106, and the associated user data 141 (e.g., the user's age in the previous example). Once posted to the blockchain 140, the merchant device 130 may decrypt the data in the blockchain 140 (e.g., using key 132 and / or public key 106) to read the user data 141. Thus, continuing with the previous example, the merchant device 130 may decrypt the data in the blockchain 140 to read the request token and the user's age. In some embodiments, the merchant device 130 may verify the digital signature 107 using the public key 106. The merchant device 130 may then determine the user's age. If the determined age exceeds the age limit of the product, the merchant device 130 may allow the user to purchase the product. Otherwise, the merchant device 130 may restrict the user from purchasing the product.

[0021] According to some embodiments, the merchant device 130 may receive the verification without receiving the actual user data 141. Instead, in such embodiments, logic external to the merchant device 130 (e.g., the verification service 121) may receive the user data 141, process the user data 141, and transmit the result to the merchant device 130. For example, the verification service 120 may determine whether the user's age exceeds the age limit of the product. The verification service 121 may then transmit the result (e.g., yes, the customer is of age, and / or no, the customer is not of age) to the merchant device 130, which may restrict and / or allow purchases based on the received result, without the user's actual age being revealed to the merchant device 130.

[0022] Additionally, the verification service 121 may be configured to manage and verify the user data 141 stored in the blockchain 140. For example, a user may submit a document reflecting an updated home address. The submitted document may be verified (e.g., by the verification service 121 using one or more image analysis and / or NLP algorithms or the user). Once verified, the verification service 121 may generate a signature (e.g., a hash value) of the document and / or the updated home address using a verification key 122 associated with the verification service 121 (and / or the entity providing the verification service 121). The user's user data 141 may then be updated to reflect the user's new home address (which may include the document submitted by the user as metadata). The digital signature generated by the verification service 121 may be verified by a recipient of the user data 141 (e.g., the merchant device 130, the verification service 121, etc.) using the corresponding public key to verify the authenticity of the user data 141. Thus, in some embodiments, the merchant device 130 may request and receive verification of the user data 141 without the actual user data 141 being exposed to the merchant device 130 .

[0023] Additionally, as blocks are added to the blockchain 140 for requests to publish and / or verify user data 141, these blocks may be used to process subsequent requests to publish and / or verify user data 141. For example, the verification service 121 may determine, based on blocks in the blockchain 140, that a user has previously published and / or verified a driver's license number to a given vendor. Thus, the verification service 121 may determine that the vendor is trusted by the user and allow subsequent publication and / or verification of the driver's license to the vendor. However, if a previous block in the blockchain 140 does not reflect the publication of the data to the vendor, the verification service 121 may reject the request to publish and / or verify user data 141 to protect the user data 141. In some embodiments, the verification service 121 may enable a user and / or vendor to receive verification of a driver's license number without having to republish the driver's license number based on a previous verification and / or publication.

[0024] User data 141 may include any type of personally identifiable data. Examples of elements of user data 141 include, but are not limited to, the user's name, facial image, home address, email address, national identification number (e.g., Social Security number), passport number, vehicle registration, license plate number, driver's license number, fingerprints, handwriting, credit card number, digital identity, date of birth, place of birth, genetic information, telephone number, login name, screen name, nickname, and password. Thus, any request to reveal and / or verify user data 141 generated by a merchant device 130 may include any number and type of elements of user data 141. For example, a merchant device 130 may request an email address, age, and an image of the user's face. Advantageously, using the techniques described herein, only the email address, age, and an image of the user's face are revealed to the requesting merchant device 130, thereby protecting the security and privacy of the user's other elements of user data 141.

[0025] Similarly, if verification of one or more elements of the user data 141 is requested, the verification service 121 may verify those elements of the user data 141 without exposing the actual user data 141 to the merchant device 130. For example, the merchant device 130 may request verification that a user resides in a particular state, and the verification service 121 may decrypt the user data 141 and determine whether the user's residential address is within the state. In response, the verification service 121 may transmit the results of the verification (e.g., whether the user resides in the state) without exposing the user's address. More generally, the merchant device 130 may request verification that the user data 141 meets one or more criteria (e.g., age criteria, address criteria, etc.). The verification service 121 may then decrypt the user data 141 and compare the decrypted user data 141 to the criteria. For example, if the request specifies to verify that the user is over 18 years old, the verification service 121 may decrypt the user data to determine the user's age and compare the user's age to a standard (e.g., user's age > 18 years old). The verification service 121 may then send the results of the comparison to the merchant device 130.

[0026] The contactless card 101 may be configured to perform key diversification techniques for generating encrypted data and / or digital signatures as described herein. Examples of key diversification techniques are described in U.S. patent application Ser. No. 16 / 205,119, filed Nov. 29, 2018. The aforementioned patent application is hereby incorporated by reference in its entirety.

[0027] The network 111 may be configured to provide communication between the client devices, the merchant device 130, the validation system 120, and the blockchain 140. For example, the network 111 may be any type of network (including infrastructure) that provides communication, exchanges information, and / or facilitates the exchange of information, such as the Internet, a local area network, or other suitable connections that enable the system 100 to send and receive information between components of the system 100.

[0028] FIG. 2A is a schematic 200 illustrating a mobile device 110 executing an account application 113. In general, the account application 113 of the mobile device 110 may communicate with the merchant device 130 to receive data from the merchant device 130 describing the requested user data 141. The account application 113 may then output a graphical user interface (GUI) specifying the data requested by the merchant device 130. As shown, for example, the merchant device 130 requested the user's age and home address. However, in other embodiments, the merchant device 130 may request verification of the user's age and home address (e.g., whether the age exceeds an age threshold and / or whether the home address meets one or more criteria). The account application 113 outputs instructions to the user specifying to tap the contactless card 101 to the merchant device 130 and the mobile device 110 to approve the release of the home address and age.

[0029] As previously described, when tapped to the merchant device 130, the contactless card 101 receives data from the merchant device 130 including the request token, the merchant wallet address 131-1, and the requested data elements (e.g., home address and age). In some embodiments, the merchant device 130 may specify criteria (e.g., age threshold, location criteria, etc.). The selection applet 103 of the contactless card 101 may then determine that the received data is associated with user data 141 based on an analysis of the received data. The selection applet 103 may then select the user data applet 103, which generates the encrypted data and digital signature 107 using the private key 104.

[0030] The user data applet 103 may then transmit the encrypted data, the data received from the merchant device 130, and the digital signature 107 to the mobile device 110 (e.g., via NFC). The account application 113 may then transmit the received data and the user wallet address 131-2 to the verification service 121. In some embodiments, the user wallet address 131-2 is stored in the memory of the contactless card 101 and provided to the mobile device 110 by the applet 103. The verification service 121 may then verify the digital signature 107 using the public key 106 associated with the contactless card 101 and decrypt the encrypted data using the private key 104 of the contactless card 101. The verification service 121 may then select the requested elements of the user data 141 (e.g., age and home address) and generate a block in the blockchain 140 for the requested data. The user data 141 in the generated block may be encrypted to protect the user data 141. In some embodiments, the verification service 121 does not store the requested user data 141 in a block in the blockchain 140. For example, if a request specifies to verify that a user was born in 1980, the verification service 121 may decrypt the user's birth date and determine whether the user's birth date was in 1980. In such an example, the verification service 121 may store an indication of whether the user was born in 1980 in a block in the blockchain.

[0031] 2B is a schematic 210 showing a display 211 of the merchant device 130 outputting the results of the disclosure of the user's age and home address. As shown, the merchant device 130 determines that the user's age has been verified (e.g., if the user is attempting to purchase an age-restricted item, enter an age-restricted establishment, etc.). Advantageously, however, only the requested elements of the user data 141 are disclosed; the remaining user data 141 stored on the blockchain 140 remains secure.

[0032] As noted, in some embodiments, the request from the merchant device 130 may specify to verify the user data 141 without revealing the actual user data 141. FIG. 2C is a schematic diagram 220 illustrating an embodiment in which the merchant device 130 receives verification of the user's age without receiving the user's actual age and receives verification of the user's home address without receiving the user's home address. For example, if the request in FIG. 2A is to determine whether the user can purchase an age-restricted item and the user lives within one of three different states, the verification service 121 may verify the user's age and place of residence in the user data 141 based at least in part on decrypting the encrypted data with the private key 104. For example, the verification service 121 may compare the decrypted user data 141 to one or more criteria and return the results of the comparison.

[0033] As shown, if the decoded age indicates that the user is permitted to purchase age-restricted items (e.g., if the user's age is greater than the age standard), the verification service 121 may send an indication of approval to the merchant device 130 without disclosing the user's actual age. Similarly, if the decoded age indicates that the user is restricted from purchasing age-restricted items (e.g., if the user's age is less than the age standard), the verification service 121 may send an indication specifying that the user does not meet the age requirement without disclosing the user's actual age. Additionally, if the user's address in the decoded user data 141 indicates that the user lives within one of three states, the verification service 121 may send an indication specifying that the user lives within one of three states without disclosing the address. As noted, in such an embodiment, the verification service 121 may store the result of the comparison in the blockchain 140 rather than the actual value of the user data 141.

[0034] FIG. 3 illustrates a logical model 300 of an example blockchain 140 corresponding to disclosed embodiments. The blockchain 140 may comprise many such blockchains maintained by many different systems. Such an example blockchain may comprise blocks, such as blocks 301a-301d. The blocks may include messages, such as messages 307a-307d. In general, the blocks may include headers, such as headers 303a-303d, that uniquely identify each block. The headers 303a-303d may include hash values ​​generated by a hash function. A hash function is any function that may be used to map input data of any size to a hash value of a fixed size. For example, the header may include at least one of a hash value of the previous block, a hash value generated based on any messages in the block (e.g., a Merkle root), and a timestamp. Consistent with disclosed embodiments, the system 100 may require that blocks added to the blockchain 140 satisfy at least one of a proof-of-work condition (e.g., proofs 305a-305d) and a digital signature condition. For example, the headers 303a-303d may include a nonce selected to ensure that the header satisfies a proof-of-work condition. As a non-limiting example, the proof-of-work condition may require that the hash of the header be within a predetermined range of values. As an additional example, the header may be digitally signed with an approved system cryptographic key (e.g., private key 104, transaction key 105, verification key 122, and / or merchant key 132), and the digital signature may be included in the header. This digital signature may be verified using a key available to members of the system 100. In general, one or more designated components of the system 100 (e.g., blockchain 140, etc.) may generate a block 302 that includes a header 303, a proof 305, and a message 307 of user data 141 stored in the blockchain 140.

[0035] FIG. 4 illustrates a logical model of message 307b stored in blockchain 140 in accordance with disclosed embodiments. In some embodiments, a designated component of system 100 (e.g., blockchain 140, etc.) generates a blockchain message, such as message 307b. In some embodiments, message 307b may comprise index information 403. In certain embodiments, index information 403 may comprise information identifying a user. For example, index information 403 may be at least one of a full name, email address, phone number, or other non-sensitive personal information of a user. In certain embodiments, index information 403 includes one or more elements of user data 141. In various embodiments, index information 403 may include one or more references to a previous block in blockchain 140. For example, index information 403 may include one or more references to one or more previous blocks associated with the same user. The references may include, as a non-limiting example, a hash of a preceding block in the blockchain associated with the same user. In some embodiments, index information 403 may be obfuscated or encrypted according to methods known to those of skill in the art. For example, the index information 403 may be encrypted with an encryption key. As an additional example, the index information 403 may comprise a hash of at least one of the full name, email address, phone number, or other non-sensitive personal information of the user.

[0036] The message 307b may comprise user data 141, consistent with disclosed embodiments. In various embodiments, the user data 141 may be stored as part of the index information 403 and / or stored separately from the index information 403. In some embodiments, the user data 141 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, the user data 141 may be encrypted with an encryption key (e.g., the private key 104 and / or the transaction key 105 of the contactless card 101, the merchant key 132 of the merchant device 130, and / or the verification key 122 of the verification system 120). The message 307b may further include a merchant wallet address 131-1, a user wallet address 131-2, and / or a public key 106. In various embodiments, the wallet address 131-1, the user wallet address 131-2, and / or the public key 106 may be stored as part of the index information 403 and / or stored separately from the index information 403.

[0037] The message 307b may comprise a user data result 404, consistent with disclosed embodiments. In general, the user data result 404 may include the result of a comparison of the user data 141 against one or more criteria by the verification service 121 and / or the blockchain 140. For example, if the merchant device 130 requests verification that the user is at least 21 years old, the user data result 404 reflects whether the user is at least 21 years old. In some embodiments, the message 307b including the user data 404 may not include the actual user data 141 (e.g., the user's age). In some embodiments, the user data result 404 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, the user data result 404 may be encrypted with an encryption key (e.g., the private key 104 and / or the transaction key 105 of the contactless card 101, the merchant key 132 of the merchant device 130, and / or the verification key 122 of the verification system 120). In various embodiments, the user data results 404 may be stored as part of the index information 403 and / or may be stored separately from the index information 403 .

[0038] Message 307b may comprise an authentication record 407, corresponding to disclosed embodiments. In some embodiments, authentication record 407 may comprise information enabling a subsequent audit of the transaction. For example, authentication record 407 may identify at least one of verification system 120, a commercial institution associated with verification system 120, a purpose of the authentication request (e.g., to reveal and / or verify elements of user data 141), a result of the authentication request (e.g., which elements of user data 141 were revealed and / or verified), and information related to the authentication request. In some embodiments, the purpose of the authentication request may include the creation of a relationship with the commercial institution associated with verification system 120 (e.g., a financial relationship such as a bank account, brokerage account, credit card account, and / or loan account) or the performance of a service by verification system 120 (e.g., revealing and / or verifying user data 141 to merchant device 130, performing a transaction on a financial account associated with the user, cashing a check provided by the user, and / or selling a cashier's check to the user). As will be appreciated by those skilled in the art, the above exemplary authentication objectives are not intended to be limiting. In some embodiments, the result of the authentication request may include whether the objective of the authentication request was accomplished. For example, if the objective of the authentication request was to create a relationship, the result of the authentication request may indicate whether the relationship was created. As another example, if the objective of the authentication request was to expose and / or verify one or more elements of user data 141, the result of the authentication request may indicate whether the elements of user data 141 were exposed and / or verified. As will be appreciated by those skilled in the art, the above exemplary authentication results are not intended to be limiting. In some embodiments, information associated with the authentication request may include additional contact information, demographic information, financial information, or similar personal information provided in connection with the authentication request. In some embodiments, such information may simply indicate that such information was provided and / or provide a location where such information may be obtained.In some embodiments, the authentication record 407 may be obfuscated or encrypted according to methods known to those of skill in the art. For example, the authentication record 407 may be encrypted with an encryption key.

[0039] The encryption keys may be used to encrypt elements of the message in the block, consistent with disclosed embodiments. In some embodiments, such encryption keys may be associated with members of the system 100 (e.g., the verification system 120, the contactless card 101, the mobile device 110, the merchant device 130, etc.). In various embodiments, at least some of the encryption keys may be associated with authorized systems. Consistent with disclosed embodiments, corresponding encryption keys may be available to decrypt the encrypted message elements. For example, if an element of a message in a block is encrypted with a symmetric key, the same symmetric key may be used to decrypt the encrypted elements. As another example, if an element of a message in a block is encrypted with a private key, the corresponding public key may be used to decrypt the encrypted elements. In some embodiments, the corresponding encryption keys may be available to members of the authentication system (e.g., the verification system 120, the contactless card 101, the mobile device 110, the merchant device 130, etc.). As mentioned, such encryption keys may be used to store user data 141 on the blockchain 140, to publish and / or verify user data 141 stored on the blockchain 140, and to create records reflecting the publication and / or verification of user data 141 stored on the blockchain 140.

[0040] 5 illustrates an embodiment of a logic flow 500. The logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 500 may represent some or all of the operations for using a contactless card 101 to securely share user data 141 stored in a blockchain 140. In this context, the embodiments are not limited.

[0041] As shown, the logic flow 500 begins at block 505 where the user data 141 is stored in the blockchain 140 and / or a cloud-based database. In some embodiments, the cloud-based database that stores the user data 141 is a component of the blockchain 140. In general, the user data 141 may be encrypted and stored in any suitable data storage entity (e.g., a database, a file, one or more blocks of the blockchain 140, etc.). One or more elements of the user data 141 may be signed by the verification service 121 (e.g., generating a digital signature using a private key of an entity associated with the verification service 121). At block 510, the user may access the account application 113 on the mobile device 110 and provide valid authentication credentials (e.g., username / password, fingerprint, etc.). At block 515, the merchant device 130 outputs instructions specifying tapping the contactless card 101 to the merchant device 130 as part of a request to receive one or more elements of the user data 141. For example, the merchant device 130 may be associated with a mass transit system and may need to verify the user's name, address, date of birth, and identification number in order to allow the user to travel on the mass transit system. As another example, the request may specify to verify the user data 141 according to one or more criteria.

[0042] At block 520, the contactless card 101 is tapped to the merchant device 130 and receives data from the merchant device 130. The data may include the request token, the requested data elements (e.g., name, address, date of birth, identification number), and the merchant's wallet address 131-1. At block 525, the selection applet 103 selects a user data applet 103 and a private key 104 based on the type of data received at block 520. For example, by parsing the data received from the merchant device 130, the applet 103 may determine that user data 141 is being requested. The user data applet 103 may then generate encrypted data and a digital signature 107 using the private key 104. At block 530, the contactless card 101 transmits the encrypted data and digital signature 107 to the mobile device 110.

[0043] At block 535, the account application 113 of the mobile device 110 sends the wallet address 131-2 and the data received from the contactless card 101 to the verification service 121. At block 540, the verification service 121 verifies the request to verify the user data 141. For example, the verification service 121 may use the contactless card's public key 106 to decrypt the digital signature 107. Additionally, the verification service 121 may use a copy of the private key 104 stored in the memory of the verification system 120 to decrypt the encrypted data generated by the contactless card 101. At block 545, the verification service 121 and / or the blockchain 140 obtain the requested user data 141 (e.g., name, address, date of birth, identification number). In some embodiments, the verification service 121 and / or the blockchain 140 may verify the user data according to another criterion. For example, the verification service 121 and / or the blockchain 140 may determine whether the age is above a threshold, whether the user lives in one or more locations, etc.

[0044] At block 550, a block in the blockchain 140 is generated to reflect the release of the requested user data 141 from the user's wallet address 131-2 to the merchant's address 131-1. As noted, a third party may view the transaction details, but the actual user data 141 remains encrypted in the block in the blockchain 140. As noted, in a verification embodiment, the verification service 121 and / or the blockchain 140 may store the result of the comparison of the user data 141 to a criteria (e.g., the user is at least as old as a specified age) as the user data result 404. At block 555, the merchant device 130 reads the block in the blockchain 140 generated at block 550. The merchant device 130 may then decrypt the encrypted data using the merchant's merchant key 132. Once decrypted, the data may be analyzed by the merchant device 130 and / or the user. For example, the merchant device 130 may determine that the decrypted user data 141 (e.g., name, address, date of birth, identification number) matches the corresponding data on the user's mass transit ticket. The user may then be permitted to board the mass transit vehicle. As another example, the block may specify the results of a required comparison. In such an example, the merchant device 130 determines the results of a comparison of the user data against criteria from the user data results 404 of the blockchain 140.

[0045] 6 illustrates an embodiment of a logic flow 600. The logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations performed by the validation service 121 to expose the user data 141 to a requesting merchant device 130. In this context, the embodiments are not limited.

[0046] As shown, logic flow 600 begins at block 610, where verification service 121 receives data generated by contactless card 101 (e.g., digital signature 107 and encrypted data). At block 620, verification service 121 decrypts digital signature 107 using public key 106 and a signature verification algorithm to verify that the request to reveal user data 141 originated from contactless card 101. Similarly, verification service 121 may decrypt the encrypted data using private key 104 to verify that the request to reveal user data 141 originated from contactless card 101.

[0047] At block 630, the verification service 121 may receive a digital signature associated with the requested element of the user data 141 stored on the blockchain 140. As mentioned, the entity providing the verification service 121 may sign each element of the user data 141 with a corresponding digital signature to verify its authenticity. At block 640, the verification service 121 may verify the digital signature associated with the requested element of the user data 141 stored on the blockchain 140. For example, the digital signature may be decrypted using the corresponding public key to verify the digital signature and, for example, verify the requested data before providing the data to the merchant device 130. At block 650, the verification service 121 determines the data associated with the request. For example, the verification service 121 may extract the request token, the requested element of the user data 141, the account and / or user identifier, and the merchant wallet address 131-1 from the decrypted data generated by the contactless card 101. In one embodiment, the verification service 121 may receive the requested element of the user data 141 (e.g., an image of the user's face) from the blockchain 140. In other embodiments, the validation service 121 indicates sufficient of the requested data element (e.g., a URL, storage location, description, etc.) to enable a component of the blockchain 140 to receive the requested data element from the user data 141.

[0048] At block 660, the validation service 121 provides the requested data to the blockchain 140 for generation of a block. The blockchain 140 may generate a block including the requested (but encrypted) user data 141. As noted, in some embodiments, the validation service 121 provides the requested user data 141. In other embodiments, the blockchain 140 retrieves the user data 141 based on information received from the validation service 121 (e.g., by accessing data at a specified URL, by selecting a record of data associated with the user from a database, etc.). In some embodiments, the validation service 121 does not provide the user data 141 to the merchant device 130. Instead, the validation service 121 may validate the user data 141 and transmit the results of the validation to the merchant device 130.

[0049] 7 illustrates an embodiment of a logic flow 700. The logic flow 700 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 700 may represent one or more operations for storing user data 141 in the blockchain 140. In this context, the embodiments are not limited.

[0050] As shown, logic flow 700 begins at block 710, where user data describing a user is received. The user data may be received from any source, such as an account application 113, a web service, a paper form, etc. At block 720, the received user data is verified. For example, verification service 121 may perform image processing on the image of the user to determine whether a face depicted in the image matches other known images of the user. As another example, an employee of the entity providing verification service 121 may verify the user data. At block 730, verification service 121 generates a digital signature of the verified user data, for example, using a private key associated with verification service 121. At block 740, the verified data and the digital signature are stored as user data 141. For example, a database of user data 141 may be updated to reflect the addition of the verified and signed user data. As another example, one or more blocks including the digital signature and an encrypted version of the user data may be added to blockchain 140. Doing so allows the contactless card 101 to be used to securely and selectively reveal stored user data 141 as described herein.

[0051] FIG. 8 illustrates an embodiment of an exemplary computing architecture 800 comprising a computing system 802 suitable for implementing the various embodiments described above. In various embodiments, the computing architecture 800 may be configured or implemented as part of an electronic device. In some embodiments, the computing architecture 800 may represent, for example, a system implementing one or more components of the system 100. In some embodiments, the computing system 802 may represent, for example, the mobile device 110, the merchant device 130, the verification system 120, the blockchain 140 of the system 100. The embodiments are not limited in this context. More generally, the computing architecture 800 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-7.

[0052] The terms "system," "component," and "module" as used in this application are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. As an example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and a component may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to one another by various types of communication media to coordinate operations. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. The information may be embodied as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. Such data messages may be transmitted over a variety of connections, examples of which include parallel interfaces, serial interfaces, and bus interfaces.

[0053] Computing system 802 includes various typical computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by computing system 802.

[0054] As shown in Figure 8, computing system 802 includes a processor 804, a system memory 806, and a system bus 808. Processor 804 may be any of a variety of commercially available computer processors, including, but not limited to, AMD Athlon, Duron, and Opteron processors, ARM applications, embedded and secure processors, IBM and Motorola DragonBall and PowerPC processors, IBM and Sony Cell processors, Intel Celeron, Core, Core(2) Duo, Itanium, Pentium, Xeon, and XScale processors and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processor 804.

[0055] The system bus 808 provides an interface from the system memory 806 to system components including, but not limited to, the processor 804. The system bus 808 may be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may connect to the system bus 808 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Enhanced) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Enhanced) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0056] The system memory 806 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 8, the system memory 806 may include non-volatile memory 810 and / or volatile memory 812. The non-volatile memory 810 may store a basic input / output system (BIOS).

[0057] The computing system 802 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 814, a magnetic floppy disk drive (FDD) 816 that reads from or writes to a removable magnetic disk 818, and an optical disk drive 820 that reads from or writes to a removable optical disk 822 (e.g., a CD-ROM or DVD). The HDD 814, FDD 816, and optical disk drive 820 may be connected to the system bus 808 by a HDD interface 824, a FDD interface 826, and an optical drive interface 828, respectively. The HDD interface 824 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 802 is generally configured to implement all of the logic, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-5.

[0058] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, and the like. For example, a number of program modules may be stored on the drives and memory units 810, 812, including an operating system 830, one or more application programs 832, other program modules 834, and program data 836. In one embodiment, the one or more application programs 832, other program modules 834, and program data 836 may include, for example, various applications and / or components of system 100, such as account application 113, verification service 121, blockchain 140, and / or user data 141.

[0059] A user may enter commands and information into the computing system 802 through one or more wired / wireless input devices, for example, a keyboard 838 and a pointing device such as a mouse 840. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, grab, graphic tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), track ball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 804 through an input device interface 842 coupled to the system bus 808, but may be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0060] A monitor 844 or other type of display device is also connected to the system bus 808 via an interface, such as a video adapter 846. The monitor 844 can be internal or external to the computing system 802. In addition to the monitor 844, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0061] The computing system 802 may operate in a networked environment using logical connections via wired and / or wireless communication to one or more remote computers, such as a remote computer 848. The remote computer 848 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and typically includes many or all of the elements described in connection with the computing system 802, although for simplicity, only a memory / storage device 850 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 852 and / or larger networks, e.g., a wide area network (WAN) 854. Such LAN and WAN networking environments are common in offices and businesses, facilitating enterprise-wide computer networks, such as an intranet. All of these may connect to a global communications network, e.g., the Internet. In an embodiment, the network 111 of FIG. 1 is one or more of the LAN 852 and the WAN 854.

[0062] When used in a LAN networking environment, the computing system 802 is connected to the LAN 852 via a wired and / or wireless communication network interface or adapter 856. The adapter 856 may facilitate wired and / or wireless communication to the LAN 852, which may include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 856.

[0063] When used in a WAN networking environment, the computing system 802 may include a modem 858 or have other means for establishing communications over the WAN 854, such as connected to a communications server on the WAN 854 or via the Internet. The modem 858 may be internal or external, a wired and / or wireless device, and connects to the system bus 808 via the input device interface 842. In a networked environment, program modules depicted relative to the computing system 802, or portions thereof, may be stored in the remote memory / storage device 850. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0064] The computing system 802 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.16 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth wireless technologies, and the like. Thus, communication can be a predefined structure, as with traditional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and fast wireless connectivity using radio technologies called IEEE 802.11x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0065] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as required computational speed, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints.

[0066] One or more embodiments of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic in a processor, and when read by a machine, the machine manufactures logic that performs the techniques described herein. Such representations, known as "IP cores," are stored on tangible machine-readable media and provided to various customers or manufacturing facilities for loading into manufacturing machines that create the logic or processors. Some embodiments may be implemented using a machine-readable medium or article that may store, for example, instructions or sets of instructions that, when executed by the machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such machines may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile disks (DVDs), tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0067] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but by the appended claims. Future applications claiming priority to this application may claim the disclosed subject matter in a different manner and may generally include any set of one or more limitations as variously disclosed or demonstrated herein.

Claims

1. a verification service executing on a server receiving from a mobile device a digital signature, an encrypted request to verify a user data element to a merchant wallet address based on criteria, and the user wallet address, wherein an applet on a contactless card generates the digital signature based on a private key of the contactless card, and the applet generates the encrypted request based on a first request received from a merchant device as part of a transaction; the verification service verifying the digital signature based on a public key associated with the private key of the contactless card; the validation service decrypting the encrypted request using the private key; said validation service receiving said user data elements; said validation service validating said user data elements based on said criteria; a node of a blockchain, in response to a second request received from the validation service, generating a block in the blockchain corresponding to the first request, the block including instructions for the validation of the digital signature, instructions for the validation of the user data element based on the criteria, the public key, the merchant wallet address, and the user wallet address; The method includes:

2. 2. The method of claim 1 , wherein the block in the blockchain further includes an indication of a request token associated with the first request, and wherein the user data element is one of a plurality of user data elements, each user data element corresponding to one or more personally identifiable attributes.

3. 3. The method of claim 2, wherein the personally identifiable attributes include: (i) age, (ii) name, (iii) address, (iv) identification number, (v) one or more biometric identifiers, (vi) one or more account numbers, and (vii) email address.

4. The method comprises: the validation service identifying a plurality of blocks of the blockchain associated with a plurality of prior requests, the plurality of prior requests being validated and satisfied to provide a user data element for a user; The method of claim 1 further comprising:

5. Validating the user data element comprises: comparing said user data elements to said criteria; determining that the user data element satisfies the criteria; and The method of claim 1 , comprising:

6. The method comprises: said merchant device reading said block of said blockchain; said merchant device identifying said indication of said validation of said user data element; the merchant device authorizing the transaction based on the indication of verification of the user data element; The method of claim 1 further comprising:

7. The user wallet address is encrypted upon receipt with the request, the method comprising: the validation service decrypting the encrypted user wallet address based on the private key; The method of claim 1 further comprising:

8. The method of claim 1 , wherein verifying the digital signature includes the verification service decrypting the digital signature based on the public key, the digital signature including a hash value.

9. 1. A computer-readable storage medium containing instructions that, when executed by a processor, cause the processor to: receiving from a mobile device a digital signature, an encrypted request to validate a user data element to a merchant wallet address based on criteria, and the user wallet address, wherein an applet of a contactless card generates the digital signature based on a private key of the contactless card, and the applet generates the encrypted request based on a first request received from a merchant device as part of a transaction; verifying the digital signature based on a public key associated with the private key of the contactless card; decrypting the encrypted request using the private key; receiving said user data element; validating said user data elements based on said criteria; generating a block on a blockchain corresponding to the first request to verify the user data element, the block including instructions for the verification of the digital signature, instructions for the verification of the user data element based on the criteria, the public key, the merchant wallet address, and the user wallet address; A computer-readable storage medium for causing the computer to execute the method.

10. 10. The computer-readable storage medium of claim 9, wherein the block in the blockchain further includes an indication of a request token associated with the first request, and the user data element is one of a plurality of user data elements, each user data element corresponding to one or more personally identifiable attributes.

11. 11. The computer-readable storage medium of claim 10, wherein the personally identifiable attributes include: (i) age, (ii) name, (iii) address, (iv) identification number, (v) one or more biometric identifiers, (vi) one or more account numbers, and (vii) email address.

12. The instructions cause the processor to: identifying a plurality of blocks of the blockchain associated with a plurality of prior requests, the plurality of prior requests being verified and satisfied to provide a user data element for a user; The computer-readable storage medium of claim 9 , further comprising:

13. The instructions for validating the user data element include instructions to the processor: comparing said user data elements to said criteria; determining that the user data element satisfies the criteria; and 10. The computer-readable storage medium of claim 9, further comprising:

14. The user wallet address is encrypted upon receipt with the request, and the instructions cause the processor to: Decrypting the encrypted user wallet address based on the private key; The computer-readable storage medium of claim 9 , further comprising:

15. 10. The computer-readable storage medium of claim 9, wherein the verifying of the digital signature includes decrypting the digital signature based on the public key, the digital signature including a hash value.

16. 1. A computing device comprising: A processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving from a mobile device a digital signature, an encrypted request to validate a user data element to a merchant wallet address based on criteria, and the user wallet address, wherein an applet of a contactless card generates the digital signature based on a private key of the contactless card, and the applet generates the encrypted request based on a first request received from a merchant device as part of a transaction; verifying the digital signature based on a public key associated with the private key of the contactless card; decrypting the encrypted request using the private key; receiving said user data element; validating said user data elements based on said criteria; generating a block on a blockchain corresponding to the first request to verify the user data element, the block including instructions for the verification of the digital signature, instructions for the verification of the user data element based on the criteria, the public key, the merchant wallet address, and the user wallet address; A computing device that executes the following:

17. 17. The computing device of claim 16, wherein the block in the blockchain further includes an indication of a request token associated with the first request, and the user data element is one of a plurality of user data elements, each user data element corresponding to one or more personally identifiable attributes.

18. 20. The computing device of claim 17, wherein the personally identifiable attributes include: (i) age, (ii) name, (iii) address, (iv) identification number, (v) one or more biometric identifiers, (vi) one or more account numbers, and (vii) email address.

19. The instructions cause the processor to: identifying a plurality of blocks of the blockchain associated with a plurality of prior requests, the plurality of prior requests being verified and satisfied to provide a user data element for a user; The computing device of claim 16 , further configured to perform the steps of:

20. The instructions for validating the user data element include instructions to the processor: comparing said user data elements to said criteria; determining that the user data element satisfies the criteria; and 20. The computing device of claim 16, configured to execute:

21. The user wallet address is encrypted upon receipt with the request, and the instructions cause the processor to: Decrypting the encrypted user wallet address based on the private key; The computing device of claim 16 , further configured to perform the steps of:

22. 17. The computing device of claim 16, wherein the verifying of the digital signature includes decrypting the digital signature based on the public key, the digital signature including a hash value.

Images