Using contactless card to securely share personal data stored in blockchain

Abstract

To provide a system and method for securely sharing personal data stored in a blockchain.SOLUTION: In a system 100, a contactless card may receive a request to provide a data element from each device. An applet of the contactless card may encrypt the data element and a wallet address, generate a signature for the request, and transmit, to a mobile device, the signature and the encrypted data. The mobile device may transmit, to a verification service, the signature and encrypted data. The verification service may verify the signature based on a public key. A node in a blockchain may generate a block in the blockchain, the block comprising indications of the verification of the signature, the requested data element, and the wallet address. An encrypted data element corresponding to the data element may be decrypted using a public key. Each device may receive the decrypted data element from the wallet address.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Related Applications This application claims the benefit of priority of U.S. Patent Application No. 16 / 359,980, entitled "Use of Contactless Cards to Securely Share Personal Data Stored on a Blockchain," filed on Mar. 20, 2019. The entire content of the foregoing application is incorporated herein by reference in its entirety.

[0002] Embodiments herein generally relate to sharing of data, and more specifically, to using contactless cards to securely share personal data stored on a blockchain.

Background Art

[0003] Users often need to share personal data with merchants, government officials, and other entities. However, using conventional methods, more personal data than necessary is often disclosed. For example, when purchasing an age-restricted item, only the person's age needs to be presented. However, scanning a driver's license at the time of sale can disclose additional data such as the person's name, address, driver's license number, etc.

Summary of the Invention

[0004] The embodiments disclosed herein provide a system, method, article of manufacture, and computer-readable medium for using a contactless card to securely share personal data stored on a blockchain. In one example, a communication interface of the contactless card may receive, from a card reader of a merchant device, a request to provide user data elements to a wallet address associated with the merchant. An applet executed within the memory of the contactless card may encrypt the user data elements and an indication of the wallet address based on a secret key stored in the memory of the contactless card. The applet may generate a digital signature for the request based on the secret key and transmit, by the communication interface of the contactless card, the digital signature and the encrypted indication of the user data elements and the wallet address to a card reader of a mobile device. The mobile device may transmit the digital signature and the encrypted indication of the user data elements and the wallet address to a verification service. The verification service may verify the digital signature based on a public key associated with the secret key of the contactless card. A node within the blockchain may generate a block within the blockchain corresponding to the request in response to verification by the verification service, the block comprising the digital signature, the requested data elements, and an indication of verification of the wallet address associated with the merchant. The encrypted data elements corresponding to the user data elements may be decrypted using the public key. The merchant's device may receive the data elements decrypted from the wallet address associated with the merchant to fulfill the request.

Brief Description of the Drawings

[0005]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Best Mode for Carrying Out the Invention

[0006] The embodiments disclosed in this specification provide a technique for securely disclosing personal data stored in a blockchain using a contactless card. Generally, a merchant device may store data that describes one or more elements of personal data requested from a user. For example, the merchant device may request that the user provide a name and date of birth. In response, the user may tap a contactless card on the merchant device and receive data (e.g., name and date of birth) that describes the requested elements of the user data. An applet executed 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 to disclose and / or verify the requested data to a wallet address associated with the merchant. Next, the applet may send the signed encrypted payload to the user's mobile device. Next, the user's mobile device may send the received data to a verification service via a network (e.g., the Internet). The verification service may store a corresponding instance of the private key and decrypt the encrypted data using the stored private key. The verification service may further verify the digital signature received from the mobile device. To reflect the requested transaction, a block may be added to the blockchain (e.g., disclosure of name and date of birth). Next, the merchant device may receive data from the blockchain, decrypt the data using the corresponding key, and thereby disclose the requested data to the merchant device without disclosing additional data of the user.

[0007] As an advantage, the embodiments disclosed in this specification utilize a contactless card to disclose and / or verify personal information stored in a blockchain. The embodiments disclosed in this specification provide a fast, efficient, and secure technique for disclosing and / or verifying one or more specific data elements as needed, rather than disclosing all personal information. By doing so, the security of personal data is improved, and user data can be processed more efficiently by requesting the device.

[0008] Referring generally to the notations and nomenclatures used in this specification, one or more portions of the following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The descriptions and representations of these procedures are used by those skilled in the art to most effectively convey the substance of their work to those skilled in the art. The procedures are herein, generally considered to be a self-consistent series of operations leading to a desired result. These operations are those that require physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. For mainly reasons of common usage, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numerical values, etc. However, it should be noted that all of these and similar terms are merely convenient labels associated with appropriate physical quantities and nothing more than that.

