Delegating management rights using a contactless card

Abstract

Delegating management of permissions using a contactless card. In one example, a permissions module can receive a request from a first account to grant a second account access to a computing resource. The permissions module can receive permissions data from the first account and encrypted data generated by the contactless card. The permissions module can transmit the permissions data and the encrypted data to an authentication server, which can verify the encrypted data based at least in part on a private key and determine, based on the permissions data, that the first account has permission to grant access to the computing resource. The permissions module can receive, from the authentication server, an indication of the verification of the encrypted data and a permissions vector associated with the second account, the permissions vector reflecting the granting of access to the computing resource to the second account.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 360,149, filed March 21, 2019, entitled "Delegated Administration of Permissions Using a Contactless Card". The contents of the aforementioned application are incorporated herein by reference in their entirety. Technical Field

[0003] The embodiments described herein generally relate to computing platforms, and more specifically, to delegated management permissions using contactless cards. Background Technology

[0004] Users typically need permission to access computing resources and / or perform actions using those resources. As the number of users in an organization increases, the complexity and difficulty of managing permissions also increase. Conventional solutions for managing permissions require significant user work and often lack reliable security measures. Summary of the Invention

[0005] The embodiments disclosed herein provide systems, methods, artifacts, and computer-readable media for authorizing access to computing resources using contactless cards. In one example, an authorization module may receive a request from a first account to authorize a second account to access computing resources, which include one or more of the following: (i) an application, (ii) data, and (iii) an operation performed using the application. The authorization module may receive authorization data associated with the first account and encrypted data generated by the contactless card from a communication interface of the contactless card associated with the first account. The applet of the contactless card is used to generate the encrypted data based at least in part on the private key of the contactless card stored in the memory of the contactless card. The authorization module may transmit the authorization data and the encrypted data to an authentication server. The authentication server may verify the encrypted data by decrypting the encrypted data based at least in part on the private key of the contactless card associated with the first account stored in the memory of the authentication server, and determine, based on the authorization data associated with the first account, that the first account has the authorization to authorize the second account to access the computing resources. The permissions module can receive instructions from the authentication server regarding the verification of encrypted data and a permissions vector associated with the second account, which reflects the permission granted to the second account to access computing resources. Attached Figure Description

[0006] Figures 1A-1B An example of a system for implementing delegated management permissions using contactless cards is shown.

[0007] Figures 2A-2B Embodiments are shown that use a contactless card to delegate management of permissions.

[0008] Figures 3A-3F Embodiments are shown that use a contactless card to delegate management of permissions.

[0009] Figure 4 Embodiments are shown that use a contactless card to delegate management of permissions.

[0010] Figure 5 Embodiments are shown that use a contactless card to delegate management of permissions.

[0011] Figure 6 Embodiments are shown that use a contactless card to delegate management of permissions.

[0012] Figure 7 Embodiments are shown that use a contactless card to delegate management of permissions.

[0013] Figure 8 Embodiments are shown that use a contactless card to delegate management of permissions.

[0014] Figure 9 Embodiments are shown that use a contactless card to delegate management of permissions.

[0015] Figures 10A-10B Embodiments are shown that use a contactless card to delegate management of permissions. DETAILED DESCRIPTION

[0016] Embodiments disclosed herein provide secure techniques for using a contactless card to delegate management of permissions. Generally, during manufacture of a contactless card, the contactless card is personalized to include data of an associated user. For example, a memory of the contactless card can store one or more applets, private keys, card data (e.g., account numbers, etc.), and permission data. A user associated with the contactless card can then use the contactless card to delegate permissions, access resources, and / or perform operations.

[0017] For example, a first user can wish to access data stored in a database via a computing device. The permissions module can control access to the database and can output a notification to the computing device specifying that the user tap their contactless card. The user can then tap their contactless card against the computing device, which can cause the contactless card to come within communication range of the computing device. In doing so, an applet executing in the contactless card generates encrypted data using a private key, which is then transmitted to the computing device along with permissions data stored in the memory of the contactless card. The permissions module can receive the encrypted data and permissions data generated by the contactless card and transmit the received data to an authentication server for verification. The authentication server can then verify the encrypted data using a copy of the private key stored in the memory of the server (or other secure element, such as a hardware security module (HSM)). If the authentication server can decrypt the encrypted data using the private key, the authentication server verifies the encrypted data and transmits an indication of the verification to the permissions module. In some embodiments, the authentication server transmits an instance of the user’s permissions data to the permissions module. The permissions module can then allow the user to access the data stored in the database based on the indication that the encrypted data was verified by the authentication server.

[0018] Advantageously, the embodiments disclosed herein improve the security of devices, applications, and / or data. For example, by requiring verification of encrypted data generated by a contactless card to access an application and / or data, the security of the application and / or data is improved. As another example, by requiring verification of encrypted data prior to performing an operation (e.g., making a purchase, extending credit, etc.), the security of such operations and related assets is improved. Further, by requiring verification of encrypted data as a condition of any attempt to delegate permissions, the security of the delegation of permissions is improved.

[0019] With general reference to notations and nomenclature used herein, one or more portions of the following detailed description can be presented in terms of program procedures acting on data that can be stored in computer or networked computers. These procedural 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 here, and generally, conceived to be an ordered sequence of operations performed on some physical, although not necessarily electronic, quantity. Generally, 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 has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

[0020] Further, these manipulations are often termed as such terms as addition or comparison, which often are associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or is desirable in most cases, in any of the operations described herein that form part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of various embodiments include digital computers, and / or specially constructed apparatuses, which are selectively activated or configured by computer programs stored therein, written in accordance with the teachings of this document. Various embodiments also relate to apparatus or systems for performing these operations. These apparatuses can be specially constructed for the required purposes. The required structure for a variety of these machines will be evident from the description given.

[0021] 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. It can be evident, however, that the novel embodiments can be practiced in

[0022] Figure 1A A schematic diagram of an exemplary system 100 consistent with the disclosed embodiments is depicted. As shown, the system 100 includes one or more contactless cards 101, one or more computing devices 110, one or more authentication servers 120, and one or more host systems 150. The contactless card 101 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, and the like. The contactless card 101 can include one or more communication interfaces 107, such as a radio frequency identification (RFID) chip, configured to communicate with the computing device 110 via NFC, EMV standards, or other short-range protocols in wireless communication. While NFC is used as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as Bluetooth and / or Wi-Fi. The computing device 110 represents any type of network-enabled computing device, such as a smartphone, a tablet, a wearable device, a laptop, a portable gaming device, a mobile device, a workstation, a desktop computer, a server, and the like. The authentication server 120 and the host system 150 represent any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, and the like.

[0023] As shown, the memory 111 of the computing device 110 includes an instance of an operating system (OS) 112. Example operating systems 112 include the Android OS, iOS, Linux, and Windows operating systems. As shown, the OS 112 includes one or more applications 113, an instance of a permissions module 114-1, and data 115. The applications 113 represent any type of executable code, such as applications, services, scripts, and the like. The data 115 represents any data stored in a computer-readable medium. Although depicted as being stored in the memory 102, the data 115 can be stored in a non-volatile storage device of the computing device 110 (or communicably attached to the computing device 110).

[0024] The permissions modules 114 (including the permissions module 114-1 of the server 120, the permissions module 114-2, and the permissions module 114-3 of the host system 150) are generally configured to enforce delegated permissions in the system 100 by confirming that a participant attempting to perform an operation has the necessary permissions as reflected in the permissions data 106 (including instances of the permissions data 106-1, 106-2, 106-3, and 106-4). The permissions data 106 represents any data structure reflecting whether an associated user is permitted to perform an attempted operation and / or access a given resource. For example, the permissions data 106 can be a vector, where each element of the vector reflects whether a user can perform an attempted operation and / or access a given resource. The attempted operation can include any type of operation, such as a user (e.g., an administrator) granting, modifying, and / or revoking permissions to other users. Additional examples of attempted operations include executing an application (e.g., the applications 113 of the computing device 110, the applications 152 of the host system 150, and the like), accessing a particular feature and / or interface of an application, accessing data (e.g., the data 115 of the computing device 110, the data 151 of the host system 150, and the like), and performing an operation using an application and / or data. Although depicted as separate entities, the permissions modules 114 and / or associated functionality described herein can be integrated into the OS 112, the applications 113, the applications 152, and / or any other permissions management platform. Thus, Figures 1A-1B The particular configuration depicted in FIG. 1 should not be considered limiting to the present disclosure.

[0025] The permissions module 114 can also consider data generated by the contactless card 101 when determining whether to grant and / or deny an attempted operation. For example, a system administrator can use the permissions application 113 to grant new employees access to the accounting application 113 and corresponding accounting data 151 of the host system 150. The permissions module 114-1 receives an indication of the attempted delegation of permissions from the permissions application 113 and / or the OS 112. The permissions module 114-1 can output a notification on the administrator’s computing device 110 to complete the attempted delegation of permissions. The notification can instruct the user to tap the contactless card 101 against the computing device 110, thereby bringing the contactless card 101 close enough to the card reader 119 of the computing device 110 to enable data transfer (e.g., NFC data transfer, Bluetooth data transfer, etc.) between the communication interface 107 of the contactless card 101 and the card reader 119 of the computing device 110. In some embodiments, the computing device 110 can trigger the card reader 119 via an application program interface (API) call. In one example, the computing device 110 triggers the card reader via an API call in response to receiving an indication of the attempted operation (e.g., from the OS 112, the application 113, the data 115, etc.). Additionally and / or alternatively, the computing device 110 can trigger the card reader 119 based on periodically polling the card reader 119. More generally, the computing device 110 can use any feasible method to trigger the card reader 119 to participate in communication.

[0026] After communication has been established between the computing device 110 and the contactless card 101, the applet 103 executing on the processor (not shown) of the contactless card 101 generates encrypted data 105 and transmits it to the computing device 110 via the communication interface 107. For example, the applet 103 of the contactless card 101 can use a cryptographic algorithm to generate a cryptographic payload of the encrypted data 105 based at least in part on a private key 104 stored in the memory 102 of the contactless card 101. In such embodiments, the private key 104 and some other data (e.g., a user identifier, an account identifier, etc.) can be provided as inputs to the cryptographic algorithm, which outputs the encrypted data 105. In general, the applet 103 can use any type of cryptographic algorithm and / or system to generate the encrypted data 105, and the use of particular cryptographic algorithms as examples herein should not be considered limiting to the present disclosure. In some embodiments, the applet 103 can use a key diversification technique to perform encryption to generate the encrypted data 105. An example of a key diversification technique is described in U.S. Patent Application 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0027] Once generated, the applet 103 can transmit the encrypted data 105 to the permissions module 114-1 of the computing device 110, e.g., via NFC. In some embodiments, the applet 103 can transmit the permissions data 106-1 to the permissions module 114-1. The permissions module 114-1 can then generate an indication of the requested operation (or provide an indication received from the OS 112 and / or the application 113) as part of a request 117 that includes the encrypted data 105. The request 117 generally includes an indication of the attempted operation (e.g., an account identifier of the new employee, an indication of the accounting data in the data 151, and an indication of the accounting application 113, etc.) and the encrypted data 105. The permissions module 114-1 can then transmit the request 117 (including the encrypted data 105) to the authentication application 123 of the authentication server 120. However, in some embodiments, the encrypted data 105 is transmitted separately from the request 117.

[0028] Once received, the authentication application 123 can then attempt to authenticate the encrypted data 105 received with the request 117. For example, the authentication application 123 can attempt to decrypt the encrypted data 105 using a copy of the private key 104 stored in the memory 122 of the authentication server 120. The private key 104 can be the same as the private key 104 stored in the memory 102 of the contactless card 101, where each contactless card 101 is manufactured to include a unique private key 104 (and the authentication server 120 stores a corresponding copy of each unique private key 104). Thus, the authentication application 123 can successfully decrypt the encrypted data 105, thereby verifying the encrypted data 105. Although the private key 104 is described as being stored in the memory 122, the private key 104 can be stored elsewhere, such as in a secure element and / or a hardware security module (HSM). In such embodiments, the secure element and / or HSM can use the private key 104 and the cryptographic function to decrypt the encrypted data 105.

[0029] For example, as described above, the user identifier of the user requesting the operation can be used to generate the encrypted data 105. In such an example, the authentication application 123 can use the private key 104 of the authentication server 120 to decrypt the encrypted data 105. If the result of the decryption produces the user identifier associated with the requesting user's account in the account data 124, the authentication application 123 validates the encrypted data 105. If the authentication application 123 is unable to decrypt the encrypted data to produce the expected result (e.g., the user identifier of the account associated with the contactless card 101), the authentication application 123 does not validate the encrypted data 105. As a result of the failed validation, the authentication application 123 transmits an indication of the failed validation to the permissions module 114-1, which denies the requested operation (e.g., the request to grant the new employee access to the accounting application 113 and / or the accounting data 151).

[0030] If the authentication application 123 validates the encrypted data 105, the authentication application 123 and / or the permissions module 114-2 can determine whether the requesting user has the permissions to grant the new employee access to the identified resources. For example, the authentication application 123 and / or the permissions module 114-2 can determine whether the permissions data 106-3 of the requesting user in the account data 124 (and / or the permissions data 106-1, 106-2 received from the computing device 110) indicates whether the administrator has the permissions to grant access to the new employee.