[0009] Furthermore, these operations are often referred to in terms such as addition or comparison, which are generally associated with intellectual operations performed by a human operator. However, in any of the operations described in this specification that form part of one or more embodiments, such capabilities of a human operator are not necessary or, in most cases, desirable. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings of this specification, and / or special-purpose devices or digital computers constructed for the required purposes. The various embodiments also relate to devices or systems for performing these operations. These devices may be specially constructed for the required purposes. The structures required for these various machines will become apparent from the given description.

[0010] Reference is now made to the drawings, where like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. It will be evident, however, that the novel embodiments can 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 shows a schematic diagram of an exemplary system 100 corresponding to the disclosed embodiments. As shown, 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 cards 101 represent any type of payment card such as credit cards, debit cards, ATM cards, gift cards, etc. The contactless cards 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 devices 110 via near field communication (NFC), EMV standards, 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 standards, Bluetooth®, and / or Wi-Fi. The mobile devices 110 represent any type of network-enabled computing device such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, and the like.

[0012] Merchant device 130 represents any type of device configured to communicate with a payment card, such as a payment terminal, card reader, mobile device, computing device, etc. Merchant device 130 is associated with merchant wallet addresses 131-1 and one or more encrypted merchant keys 132. Generally, merchant device 130 can 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) can 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 memory 102 of the contactless card includes one or more applets 103, a private key 104, a transaction key 105, a public key 106, and a digital signature 107. The applet 103 can be executed on a processor (not shown) of the contactless card 101 and represents executable code configured to perform any number and type of operations. For example, the applet 103 can include a first applet 103 (referred to herein as the "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 can select a second applet 103 (referred to herein as the "transaction applet") that processes the transaction using the contactless card 101. In such an embodiment, the transaction applet 103 can select the transaction key 105 and generate encrypted data for processing the transaction. The transaction can be posted to a first instance of a blockchain 140 that is the blockchain of the transaction. As another example, when processing a request to provide user data 141 stored in the blockchain 140, the selection applet 103 can select a third applet 103 (referred to herein as the "user data applet") that processes the request to provide the user data 141. In such an embodiment, the user data applet 103 can select the private key 104 and process the request to provide the user data 141. Such a transaction can be posted to a second instance of the blockchain 140 that is the blockchain for storing the user data 141.

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

[0015] For example, a user associated with the contactless card 101 may attempt to purchase an age-restricted item from a merchant. The merchant's merchant device 130 may require verification of the user's age before permitting the user to purchase the item. The user may tap the contactless card 101 on the merchant device 130, thereby bringing the contactless card 101 sufficiently close 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 send request data including at least one or more requested elements of the merchant wallet address 131-1, a request token (not shown) identifying the request, and the user data 141 (e.g., at least the customer's age). The elements of the user data may be the user data 141 stored in the blockchain 140. In some embodiments, the user data 141 is stored in a cloud-based database. However, the present disclosure is applicable to any type of data storage technology.

[0016] In some embodiments, the merchant device 130 may initiate a request to receive and / or verify user data 141. In other embodiments, the mobile device 110 may initiate a transaction to provide and / or verify user data 141. Since 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, the specific entity that initiates the communication should not be considered to limit the disclosure.

[0017] In response to receiving a disclosure and / or verification request from the merchant device 130, the selected applet 103 may determine that the type of request is associated with a request to provide user data 141. Accordingly, the selected applet 103 may select the user data applet 103 and provide the received data to the user data applet 103. Next, the user data applet 103 may select the private key 104 and generate encrypted data that is 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 the indication of the requested data elements. In some embodiments, additional data elements may be encrypted using the private key 104 such as the account identifier of the contactless card 101, the identifier of the user, etc. Further, the user data applet 103 may generate a digital signature 107 using the private key 104 and the encryption function. The digital signature 107 is used to confirm that the user has approved the release of the requested user data 141 from the blockchain 140.

[0018] Next, in response to a tap of the contactless card 101 on the mobile device 110, the user data applet 103 may send encrypted data (including the digital signature 107) to the account application 113 of the mobile device 110. The user may tap the contactless card 101 on 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 enables the user to perform various account-related operations such as displaying the account balance, processing payments, and publishing user data 141. In some embodiments, the user must authenticate using authentication credentials to access the account application 113. For example, the authentication credentials may include a username and password, biometric identifiers (e.g., fingerprint, iris scan, etc.). The mobile device 110 is generally under the control of an operating system (not shown). Examples of operating systems include the Android (registered trademark) OS, iOS (registered trademark), macOS (registered trademark), Linux (registered trademark), and Windows (registered trademark) operating systems.

[0019] Next, the account application 113 may send the data received from the wallet address 131-2 and the contactless card 101 associated with the user to the verification service 121 of one or more verification systems 120. Next, the verification service 121 may verify the digital signature 107 using the key from the 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 a signature verification algorithm to verify the digital signature 107. Further, the verification service 121 may decrypt the 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 contains an expected value (e.g., a customer identifier, an account identifier, etc.) before publishing the requested data. Thus, for example, if the verification service 121 cannot verify the digital signature 107 and / or cannot decrypt the encrypted data, the verification service 121 may refrain from publishing the requested data.

[0020] When the digital signature 107 is verified and / or the encrypted data generated by the contactless card 101 is decrypted, the verification service 121 may cause the computing node to generate a block in the blockchain 140 that reflects the disclosure of the requested user data 141. For example, the block in the blockchain 140 may include the wallet address 131-2 of the user (or other users and / or account identifiers), the merchant wallet address 131-1, the request token, the public key 106, and an encrypted instruction of the associated user data 141 (e.g., the age of the user in the previous example). When posted to the blockchain 140, the merchant device 130 may decrypt the data in the blockchain 140 (e.g., using the key 132 and / or the 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 age of the user. In some embodiments, the merchant device 130 may verify the digital signature 107 using the public key 106. Next, the merchant device 130 may determine the age of the user. If the determined age exceeds the age limit of the product, the merchant device 130 may permit 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 verification without receiving the actual user data 141. Instead, in such embodiments, the 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 send the result to the merchant device 130. For example, the verification service 120 may determine whether the age of the user exceeds the age limit of the product. Next, the verification service 121 may send 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 permit the purchase based on the received result without the actual age of the user being disclosed to the merchant device 130.

[0022] Furthermore, the verification service 121 may be configured to manage and verify 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 one or more image analysis and / or NLP algorithms or the verification service 121 using 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). Next, the user's user data 141 may 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 the recipient of the user data 141 (e.g., the merchant device 130, the verification service 121, etc.) using the corresponding public key, and the reliability of the user data 141 may be verified. Thus, in some embodiments, the merchant device 130 may request verification of the user data 141 and receive verification of the user data 141 without the actual user data 141 being disclosed to the merchant device 130.

[0023] Furthermore, since the blocks are added to the blockchain 140 for requests to publish and / or verify user data 141, these blocks can be used to process subsequent requests to publish and / or verify user data 141. For example, the verification service 121 can determine, based on the blocks within the blockchain 140, that the user has previously published and / or verified their driver's license number to a given merchant. Thus, the verification service 121 can determine that the merchant is trusted by the user and permit subsequent publication and / or verification of the driver's license to the merchant. However, if previous blocks within the blockchain 140 do not reflect the publication of data to the merchant, the verification service 121 can reject requests to publish and / or verify user data 141 to protect the user data 141. In some embodiments, the verification service 121 can enable the user and / or merchant to receive verification of the driver's license number without the need to republish the driver's license number based on previous verifications and / or publications.

[0024] User data 141 can include data that can identify any type of individual. Examples of elements of user data 141 include, but are not limited to, the user's name, image of the face, home address, email address, national identification number (e.g., social security number), passport number, vehicle registration, license plate number, driver's license number, fingerprint, handwriting, credit card number, digital identity, date of birth, place of birth, genetic information, phone number, login name, screen name, nickname, and password. Thus, any request to publish and / or verify user data 141 generated by the merchant device 130 can include any number and type of elements of user data 141. For example, the merchant device 130 can 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 image of the user's face are published to the requesting merchant device 130, thereby protecting the security and privacy of other elements of the user's user data 141.

[0025] Similarly, when verification of one or more elements of user data 141 is requested, the verification service 121 can verify those elements of the user data 141 without disclosing the actual user data 141 to the merchant device 130. For example, the merchant device 130 may request verification that the user resides in a particular state, and the verification service 121 can decrypt the user data 141 and determine whether the user's residential address is within the state. In response, the verification service 121 can send the result of the verification (e.g., whether the user resides in the state) without disclosing 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., an age criterion, an address criterion, etc.). Next, the verification service 121 can decrypt the user data 141 and compare the decrypted user data 141 against the criteria. For example, if the request specifies verifying that the user is 18 years of age or older, the verification service 121 can decrypt the user data to determine the user's age and compare the user's age against the criterion (e.g., user's age > 18 years). Next, the verification service 121 can send the result of the comparison to the merchant device 130.

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

[0027] Network 111 may be configured to provide communication between the client device, the merchant device 130, the verification system 120, and the blockchain 140. For example, 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 connection that enables system 100 to send and receive information between components of system 100.

[0028] FIG. 2A is a schematic 200 showing a mobile device 110 executing an account application 113. Generally, the account application 113 of the mobile device 110 may communicate with the merchant device 130 to receive data from the merchant device 130 that describes the requested user data 141. Next, the account application 113 may output a graphical user interface (GUI) that specifies 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 an instruction to the user to tap the contactless card 101 on the merchant device 130 and the mobile device 110 to approve the release of the home address and age.

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

[0030] Next, the user data applet 103 may send 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). Next, the account application 113 may send 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. Next, the verification service 121 may verify the digital signature 107 using the public key 106 associated with the contactless card 101 and decrypt the encrypted data using the secret key 104 of the contactless card 101. Next, the verification service 121 may select the requested elements of the user data 141 (e.g., age and home address) and generate a block within the blockchain 140 for the requested data. The user data 141 within 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 within the blockchain 140. For example, if the request specifies verifying that the user was born in 1980, the verification service 121 may decrypt the user's date of birth and determine whether the user's date of birth was 1980. In such an example, the verification service 121 may store an indication of whether the user was born in 1980 in a block of the blockchain.