[0031] Figure 1B Embodiments are depicted in which the authentication application 123 and / or the permissions module 114-2 have determined that the permissions data 106 reflects that the administrator has the permissions to grant access to the new employee. In response, the authentication application 123 and / or the permissions module 114-2 can transmit the authorization 118 to the permissions module 114-1 of the computing device 110. Further, the authentication application 123 and / or the permissions module 114-2 can update the permissions data 106-3 of the new employee to reflect that the new employee can access the accounting application 113 and the accounting data in the data 151. Accordingly, the authorization 118 can include the updated permissions data 106. The permissions module 114-1 and / or the permissions application 113 can then output an indication of the authorization to the administrator. The permissions module 114-1 can further update the permissions data 106-1 in the contactless card 101, for example, when the contactless card 101 is subsequently tapped against the device 110.

[0032] However, if the authentication application 123 and / or the permissions module 114-2 determines that the permissions data 106 reflects that the administrator does not have permission to grant access to the new employee, the authentication application 123 and / or the permissions module 114-2 can deny the requested operation. In such embodiments, the authentication application 123 and / or the permissions module 114-2 will transmit a denial indication to the permissions module 114-1, which in turn can output a denial indication to the administrator.

[0033] In some embodiments, the permissions module 114-1 executing on the computing device 110 can determine whether the permissions data 106-2 (and / or the permissions data 106-1 of the contactless card 101) reflects whether the administrator has permission to grant access to the new employee. Thus, in such embodiments, the permissions module 114-1 determines whether the permissions data 106-2 (and / or the permissions data 106-1 of the contactless card 101) reflects whether the administrator has permission to grant access to the new employee in response to receiving an indication that the authentication application 123 has verified the encrypted data 105. Similarly, if the request is to access a resource of the host system 150, the permissions module 114-3 can determine whether the permissions data 106-4 (and / or the permissions data 106-1, 106-2 received from the requesting computing device 110) reflects whether the administrator has permission to grant access to the new employee in response to receiving an indication that the authentication application 123 has verified the encrypted data 105.

[0034] The above-described techniques can be used for any type of attempted operation in the system 100. For example, if the new employee subsequently attempts to open the accounting application 113 using their computing device 110, the permissions module 114-1 will require the new employee to tap their contactless card 101 against the computing device 110. In response, the applet 103 will generate encrypted data 105 using the private key 104 and the account identifier of the new employee. The permissions module 114-1 will then receive the encrypted data 105 and transmit the encrypted data 105 as part of a request to access the accounting application 113. The authentication application 123 can then attempt to verify the encrypted data 105 as described above. If the verification of the encrypted data 105 is successful, the authentication application 123 and / or the permissions module 114-2 can grant and / or deny the requested access to the accounting application 113 based on the permissions data 106 in the account data 124 of the new employee.

[0035] While Figures 1A-1Bis described with reference to an example business organization, but the present disclosure is equally applicable to other groups, such as families, educational institutions, etc. For example, a parent can wish to provide their child with limited access to a checking account. In such an example, the parent can delegate access to the checking account using the account management application 113 according to one or more rules. The rules can include spending limits, merchant limits, time limits, and / or geographic limits. The permissions module 114-1 can then instruct the parent to tap their contactless card 101 against the computing device 110 to generate encrypted data 105, which can be verified by the authentication application 123. Once verified, the permissions data 106 for the parent’s account (and / or a child account generated for the child) can be updated to reflect that the child is able to use funds in the checking account according to the rules specified by the parent. In one embodiment, a virtual account number can be generated for the child’s account. The virtual account number can be tied to the parent’s checking account and limited based on the rules specified by the parent.

[0036] Figure 2A is a schematic diagram 200 depicting an example embodiment of tapping a contactless card 101 in order to delegate managed permissions. As shown, the permissions module 114-1 executing on the computing device 110-1 displays a graphical user interface (GUI) to delegate permissions. Although depicted as part of the permissions module 114-1, the GUI can be part of a different application 113. As shown, the GUI includes form fields 201-203. More specifically, the user field 201 corresponds to the user to which permissions are being delegated, the resource field 202 corresponds to the resource to which permissions are being delegated, and the time field 203 corresponds to the amount of time for which permissions are being delegated. Thus, as shown, the user has entered the example user “User ABC” in field 201, the example resource “Database 1” (e.g., corresponding to data 151) in field 202, and an unlimited duration in field 203. The user can then select the submit button 204.

[0037] Figure 2B is a schematic diagram 300 depicting an example embodiment in which the user has selected the submit button 204. As shown, the permissions module 114-1 has generated a virtual account number 301 for the child. The virtual account number 301 can be tied to the parent’s checking account and limited based on the rules specified by the parent. The virtual account number 301 can be used by the child to access the parent’s checking account according to the rules specified by the parent. Figure 2AFIG. 21 is a diagram 210 of an embodiment of the submit button 204 in FIG. 20. As shown, the permissions module 114-1 instructs the user to tap the contactless card 101 against the computing device 110-1 to complete the delegation of permissions to the user ABC. As described above, once the user taps the contactless card 101 against the computing device 110-1, the contactless card 101 generates and transmits the encrypted data 105 to the permissions module 114-1. In some embodiments, the contactless card 101 transmits the permissions data 106-1 to the permissions module 114-1. The permissions module 114-1 can generate a request packet specifying the requested permissions (e.g., unlimited access to database 1 by user ABC). The permissions module 114-1 then transmits the request and the encrypted data 105 to the authentication server 120. In some embodiments, the permissions module 114-1 can transmit the permissions data 106-1 and / or 106-2 to the authentication application 123.

[0038] The authentication application 123 can then validate the encrypted data 105 by decrypting the encrypted data 105 with the private key 104 of the server 120. Once validated, the authentication application 123 and / or the permissions module 114-2 determines whether the requesting user has the permissions to give the user access to the database. As described above, the authentication application 123 and / or the permissions module 114-2 can determine whether the requesting user has the permissions based on the permissions data 106, which can include the permissions data 106-1, 106-2, 106-3, and / or 106-4. If the requesting user has the permissions, the authentication application 123 and / or the permissions module 114-2 can update the permissions data 106 of the target user (in this example, user ABC) to reflect the unlimited access to database 1. The permissions data 106-1, 106-2, 106-3, and / or 106-4 can each be updated to reflect the unlimited access to database 1 by user ABC.

[0039] Figure 3Ais a diagram 300 illustrating an embodiment in which a user can request permissions from another user. As shown, an example application 113 executing on computing device 110-1 can include a GUI with form fields 301-303. Although depicted as being output by application 113, form fields 301-303 can be output by permissions module 114-1 of computing device 110-1. More specifically, user field 301 corresponds to the user requesting permissions, resource field 302 corresponds to the resource for which permissions are being requested, and time field 303 corresponds to the amount of time for which permissions are being requested. Thus, as shown, the user has entered an example user, “User ABC,” in field 301, an example resource, “$20,000 spending limit,” in field 302, and a one-month duration in field 303. In some embodiments, the spending limit can be associated with application 113, an account, etc. The user can then select submit button 304.

[0040] Figure 3B is a diagram 310 depicting an embodiment in which the user has selected submit button 304 in Figure 3A As shown, permissions module 114-1 on computing device 110-1 instructs the user to tap contactless card 101 against computing device 110-1 to process the request for permissions for User ABC to have a $20,000 spending limit. As described above, once the user taps contactless card 101 against computing device 110, contactless card 101 generates and transmits encrypted data 105 to permissions module 114-1. In some embodiments, contactless card 101 transmits permissions data 106-1 to permissions module 114-1. In at least one embodiment, applet 103 of contactless card 101 generates a digital signature using private key 104. The digital signature can sign encrypted data 105 and / or permissions data 106-1. Contactless card 101 can then transmit the digital signature with encrypted data 105 and / or permissions data 106-1.

[0041] Permissions module 114-1 can then generate a request packet specifying the requested permissions (e.g., that User ABC can have a one-month $20,000 spending limit). The request can further specify the account associated with the requested spending limit, the account of the requesting user (e.g., the account number of User ABC’s contactless card 101), the application 113 associated with the requested spending limit, etc. Permissions module 114-1 then transmits the request, the digital signature, and encrypted data 105 to authentication server 120. In some embodiments, permissions module 114-1 can transmit permissions data 106-1 and / or 106-2 to authentication application 123.

[0042] The authentication application 123 can then verify the encrypted data 105 by decrypting the encrypted data 105 using the private key 104 of the server 120. The authentication application 123 can also verify the digital signature by decrypting the digital signature using the public key associated with the contactless card 101 and stored by the server 120. Once the authentication application 123 verifies the encrypted data 105, the digital signature, the authentication application 123 and / or the permissions module 114-2 can transmit a notification (or another indication) to an administrator (or other user) with sufficient permissions to approve the request.