[0031] FIG. 2B is a schematic 210 showing the display 211 of the merchant device 130 that outputs the public result 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., when the user attempts to purchase an age-restricted item, enter an age-restricted facility, etc.). Advantageously, however, only the requested elements of the user data 141 are disclosed, and the remaining user data 141 stored in the blockchain 140 remains secure.

[0032] As described above, in some embodiments, requests from the merchant device 130 may specify to verify the user data 141 without disclosing the actual user data 141. FIG. 2C is a schematic diagram 220 showing 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 of FIG. 2A is to determine whether a 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 residence within the user data 141 based at least in part on decrypting the encrypted data using the private key 104. For example, the verification service 121 may compare the decrypted user data 141 with one or more criteria and return the result of the comparison.

[0033] As shown, if the decrypted age indicates that the user is permitted to purchase an age-restricted item (e.g., the user's age is greater than the age criterion), the verification service 121 may send an approval instruction to the merchant device 130 without disclosing the user's actual age. Similarly, if the decrypted age indicates that the user is restricted from purchasing an age-restricted item (e.g., the user's age is less than the age criterion), the verification service 121 may send an instruction specifying that the user does not meet the age requirement without disclosing the user's actual age. Further, if the user's address within the decrypted user data 141 indicates that the user lives within one of the three states, the verification service 121 sends an instruction specifying that the user lives within one of the three states without disclosing the address. As described above, in such embodiments, the verification service 121 may store the result of the comparison in the blockchain 140 instead of the actual value of the user data 141.

[0034] Figure 3 shows a logical model 300 of an exemplary blockchain 140 corresponding to the disclosed embodiment. The blockchain 140 can comprise many such blockchains maintained by many different systems. Such an exemplary blockchain can comprise blocks such as blocks 301a - 301d. The blocks can include messages such as messages 307a - 307d. Generally, a block can include headers such as headers 303a - 303d that uniquely identify each block. Headers 303a - 303d can include hash values generated by a hash function. A hash function can be any function used to map input data of any size to a hash value of a fixed size. For example, a header can include at least one of a hash value of the previous block, a hash value (e.g., Merkle root) generated based on any message within the block, and a timestamp. Consistent with the disclosed embodiment, system 100 can require that a block 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, headers 303a - 303d can include a nonce selected to ensure that the header satisfies the proof - of - work condition. As a non - limiting example, the proof - of - work condition can require that the hash of the header be within a predetermined range of values. As an additional example, a header can be digitally signed with an encryption key of an approved system (e.g., private key 104, transaction key 105, verification key 122, and / or merchant key 132), and the digital signature can be included in the header. This digital signature can be verified using a key available to a member of system 100. Generally, one or more specified components of system 100 (e.g., blockchain 140, etc.) can 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 shows a logical model of a message 307b stored in blockchain 140 corresponding to the disclosed embodiment. 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, an email address, a phone number, or other less sensitive personal information of the 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 previous blocks within 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 reference may include, by way of non-limiting example, the hash of a preceding block within 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 ordinary skill in the art. For example, index information 403 may be encrypted with an encryption key. As an additional example, index information 403 may comprise a hash of at least one of a full name, an email address, a phone number, or other less sensitive personal information of the user.

[0036] Message 307b may include user data 141 corresponding to the disclosed embodiments. In various embodiments, user data 141 may be stored as part of index information 403 and / or may be stored separately from index information 403. In some embodiments, user data 141 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, user data 141 may be encrypted with an encryption key (e.g., the secret key 104 and / or 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). 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 index information 403 and / or may be stored separately from index information 403.

[0037] Message 307b may include user data result 404 corresponding to the disclosed embodiment. Generally, user data result 404 may include the result of comparing user data 141 against one or more criteria by verification service 121 and / or 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, message 307b including user data 404 may not include actual user data 141 (e.g., the user's age). In some embodiments, user data result 404 may be obfuscated or encrypted according to methods known to those skilled in the art. For example, user data result 404 may be encrypted with an encryption key (e.g., the private key 104 and / or 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, user data result 404 may be stored as part of index information 403 and / or may be stored separately from index information 403.

[0038] Message 307b may include an authentication record 407 corresponding to the disclosed embodiment. In some embodiments, the authentication record 407 may include information that enables subsequent auditing of the transaction. For example, the authentication record 407 may identify at least one of the verification system 120, the commercial organization associated with the verification system 120, the purpose of the authentication request (e.g., for disclosing and / or verifying elements of the user data 141), the result of the authentication request (e.g., which elements of the user data 141 were disclosed and / or verified), and information related to the authentication request. In some embodiments, the purpose of the authentication request may include creating a relationship with a commercial organization associated with the verification system 120 (e.g., a financial relationship such as a bank account, an intermediary account, a credit card account, and / or a loan account), or performing a service by the verification system 120 (e.g., disclosing and / or verifying user data 141 to a 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 understood by those skilled in the art, the above exemplary authentication purposes are not intended to be limiting. In some embodiments, the result of the authentication request may include whether the purpose of the authentication request was achieved. For example, if the purpose 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 purpose of the authentication request was to disclose and / or verify one or more elements of the user data 141, the result of the authentication request may indicate whether the elements of the user data 141 were disclosed and / or verified. As will be understood by those skilled in the art, the above exemplary authentication results are not intended to be limiting. In some embodiments, the information related to 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 can be obfuscated or encrypted according to methods known to those skilled in the art. For example, the authentication record 407 can be encrypted with an encryption key.

[0039] The encryption key can be used to encrypt elements of the message within the block corresponding to the disclosed embodiments. In some embodiments, such an encryption key can be associated with a member 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 can be associated with an approved system. Consistent with the disclosed embodiments, the corresponding encryption key can be available for decrypting the encrypted message elements. For example, if the elements of the message within the block are encrypted with a symmetric key, the same symmetric key can be used to decrypt the encrypted elements. As another example, if the elements of the message within the block are encrypted with a private key, the corresponding public key can be used to decrypt the encrypted elements. In some embodiments, the corresponding encryption key can be available to a member of the authentication system (e.g., the verification system 120, the contactless card 101, the mobile device 110, the merchant device 130, etc.). As described, such encryption keys can be used to store user data 141 in the blockchain 140, to publish and / or verify the user data 141 stored in the blockchain 140, and to create a record reflecting the publication and / or verification of the user data 141 stored in the blockchain 140.

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

[0041] As shown, the logical flow 500 begins at block 505, where user data 141 is stored in blockchain 140 and / or a cloud-based database. In some embodiments, the cloud-based database storing user data 141 is a component of blockchain 140. Generally, user data 141 is encrypted and can be stored in any suitable data storage entity (e.g., a database, a file, one or more blocks of blockchain 140, etc.). One or more elements of user data 141 can be signed by verification service 121 (e.g., generating a digital signature using the private key of an entity associated with verification service 121). At block 510, the user can access the account application 113 on mobile device 110 and provide valid authentication credentials (e.g., username / password, fingerprint, etc.). At block 515, the merchant device 130 outputs an instruction specifying that the contactless card 101 be tapped on the merchant device 130 as part of a request to receive one or more elements of user data 141. For example, the merchant device 130 can 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 for the user to move on the mass transit system. As another example, the request can specify that user data 141 be verified according to one or more criteria.

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

[0043] At block 535, the account application 113 of the mobile device 110 transmits 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 for verifying the user data 141. For example, the verification service 121 may decrypt the digital signature 107 using the public key 106 of the contactless card. Further, the verification service 121 may decrypt the encrypted data generated by the contactless card 101 using a copy of the private key 104 stored in the memory of the verification system 120. 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 exceeds a threshold, whether the user lives in one or more locations, etc.

[0044] At block 550, a block within blockchain 140 is generated to reflect the release of requested user data 141 from the user's wallet address 131-2 to the merchant's address 131-1. As described, a third party can view the details of the transaction, but the actual user data 141 remains encrypted within the blocks of blockchain 140. As described, in a verification embodiment, verification service 121 and / or blockchain 140 may store the result of a comparison of user data 141 with a criterion (e.g., the user is at least the same age as a specified age) as user data result 404. At block 555, merchant device 130 reads the block within blockchain 140 generated at block 550. Next, merchant device 130 may decrypt the data encrypted using the merchant's merchant key 132. Once decrypted, the data may be analyzed by merchant device 130 and / or the user. For example, 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. Thereafter, the user may be permitted to board the mass transit vehicle. As another example, the block may specify the result of the required comparison. In such an example, merchant device 130 determines the result of the comparison of the user data to the criterion from user data result 404 of blockchain 140.

[0045] Figure 6 shows an embodiment of logical flow 600. Logical flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, logical flow 600 may include some or all of the operations performed by verification service 121 to expose user data 141 requested by 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 (e.g., digital signature 107 and encrypted data) generated by contactless card 101. At block 620, verification service 121 uses public key 106 and a signature verification algorithm to decrypt digital signature 107 and verify that a request to disclose user data 141 was sent from contactless card 101. Similarly, verification service 121 may use private key 104 to decrypt the encrypted data and confirm that a request to disclose user data 141 was sent from contactless card 101.

[0047] At block 630, verification service 121 may receive a digital signature associated with the requested elements of user data 141 stored in blockchain 140. As described, the entity providing verification service 121 may sign each element of user data 141 with a corresponding digital signature to verify its trustworthiness. At block 640, verification service 121 may verify the digital signature associated with the requested elements of user data 141 stored in 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 merchant device 130. At block 650, verification service 121 determines the data associated with the request. For example, verification service 121 may extract a request token, the requested elements of user data 141, an account and / or user identifier, and merchant wallet address 131-1 from the decrypted data generated by contactless card 101. In one embodiment, verification service 121 may receive the requested elements of user data 141 (e.g., an image of the user's face) from blockchain 140. In other embodiments, verification service 121 indicates the requested data elements (e.g., URL, storage location, description, etc.) sufficient for the components of blockchain 140 to receive the data elements requested from user data 141.

[0048] At block 660, the verification service 121 provides the request data to the blockchain 140 for block generation. The blockchain 140 may generate a block that includes the requested (but encrypted) user data 141. As described, in some embodiments, the verification service 121 provides the requested user data 141. In other embodiments, the blockchain 140 searches for the user data 141 based on the information received from the verification service 121 (e.g., by accessing the data at a specified URL, by selecting a record of data associated with the user from a database, etc.). In some embodiments, the verification service 121 does not provide the user data 141 to the merchant device 130. Instead, the verification service 121 may verify the user data 141 and send the result of the verification to the merchant device 130.

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

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

[0051] FIG. 8 shows 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 as, or implemented as, part of an electronic device. In some embodiments, the computing architecture 800 may represent, for example, a system that implements one or more components of 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 system 100. The embodiments are not limited to this context. More generally, the computing architecture 800 is configured to implement all of the logic, applications, systems, methods, devices, 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, whether 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 can be a process running on a computer processor, a computer processor, a hard disk drive, a plurality of storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer, but is not limited thereto. By way of example, both an application running on a server and the server can be components. One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between two or more computers. Further, components can be communicatively coupled to each other by various types of communication media and can coordinate their operations. The coordination can include the one-way or two-way exchange of information. For example, a component can communicate information in the form of signals communicated through a communication medium. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments can alternatively use data messages. Such data messages can be transmitted through various connections. Examples of connections include a parallel interface, a serial interface, and a bus interface.

[0053] The computing system 802 includes various common computing elements such as one or more processors, multi-core processors, coprocessors, memory units, chip sets, controllers, peripheral devices, 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 the computing system 802.

[0054] As shown in FIG. 8, computing system 802 includes a processor 804, a system memory 806, and a system bus 808. Processor 804 can be any of a variety of commercially available computer processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, 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 can also be used as processor 804.

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

[0056] System memory 806 can 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), ferroelectric polymer memory, ovonic memory, polymer memory such as phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant arrays of independent disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 8, system memory 806 can include non-volatile memory 810 and / or volatile memory 812. The basic input / output system (BIOS) can be stored in non-volatile memory 810.

[0057] 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., CD-ROM or DVD). HDD 814, FDD 816, and optical disk drive 820 may each be connected to system bus 808 by an HDD interface 824, an FDD interface 826, and an optical drive interface 828, respectively. The HDD interface 824 for external drive use may include at least one or both of universal serial bus (USB) and IEEE 1394 interface technologies. Computing system 802 is generally configured to implement all of the logic, systems, methods, apparatuses, and functions described herein with reference to FIGS. 1-5.

[0058] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, and the like. For example, a number of program modules may be stored in 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, 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, authentication service 121, blockchain 140, and / or user data 141.

[0059] A user can input commands and information into computing system 802 via one or more wired / wireless input devices, such as pointing devices like keyboard 838 and mouse 840. Other input devices can include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, fingerprint readers, grabs, graphic tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to processor 804 via an input device interface 842 coupled to system bus 808, but can be connected by other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, and the like.

[0060] Monitor 844 or other types of display devices are also connected to system bus 808 via an interface such as video adapter 846. Monitor 844 can be inside or outside computing system 802. In addition to monitor 844, a computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0061] Computing system 802 can operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computer 848. Remote computer 848 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described in relation to computing system 802, but for simplicity only memory / storage device 850 is shown. The logical connections shown include wired / wireless connections to local area network (LAN) 852 and / or a larger network, such as wide area network (WAN) 854. Such LAN and WAN network environments are common in offices and enterprises and facilitate enterprise-scale computer networks such as intranets. All of these can be connected to a global communication network such as the Internet, for example. In an embodiment, network 111 of FIG. 1 is one or more of LAN 852 and WAN 854.

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

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

[0064] Computing system 802 is operable to communicate with wired and wireless devices or entities using the IEEE 802 standard family, such as a wireless device operably arranged to operate in wireless communication (e.g., IEEE 802.16 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technology, etc. Thus, the communication can be in a pre-defined structure similar to a conventional network, or simply ad-hoc communication between at least two devices. A Wi-Fi network provides a secure, reliable, and high-speed wireless connection using a wireless technology called IEEE 802.11x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to the Internet, or to a wired network (using media and functions related to IEEE 802.3).

[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, chip sets, and the like. 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, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination as to whether an embodiment is implemented using hardware elements and / or software elements may vary according to any number of factors such as required computational speed, power levels, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0066] One or more embodiments of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium that represents various logics within a processor, and when read by a machine, the machine manufactures the logic for performing the techniques described herein. Such representations, known as “IP cores,” are stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities for loading onto a manufacturing machine that creates the logic or processor. Some embodiments may be implemented using a machine-readable medium or article that can store, for example, instructions or instruction sets that, when executed by a machine, can cause the machine to perform methods and / or operations in accordance with the embodiments. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article can 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 disc read only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory card or disk, various digital versatile discs (DVD), tape, cassette, etc. The instructions can include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0067] The foregoing description of the 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. The scope of this disclosure is intended to be limited not by this detailed description, but rather by the claims appended hereto. Future applications claiming the priority of this application may claim the disclosed subject matter in different ways and may generally include any set of one or more limitations as variously disclosed or demonstrated herein.

Claims

1. receiving, by a communication interface of a contactless card, a request from a card reader of a merchant device to provide a user data element to a wallet address associated with said merchant; an applet executing in a memory of the contactless card encrypting the user data element and the indication of the wallet address based on a private key stored in the memory of the contactless card; the applet generating a digital signature of the request based on the private key; transmitting, via the communication interface of the contactless card to a card reader of a mobile device, the digital signature and the encrypted indication of the user data elements and the wallet address; the mobile device transmitting the digital signature and the encrypted indication of the user data elements and the wallet address to a verification service; the verification service verifying the digital signature based on a public key associated with the private key of the contactless card; a node of a blockchain in response to the validation by the validation service generating a block in the blockchain corresponding to the request, the block comprising the digital signature, the requested data element, and an indication of the validation of the wallet address associated with the merchant; decrypting an encrypted data element corresponding to the user data element based on the public key; receiving, by the merchant device, the decrypted data element from the wallet address associated with the merchant to fulfill the request; The method includes:

2. The private key corresponds to a request to read the user data element and a transaction key corresponds to a request to execute a transaction in a blockchain, the method comprising: determining, by the applet, the type of the request received from the card reader of the merchant device; the applet selecting one of the private key and the transaction key based on the determined type of the request; The method of claim 1 further comprising:

3. The method comprises: the validation service receiving a hash value associated with the encrypted data element; the verification service verifying the hash value based on a public key of an entity that signs the encrypted data element before decrypting the encrypted data element; The method of claim 1 further comprising:

4. 2. The method of claim 1, wherein the block in the blockchain further comprises an indication of a request token associated with the request, and the merchant device receives the decrypted data element based on the request token.

5. 2. The method of claim 1 , wherein the encrypted data element is one of a plurality of encrypted data elements associated with a user, each encrypted data element corresponding to one or more personally identifiable attributes of the user, the personally identifiable attributes of the user comprising: (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, and wherein the plurality of encrypted data elements are stored in one or more of: (i) the blockchain; and (ii) a cloud-based database.

6. The method comprises: the verification service decrypts the encrypted indication of the user data element and the wallet address based on the public key associated with the private key of the contactless card to verify the identity of the user associated with the user data element; The method of claim 1 further comprising:

7. The method comprises: the validation service identifies 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 the user data element of the user associated with the user data element; The method of claim 1 further comprising:

8. A processor circuit; a memory for storing instructions, The instructions, when executed by the processor circuit, cause the processor circuit to: a verification service receiving digitally signed and encrypted data from a merchant device, the encrypted data comprising a wallet address of the merchant and a user data element, the digitally signed and encrypted data being generated by an applet of the contactless card based on a private key stored in a memory of the contactless card in response to a request received from the merchant device to provide the user data element, the digitally signed and encrypted data being received by a card reader of the merchant device from a communication interface of the contactless card; the verification service verifying the digital signature based on a public key associated with the private key of the contactless card; a node of a blockchain in response to the validation by the validation service generating a block in the blockchain corresponding to the request, the block comprising the digital signature, the requested data element, and an indication of the validation of the wallet address associated with the merchant; decrypting an encrypted data element corresponding to the user data element based on the public key; sending the decrypted data element corresponding to at least the user data element to the wallet address associated with the merchant; receiving, by the merchant device, the decrypted data element from the wallet address associated with the merchant; Execute the Device.

9. the private key corresponds to a request to read the user data element, and a transaction key corresponds to a request to execute a transaction within the blockchain; and the memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: determining, by the applet, the type of the request received from the card reader of the merchant device; the applet selecting one of the private key and the transaction key based on the determined type of the request; Execute the 9. The apparatus of claim 8.

10. the memory storing instructions; The instructions, when executed by the processor circuit, cause the processor circuit to: the validation service receiving a hash value associated with the encrypted data element; the verification service verifying the hash value based on a public key of an entity that signs the encrypted data element before decrypting the encrypted data element; Execute the 9. The apparatus of claim 8.

11. 10. The apparatus of claim 8, wherein the block in the blockchain further comprises an indication of a request token associated with the request, and wherein the merchant device receives the decrypted data element based on the request token.

12. 10. The apparatus of claim 8, wherein the encrypted data element is one of a plurality of encrypted data elements associated with a user, each encrypted data element corresponding to one or more personally identifiable attributes of the user, the personally identifiable attributes of the user comprising: (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, and the plurality of encrypted data elements are stored in one or more of: (i) the blockchain; and (ii) a cloud-based database.

13. the memory storing instructions; The instructions, when executed by the processor circuit, cause the processor circuit to: the verification service decrypts the encrypted indication of the user data element and the wallet address based on the public key associated with the private key of the contactless card to verify the identity of the user associated with the user data element; Execute the 9. The apparatus of claim 8.

14. the memory storing instructions; The instructions, when executed by the processor circuit, cause the processor circuit to: the validation service identifies 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 the user data element of the user associated with the user data element; Execute the 9. The apparatus of claim 8.

15. A non-transitory computer readable storage medium having computer readable program code embodied therein, the computer readable program code being executable by a processor, the computer readable program code causing the processor to: receiving, by a communication interface of a contactless card, a request from a card reader of a merchant device to provide a user data element to a wallet address associated with said merchant; an applet executing in a memory of the contactless card encrypting the user data element and the indication of the wallet address based on a private key stored in the memory of the contactless card; the applet generating a digital signature of the request based on the private key; transmitting, via the communication interface of the contactless card to a card reader of a mobile device, the digital signature and the encrypted indication of the user data elements and the wallet address; the mobile device transmitting the digital signature and the encrypted indication of the user data elements and the wallet address to a verification service; the verification service verifying the digital signature based on a public key associated with the private key of the contactless card; a node of a blockchain in response to the validation by the validation service generating a block in the blockchain corresponding to the request, the block comprising the digital signature, the requested data element, and an indication of the validation of the wallet address associated with the merchant; decrypting an encrypted data element corresponding to the user data element based on the public key; receiving, by the device of the merchant, the decrypted data element from the wallet address associated with the merchant to fulfill the request; A non-transitory computer-readable storage medium for causing a program to be executed.

16. The computer-readable storage medium includes a computer-readable program code executable by a processor, the computer-readable program code including: determining, by the applet, the type of the request received from the card reader of the merchant device; the applet selecting one of the private key and the transaction key based on the determined type of the request; 20. The computer-readable storage medium of claim 15, further comprising:

17. The computer-readable storage medium includes a computer-readable program code executable by a processor, the computer-readable program code including: the validation service receiving a hash value associated with the encrypted data element; the verification service verifying the hash value based on a public key of an entity that signs the encrypted data element before decrypting the encrypted data element; 20. The computer-readable storage medium of claim 15, further comprising:

18. The computer-readable storage medium includes a computer-readable program code executable by a processor, the computer-readable program code including: the verification service decrypts the encrypted indication of the user data element and the wallet address based on the public key associated with the private key of the contactless card to verify the identity of the user associated with the user data element; 20. The computer-readable storage medium of claim 15, further comprising:

19. the block in the blockchain further comprises an indication of a request token associated with the request, the merchant device receiving the decrypted data element based on the request token, the encrypted data element being one of a plurality of encrypted data elements associated with a user, each encrypted data element corresponding to one or more personally identifiable attributes of the user, the personally identifiable attributes of the user comprising: (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, the plurality of encrypted data elements being stored in one or more of: (i) the blockchain, and (ii) a cloud-based database.

16. The computer-readable storage medium of claim 15.

20. The computer-readable storage medium includes a computer-readable program code executable by a processor, the computer-readable program code including: the validation service identifies 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 the user data element of the user associated with the user data element; 20. The computer-readable storage medium of claim 15, further comprising:

Images