[0043] Figure 3C is a diagram 320 illustrating an embodiment in which the permissions module 114-1 executing on the administrator’s computing device 110-2 has received a notification from the authentication application 123 and / or the permissions module 114-2 that the user ABC has requested a $20,000 spending limit for one month (as described above with reference to Figure 3B As illustrated, the permissions module 114-1 outputs a GUI with fields 305-307 reflecting the requested user, the requested permissions, and the duration, respectively. The administrator can select the approve button 308 to initiate approval of the requested spending limit.

[0044] Figure 3D is a diagram 330 illustrating an embodiment in which the administrator has selected the approve button 308 in Figure 3C As illustrated, the permissions module 114-1 instructs the user to tap the contactless card 101 against the computing device 110-2 to complete the delegation of permissions to the user ABC. As described above, once the user taps the contactless card 101 against the computing device 110-2, the contactless card 101 generates and transmits the encrypted data 105 to the permissions module 114-1. In some embodiments, the contactless card 101 transmits the administrator’s permissions data 106-1 to the permissions module 114-1. The permissions module 114-1 can generate a request packet specifying the requested permissions (e.g., a $20,000 spending limit for the user ABC for one month). The request can also specify the account associated with the requested spending limit (e.g., the account number of the contactless card 101 of the user ABC), the account of the requesting user, the application 113 associated with the requested spending limit, etc. The permissions module 114-1 then transmits the request and the encrypted data 105 to the authentication server 120. In some embodiments, the permissions module 114-1 can transmit the administrator’s permissions data 106-1 and / or 106-2 to the authentication application 123.

[0045] The authentication application 123 can then verify the encrypted data 105 by decrypting the encrypted data 105 using the private key 104 of the server 120. Once verified, the authentication application 123 and / or the permissions module 114-2 determines whether the requesting user has the permissions to give user ABC access to the requested spending limit. As described above, the authentication application 123 and / or the permissions module 114-2 can determine whether the administrator has the permissions based on the permissions data 106, which can include permissions data 106-1, 106-2, 106-3, and / or 106-4. If the administrator has the permissions, the authentication application 123 and / or the permissions module 114-2 can update the permissions data 106 of the target user (in this example, user ABC) to reflect a $20,000 spending limit for 1 month. The permissions data 106-1, 106-2, 106-3, and / or 106-4 can each be updated to reflect that user ABC has a $20,000 spending limit for 1 month. As described in some embodiments, a virtual account number can be generated for user ABC for the stated spending limit and duration. The virtual account number can be further restricted based on merchant, geolocation, and / or any other parameter. In some embodiments, the account number of the contactless card 101 of the user (in this example, user ABC) can be permitted a $20,000 spending limit for 1 month.

[0046] Figure 3E FIG. 34 is a schematic diagram 340 illustrating an embodiment in which user ABC attempts to make a purchase using the application 113. The application 113 can be a merchant application, a web browser, or any other application configured to process payments and / or transfer funds. As shown, the application 113 includes form payment fields 311-313 corresponding to an account number field, an expiration date field, and a card verification value (CVV) field, respectively. As shown, the user has entered an example account number, expiration date, and CVV into fields 311-313, respectively. The account number can be a time-limited virtual account number and / or account number of the contactless card 101 of the user (in this example, user ABC).

[0047] Figure 3F FIG. 35 is a schematic diagram 350 depicting that the user has selected Figure 3EFIG. 3 illustrates a flowchart of an embodiment of a process 300 for approving a purchase request. As shown, the process 300 begins with a user (e.g., user ABC) requesting a purchase of a product or service (e.g., a $19999 purchase) using a computing device 110-1. The user can request the purchase using an application 113 on the computing device 110-1. The application 113 can then transmit a request to the authorization module 114-1 on the computing device 110-1. The request can include a request for a purchase of a product or service (e.g., a $19999 purchase) and a request for a user (e.g., user ABC) to tap the contactless card 101 against the computing device 110-1 to complete the requested purchase. The request can also include a request for the authorization module 114-1 to transmit the request and encrypted data 105 to the authentication server 120.

[0048] The authorization module 114-1 can then generate a request package specifying the requested authorization (e.g., a $19999 purchase). The authorization module 114-1 can then transmit the request and encrypted data 105 to the authentication server 120. In some embodiments, the authorization module 114-1 can transmit the authorization data 106-1 and / or 106-2 to the authentication application 123.

[0049] The authentication application 123 can then validate the encrypted data 105 by decrypting the encrypted data 105 using the private key 104 of the server 120. Once validated, the authentication application 123 and / or the authorization module 114-2 determines whether the requesting user has authorization to spend $19999. As described above, the authentication application 123 and / or the authorization module 114-2 can determine whether the requesting user has authorization based on the authorization data 106, which can include the authorization data 106-1, 106-2, 106-3, and / or 106-4. The authorization data 106 can reflect the available spending limit of the requesting user and a 1-month duration of the spending limit. If the requesting user has sufficient spending limit and is within the 1-month period of the spending limit reflected in the authorization data 106, the authentication application 123 and / or the authorization module 114-2 can approve the requested purchase. Otherwise, the requested purchase is denied.

[0050] Figure 4is a schematic diagram 400 that describes embodiments of using a contactless card to obtain permissions on first computing device 110-1 and second computing device 110-2. As shown, computing devices 110-1, 110-2 each execute example application 113-1. However, the functionality provided by application 113-1 on devices 110-1, 110-2 is different. As described above, permissions data 106-1 of contactless card 101 can be used to control the functionality, appearance, and / or any other attribute of the application.

[0051] For example, when application 113-1 is executed on device 110-1, permissions module 114-1 can output an indication that specifies to tap contactless card 101-1 against device 110-1. Doing so can cause contactless card 101-1 to generate and transmit encrypted data 105 for verification by authentication application 123 as described above. Additionally, as stated, contactless card 101-1 can transmit permissions data 106-1 to permissions module 114-1 of device 110-1. Permissions module 114-1 can then transmit permissions data 106-1 and / or an indication of which features of application 113-1 to expose to application 113-1. In response, application 113-1 exposes three features associated with links 401-403 on device 110-1. For example, as shown, link 401 is associated with an interface to view an account balance that a user associated with contactless card 101-1 can access, link 402 is associated with a payment interface that a user associated with contactless card 101-1 can access, and link 403 is associated with an interface that a user associated with contactless card 101-1 can access to request credit.

[0052] However, as shown, when a user associated with contactless card 101-2 taps contactless card 101-2 against computing device 110-2, permissions data 106-1 allows for a more limited functionality of application 113-1 to be exposed. For example, as shown, application 113-1 on computing device 110-2 exposes an interface associated with link 404, i.e., an interface to view an account balance, based on permissions data 106-2 received from contactless card 101-2. However, application 113-1 on computing device 110-2 does not expose other interfaces (e.g., a payment interface, a credit request interface, etc.).

[0053] Accordingly, as stated above, the permissions module 114-1 restricts and / or permits access to different functions, pages, and / or any other attributes of the application 113-1 to a user based on the permissions data 106 associated with the user associated with the given contactless card 101-1. In some embodiments, the permissions data 106-1 stored in the contactless card is in plain text that can be read directly by the computing device 110. In such embodiments, the generation of the encrypted data 105 can not be generated and / or verified by the authentication server 120. Such embodiments are useful, for example, when the given device 110 does not have internet access. However, in some such embodiments, the user can be required to provide local login credentials on the computing device 110 to improve security.

[0054] Figure 5 An example portion of the permissions data 106 is depicted in accordance with one embodiment. As shown, the permissions data 106 is a vector of binary values. Each element of the permissions data 106 can specify whether the associated user is permitted to access and / or perform an operation on the associated resource. For example, as shown, the value "1" in element 501 of the permissions data 106 can indicate that the user is permitted to access the resource and / or perform the operation. Similarly, the value "0" in element 502 of the permissions data 106 can indicate that the user is not permitted to access the resource and / or perform the operation. As stated above, the elements of the permissions data 106, including elements 501, 502, can be associated with granting, modifying, and / or revoking permissions to other users, performing applications (e.g., applications 113 of the computing device 110, applications 152 of the host system 150, etc.), accessing specific features and / or interfaces of applications, accessing data (e.g., data 115 of the computing device 110, data 151 of the host system 150, etc.), and performing operations using applications and data.

[0055] Figure 6 An embodiment of a logical flow 600 is shown. The logical flow 600 can be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 600 can include some or all of the operations performed to delegate management of permissions using a contactless card 101. Embodiments are not limited to this context.

[0056] As shown, the logic flow 600 begins at block 605, where one or more contactless cards 101 are programmed at manufacture to include a unique private key 104 and permissions data 106-1. For example, permissions data 106-3 in the account data 124 of the associated user can be programmed into the memory 102 of the user's contactless card 101 at manufacture. At block 610, the permissions module 114-1 executing on the computing device 110 can receive a request from a first account to grant permissions to a second account to a computing resource and / or to perform an operation. For example, a user of the first account can wish to grant a user of the second account access to data 151 and / or applications 152 of the host system 150. At block 615, the user associated with the first account taps the contactless card 101 against the computing device 110 to cause the contactless card 101 to generate and transmit encrypted data 105. At block 620, the applet 103 of the contactless card 101 can then generate the encrypted data 105 using the private key 104, input data (e.g., a user identifier), and a cryptographic algorithm. At block 625, the applet 103 can transmit the encrypted data 105 and the permissions data 106-1 to the permissions module 114-1 of the computing device 110.

[0057] At block 630, the permissions module 114-1 of the computing device 110 transmits the encrypted data 105 and a request to grant specified permissions to the second account to the authentication server 120. For example, the request can specify the permission to grant the second account access to specified data 151 and / or applications 152 of the host system 150 by the first account. In some embodiments, the permissions module 114-1 can transmit the permissions data 106-1 and / or the permissions data 106-2 to the authentication server 120. In other embodiments, the permissions module 114 can refrain from transmitting the permissions data to the server 120. At block 635, the authentication application 123 decrypts the encrypted data 105 using the private key 104 of the authentication server 120 to verify the encrypted data 105.

[0058] At block 640, the authentication application 123 determines that the first account has the authority to grant the requested access to the second account. For example, the authentication application 123 can reference the permissions data 106-3 of the first account stored in the account data 124 to determine whether the first account has the required authority. As another example, the authentication application 123 can use the received permissions data 106-1 and / or the permissions data 106-2. At block 645, the authentication application 123 updates the permissions data 106 of the second account to reflect the grant of access to the specified resource. For example, the authentication application 123 can update the permissions data 106-3 of the second account stored in the account data 124 to reflect that the second account is allowed to access the specified data 151 and / or applications 152 of the host system 150. Similarly, the update can be pushed to other instances of the permissions data 106 of the second account (e.g., the permissions data 106-1 on the contactless card 101 of the user of the second account, the permissions data 106-2 on the computing device 110 of the user of the second account, the permissions data 106-4 of the host system 150, etc.).

[0059] At block 650, the authentication application 123 can transmit an indication of the verification of the encrypted data 105 and the grant of permissions to the second account to the permissions module 114-1. In some embodiments, the authentication application 123 can transmit the permissions data 106-3 of the second account to the permissions module 114-1. At block 655, the user of the second account can tap their contactless card 101 against the computing device 110 to update the permissions data 106-1 stored in the contactless card 101 to reflect the grant of permissions.

[0060] Figure 7 An embodiment of a logic flow 700 is illustrated. The logic flow 700 can be representative of some or all of the operations executed by one or more embodiments described herein. For instance, the logic flow 700 can include some or all of the operations of modifying application features based on permissions data. Embodiments are not limited to this context.

[0061] As shown, the logic flow 700 begins at block 705, where the permissions module 114-1 executing on the computing device 110 receives a request to perform an operation from, for example, an application 113 and / or the OS 112. The operation can include, but is not limited to, accessing a computing resource, granting a permission, modifying a permission, revoking a permission, and / or performing an operation using a computing resource. At block 710, the user associated with the request taps the contactless card 101 against the computing device 110 to cause the contactless card 101 to generate and transmit the encrypted data 105. The applet 103 of the contactless card 101 can then generate the encrypted data 105 using the private key 104, input data (e.g., a user identifier), and a cryptographic algorithm. The applet 103 can transmit the encrypted data 105 and the permissions data 106-1 to the permissions module 114-1 of the computing device 110.

[0062] At block 715, the permissions module 114-1 of the computing device 110 transmits the encrypted data 105 and an indication of the requested operation to the authentication server 120. In some embodiments, the permissions module 114-1 can transmit the permissions data 106-1 and / or the permissions data 106-2 to the authentication server 120. The authentication application 123 can then decrypt the encrypted data 105 using the private key 104 of the authentication server 120 to verify the encrypted data 105. At block 720, the permissions module 114-1 receives an indication of the verification of the encrypted data 105 from the authentication server 120. The permissions module 114-1 can also receive the permissions data 106-3 for the requesting account from the authentication server 120.

[0063] At block 725, the permissions module 114-1 determines whether the requested operation is allowed based on the permissions data 106-1, 106-2, 106-3, and / or 106-4 for the requesting account. At block 730, the permissions module 114-1 allows the requested operation when the permissions data 106 specifies that the operation is allowed (e.g., based on a lookup of an entry of the permissions data 106 associated with the requested operation). However, if the permissions data 106 does not allow the requested operation, then at block 735, the permissions module 114-1 restricts the execution of the requested operation. For example, if the requested operation is to open an application, then the permissions module 114-1 will restrict the application from being opened. Additionally, if the requested operation is to open an application and / or a particular portion of the application, then at block 740, the permissions module 114-1 and / or the application can modify the GUI of the application to showcase features allowed by the permissions data 106 and disable features not allowed by the permissions data 106.

[0064] Figure 8An embodiment of the logic flow 800 is shown. The logic flow 800 can be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow 800 can include some or all of the operations executed by the applet 103 of the contactless card 101. Embodiments are not limited in this context.

[0065] As shown, the logic flow 800 begins at block 805, where the applet 103 of the contactless card 101 receives an identifier of the requesting device 110. The identifier can be a media access control (MAC) address, a software fingerprint, a device identifier, etc. The requesting device 110 can be any device that includes an instance of the entitlement module 114-1 that is brought within a communication range of the contactless card 101. At block 810, the applet 103 determines that the received identifier is designated as an authorized identifier in the memory 102 of the contactless card. At block 815, the applet 103 generates encrypted data 105 based on a private key, input data, and a cryptographic function. At block 820, the contactless card 101 transmits the encrypted data 105 and the entitlement data 106-1 of the contactless card 101 to the requesting device 110.

[0066] Figure 9 An embodiment of an example computing architecture 900 including a computing system 902 that can be suitable for implementing various embodiments as previously described is shown. In various embodiments, the computing architecture 900 can comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture 900 can be representative of a system implementing one or more components of the system 100, for example. In some embodiments, the computing system 902 can be representative of the contactless card 101, the computing device 110, the authentication server 120, and / or the host system 150 of the system 100, for example. Embodiments are not limited in this context. More generally, the computing architecture 900 is configured to implement all of the logic, applications, systems, methods, apparatuses, and functionality described herein with reference to Figures 1 through Figure 8

[0067] ​As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, hardware, combinations of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 900. For example, a component can be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an executing thread, a program, and / or a computer. For example, both an application running on a server and the server itself can be components. One or more components may reside in a process and / or an executing thread, and components may reside on a single computer and / or be distributed across two or more computers. Furthermore, components can communicatively couple with each other through various types of communication media to coordinate operations. Coordination can include one-way or two-way information exchange. For example, components can transmit information in the form of signals transmitted via a communication medium. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, alternative embodiments may employ data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0068] The computing system 902 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, and so on. However, embodiments are not limited to those implemented by the computing system 902.

[0069] like Figure 9 As shown, computing system 902 includes processor 904, system memory 906, and system bus 908. Processor 904 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 security processors; IBM and Motorola's 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 multiprocessor architectures can also be used as processor 904.

[0070] The system bus 908 provides an interface for system components including, but not limited to, the system memory 906 to the processor 904. The system bus 908 can be any of several types of bus structures including, but not limited 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 can connect to the system bus 908 via an appropriate socket architecture. Example socket architectures can include, but are not limited to, an Accelerated Graphics Port (AGP), Card Bus, (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), and the like.

[0071] The system memory 906 can include various types of computer-readable storage media in the form of one or more higher 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, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information. In Figure 9 In the illustrated embodiment shown in FIG. 10, the system memory 906 can include non-volatile memory 910 and / or volatile memory 912. The basic input / output system (BIOS) can be stored in the non-volatile memory 910.

[0072] The computing system 902 can include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) 914, a magnetic floppy disk drive (FDD) 916 to read from or write to a removable magnetic floppy disk 918, and an optical disk drive 920 to read from or write to a removable optical disk 922 (e.g., a CD-ROM or DVD). The HDD 914, FDD 916 and optical disk drive 920 can be connected to the system bus 908 by a HDD interface 924, an FDD interface 926 and an optical drive interface 928, respectively. The HDD interface 924 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The disk drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. Figure 8 All of the logic, systems, methods, apparatus, and functionality described.

[0073] The drives and their associated computer-readable media, provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units 910, 912, including an operating system 930, one or more application programs 932, other program modules 934, and program data 936. In one embodiment, the one or more application programs 932, other program modules 934, and program data 936 can include, for example, various applications and / or components of the system 100, such as the applet 103, the private key 104, the encrypted data 105, the permissions data 106, the operating system 112, the application 113, the permissions module 114, the authentication application 123, the host system 150, the data 151, and / or the application 152.

[0074] A user can enter commands and information into the computing system 902 through one or more wire / wireless input devices, e.g., a keyboard 938 and a pointing device, such as a mouse 940. Other input devices can include a microphone, an infra-red (IR) remote control, a radio-frequency (RF) remote control, a game pad, a joystick, a stylus, a barcode reader, a plug-in card, a thumbwheel, a touchpad, a touch screen (e.g., capacitive, resistive, etc.), a retina reader, a glove, a graphics tablet, a camera, a microphone, a reading machine, a sensor, a pen, and so forth. These and other input devices are often connected to the processing unit 904 through an input device interface 942 that is coupled to the system bus 908, but can be connected by other interfaces such as a parallel port, a serial port, a game port, a USB port, an IR interface, and so forth.

[0075] A monitor 944 or other type of display device is also connected to the system bus 908 via an interface, such as a video adapter 946. The monitor 944 can be internal or external to the computing system 902. In addition to the monitor 944, a computer typically includes other peripheral output devices, such as speakers, printers, etc.

[0076] The computing system 902 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 948. The remote computer 948 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computing system 902, although, for purposes of brevity, only a memory / storage device 950 is illustrated. The logical connections depicted include wired / wireless connectivity to a local area network (LAN) 952 and / or larger networks, e.g., a wide area network (WAN) 954. Such LAN and WAN networking environments are commonplace in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, such as the Internet. In embodiments, the network 130 of FIG. 1 is one or more of the LAN 952 and the WAN 954.

[0077] When used in a LAN networking environment, the computing system 902 is connected to the LAN 952 through a wired and / or wireless communication network interface or adapter 956. The adapter 956 can facilitate wired / wireless communications to the LAN 952, which can also include a wireless access point disposed therein for communicating with the wireless functionality of the adapter 956.

[0078] When used in a WAN networking environment, the computing system 902 can include a modem 958, or be connected to a communications server on the WAN 954, or have other means for establishing communications over the WAN 954, such as by way of the Internet. The modem 958, which can be internal or external and a wired and / or wireless device, connects to the system bus 908 via the input device interface 942. In a networked environment, program modules depicted relative to the computing system 902, or portions thereof, can be stored in the remote memory / storage device 950. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

[0079] The computing system 902 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.16 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc, on the fly, communication between at least two devices. A Wi-Fi network is a convenient example for a wireless communication network, but other networks can also be used. Wi-Fi networks use radio technologies such as IEEE 802.11x (a, b, g, n, etc.) to transmit data. Wi-Fi networks can be used to connect computers, lap tops, tablets, and mobile devices to the Internet or networks. Wi-Fi networks can also be used to connect devices such as digital cameras, digital media players, and handheld gaming devices to the Internet or to each other. These devices can connect to each other via a direct peer-to-peer connection, or via a local area network (LAN), or via a wide area network (WAN), such as the Internet or a cellular telephone network.

[0080] Figure 10A A contactless card 101 is shown, which can include a payment card, such as a credit card, a debit card, and / or a gift card. As shown, the contactless card 101 can be issued by a service provider 1002, which is displayed on the front or back of the card 101. In some examples, the contactless card 101 is not associated with a payment card, and can include, but is not limited to, an identification card. In some examples, the payment card can include a dual interface contactless payment card. The contactless card 101 can include a substrate 1010, which can include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Example substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 can have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card can additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 101 according to the present disclosure can have different characteristics, and the present disclosure does not require the implementation of a contactless card in a payment card.

[0081] The contactless card 101 can also include identification information 1015, which is displayed on the front and / or back of the card, and a contact pad 1020. The contact pad 1020 can be configured to establish a link with another communication device, such as a mobile device 110, a user device, a smart phone, a laptop, a desktop, or a tablet. The contactless card 101 can also include processing circuitry, antennas, and Figure 10A other components not shown in FIG. 1. These components can be located behind the contact pad 1020 or elsewhere on the substrate 1010. The contactless card 101 can also include a magnetic stripe or tape, which can be located on the back of the card (not shown in FIG. 1). Figure 10A

[0082] As Figure 10B ​As shown, the contact pad 1020 of the contactless card 101 can include processing circuitry 1025 for storing and processing information, including a microprocessor 1030 and a memory 102. It should be appreciated that the processing circuitry 1025 can contain additional components necessary to perform the functions described herein, including a processor, a memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-resistant hardware.

[0083] The memory 102 can be read-only memory, write-once read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 can include one or more of these memories. Read-only memory can be factory programmable read-only memory or one-time programmable memory. One-time programmability provides the opportunity for a write once and then read many times. Write-once / read-many memory can be programmed at some point in time after the memory chip has left the factory. Once the memory is programmed, it can not be rewritten, but it can be read many times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. Read / write memory can also be read many times after leaving the factory.

[0084] The memory 102 can be configured as one or more of applets 103, private keys 104, encrypted data 105, entitlement data 106-1, and one or more user identifiers (IDs) 1007. The one or more applets 103 can include one or more software applications configured to execute on one or more contactless cards, such as Java Card applets. However, it should be appreciated that the applets 103 are not limited to Java Card applets and instead can be any software application operable on a contactless card or other device having limited memory. The user ID 1007 can include a unique alphanumeric identifier assigned to a user of the contactless card 101, and the identifier can distinguish the user of the contactless card from other contactless card users. In some examples, the user ID 1007 can identify both a customer and an account assigned to the customer, and can further identify the contactless card associated with the customer’s account. In some embodiments, the applets 103 can use the customer ID 1007 as an input to a cryptographic algorithm with the private key 104 to generate the encrypted data 105.

[0085] The processor and storage elements of the foregoing example embodiments are described with reference to the contact pad, but the present disclosure is not so limited. It should be appreciated that these elements can be implemented outside of the pad 1020, or completely separate from the pad, or as other elements located outside of the processor 1030 and memory 102 elements within the contact pad 1020.

[0086] In some examples, the contactless card 101 can include one or more antennas 1055. The one or more antennas 1055 can be placed within the contactless card 101 and around the processing circuitry 1025 of the contact pad 1020. For example, the one or more antennas 1055 can be integral with the processing circuitry 1025, and the one or more antennas 1055 can be used with an external boost coil. As another example, the one or more antennas 1055 can be external to the contact pad 1020 and the processing circuitry 1025.

[0087] In embodiments, the coil of the contactless card 101 can act as a secondary coil of an air-core transformer. A terminal can communicate with the contactless card 101 by cutting power or amplitude modulation. The contactless card 101 can use a gap in the power connection of the contactless card to infer data transmitted from the terminal, which can be held functionally by one or more capacitors. The contactless card 101 can communicate by switching a load on the coil of the contactless card or load modulation. Load modulation can be detected by interference in the coil of the terminal. More generally, using the antennas 1055, the processing circuitry 1025, and / or the memory 102, the contactless card 101 provides a communication interface to communicate over NFC, Bluetooth, and / or Wi-Fi communication.

[0088] As explained above, the contactless card 101 can be built on a software platform that can operate on a smart card or other device with limited memory, such as a JavaCard, and can securely execute one or more applications or applets. Applets can be added to the contactless card to provide one-time passwords (OTPs) for multifactor authentication (MFA) in various mobile application-based use cases. The applets can be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (of the device 110), and produce NDEF messages that include password-secured OTPs encoded as NDEF text tags.

[0089] Various embodiments can be implemented using either hardware elements, software elements, or combinations thereof. Examples of hardware elements can include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software can 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. Determining whether an embodiment is implemented using hardware elements and / or software elements can vary in accordance with

[0090] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores" can be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that make the logic or processor. Some embodiments can be implemented, for example, using a machine-readable medium or article which can store an instruction or a set of instructions that, if executed by a machine, can cause the machine to perform a method and / or operations in accordance with the embodiments. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, 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, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable 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 types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. 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, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0091] The foregoing description of exemplary embodiments has been presented for the 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 rather by the claims appended hereto. Future filed applications claiming priority to this application can be filed that claim the disclosed subject matter in a different manner and generally can include any set or series of one or more limitations disclosed herein, disclosed or otherwise taught in different combinations, or disclosed or otherwise taught in different contexts.

Claims

1. A method for managing permissions using contactless cards, comprising: The application receives a first request from the first account for the first account to grant the second account permission to access computing resources and / or perform operations; The application receives a password and the first account's permission data from a contactless card associated with the first account; The application transmits the first request, the password, and the permission data to the authentication server. The application receives a result from the authentication server instructing the authentication server to decrypt the password, and the permission is granted to the second account by the first account; The application receives a permission vector of the second account from the authentication server. The permission vector includes multiple entries, and at least one of the multiple entries reflects the permissions granted by the first account. as well as The application grants the second account access to the computing resources and / or the execution of the operations based on the second account's permission vector.

2. The method of claim 1, wherein the computing resources include applications, and the method further includes: The application disables a first feature based on the first entry of a plurality of entries in the permission vector of the second account.

3. The method according to claim 2, further comprising: The second feature of the application is enabled by the application based on the second entry of a plurality of entries in the permission vector of the second account.

4. The method according to claim 1, further comprising: The application transmits the permission vector of the second account to the contactless card associated with the second account to update the permission data stored in the contactless card associated with the second account.

5. The method according to claim 1, further comprising: The application receives a second request that includes the second account and the second resource; The application determines, based on the permission vector of the second account, that the second account does not have permission to access the second resource; and The application rejects the second request based on the determination that the second account does not have permission to access the second resource.

6. The method according to claim 1, further comprising: The application receives a second request that includes the first account and the second resource; The application receives a second password from the contactless card; The application transmits the second password to the authentication server; The application receives a second result from the authentication server indicating that the authentication server has not decrypted the second password; and The application rejects the second request based on the second result.

7. The method of claim 1, wherein the permission vector is a vector of binary values, each value specifying whether the second account is permitted to access the associated resource and / or perform the associated operation.

8. The method of claim 1, wherein the operations include accessing specific features of the application, accessing specific interfaces of the application, accessing data, and modifying permissions for other users.

9. A computer-readable storage medium for managing permissions using a contactless card, the computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: The application receives a first request from the first account for the first account to grant the second account permission to access computing resources and / or perform operations; The application receives a password and the first account's permission data from a contactless card associated with the first account; The application transmits the first request, the password, and the permission data to the authentication server. The application receives a result from the authentication server instructing the authentication server to decrypt the password, and the permission is granted to the second account by the first account; The application receives a permission vector of the second account from the authentication server. The permission vector includes multiple entries, and at least one of the multiple entries reflects the permissions granted by the first account. as well as The application grants the second account access to the computing resources and / or the execution of the operations based on the second account's permission vector.

10. The computer-readable storage medium of claim 9, wherein the computing resource includes an application, and wherein the instructions further cause the processor to: The application disables a first feature based on the first entry of a plurality of entries in the permission vector of the second account.

11. The computer-readable storage medium of claim 10, wherein the instructions further cause the processor to: The second feature of the application is enabled by the application based on the second entry of a plurality of entries in the permission vector of the second account.

12. The computer-readable storage medium of claim 9, wherein the instructions further cause the processor to: The application transmits the permission vector of the second account to the contactless card associated with the second account to update the permission data stored in the contactless card associated with the second account.

13. The computer-readable storage medium of claim 9, wherein the instructions further cause the processor to: The application receives a second request that includes the second account and the second resource; The application determines, based on the permission vector of the second account, that the second account does not have permission to access the second resource; and The application rejects the second request based on the determination that the second account does not have permission to access the second resource.

14. The computer-readable storage medium of claim 9, wherein the instructions further cause the processor to: The application receives a second request that includes the first account and the second resource; The application receives a second password from the contactless card; The application transmits the second password to the authentication server; The application receives a second result from the authentication server indicating that the authentication server has not decrypted the second password; and The application rejects the second request based on the second result.

15. The computer-readable storage medium of claim 9, wherein the permission vector is a vector of binary values, each value specifying whether the second account is permitted to access the associated resource and / or perform the associated operation.

16. A computing device for managing permissions using a contactless card, comprising: processor; as well as The memory stores instructions that, when executed by the processor, cause the processor to: The application receives a first request from the first account for the first account to grant the second account permission to access computing resources and / or perform operations; The application receives a password and the first account's permission data from a contactless card associated with the first account; The application transmits the first request, the password, and the permission data to the authentication server. The application receives a result from the authentication server instructing the authentication server to decrypt the password, and the permission is granted to the second account by the first account; The application receives a permission vector of the second account from the authentication server. The permission vector includes multiple entries, and at least one of the multiple entries reflects the permissions granted by the first account. as well as The application grants the second account access to the computing resources and / or the execution of the operations based on the second account's permission vector.

17. The computing device of claim 16, wherein the computing resources include applications, and wherein the instructions further cause the processor to: The application disables a first feature based on the first entry of a plurality of entries in the permission vector of the second account.

18. The computing device of claim 17, wherein the instructions further cause the processor to: The second feature of the application is enabled by the application based on the second entry of a plurality of entries in the permission vector of the second account.

19. The computing device of claim 16, wherein the instructions further cause the processor to: transmit the permission vector of the second account to the contactless card associated with the second account by the application, so as to update the permission data stored in the contactless card associated with the second account.

20. The computing device of claim 16, wherein the instructions further cause the processor to: receive a second request from the application including the second account and the second resource; The application determines, based on the permission vector of the second account, that the second account does not have permission to access the second resource; and The application rejects the second request based on the determination that the second account does not have permission to access the second resource.

21. The computing device of claim 16, wherein the instructions further cause the processor to: receive a second request from the application including the first account and the second resource; The application receives a second password from the contactless card; The application transmits the second password to the authentication server; The application receives a second result from the authentication server indicating that the authentication server has not decrypted the second password; and The application rejects the second request based on the second result.

22. The computing device of claim 16, wherein the permission vector is a vector of binary values, each value specifying whether the second account is permitted to access the associated resource and / or perform the associated operation.

Images