Extended provisioning of device tokens with passkeys and device binding consent

Abstract

A computer receives a token pre-provisioning request message from a token requester computer. The token pre-provisioning request message requests the pre-provisioning of a device token to a user device. The computer receives authentication information from the user device via the token requester computer. The computer verifies the authentication information. If the authentication information is valid, the computer activates the device token. The computer activates one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer. The computer generates a token activation message indicating whether each token is active. The computer provides the token activation message to the token requester computer.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 730,799, filed December 11, 2024, the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Tokens can be pre-assigned to a token requester on a user device. The token requester can request the token service computer to pre-assign a token to the user device. During token pre-assignment, the user of the user device can be authenticated. Typically, the user needs to provide consent for each token and needs to be authenticated for each token.

[0004] If multiple tokens are pre-assigned to or activated by a user device, the user will need to perform multiple authentication processes. These authentication processes consume system resources and time, leading to system inefficiency.

[0005] The implementation scheme disclosed herein addresses this problem and other issues, either individually or collectively. Summary of the Invention

[0006] One embodiment relates to a method comprising: receiving, by a computer, a token pre-provisioning request message from a token requester computer, wherein the token pre-provisioning request message requests the pre-provisioning of a device token to a user device; receiving, by the computer, authentication information from the user device via the token requester computer; verifying the authentication information by the computer; activating the device token by the computer if the authentication information is valid; activating one or more additional tokens by the computer based on a predetermined list of additional tokens associated with the token requester computer; generating a token activation message by the computer, the token activation message indicating whether each token is active; and providing the token activation message to the token requester computer by the computer.

[0007] Another embodiment relates to a computer comprising: a processor; and a non-transitory computer-readable medium including code executable by the processor to perform operations including: receiving a token provisioning request message from a token requester computer, wherein the token provisioning request message requests provisioning a device token to a user device; receiving authentication information from the user device via the token requester computer; verifying the authentication information; activating the device token if the authentication information is valid; activating one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer; generating a token activation message indicating whether each token is active; and providing the token activation message to the token requester computer.

[0008] Another embodiment relates to a method comprising: receiving, by a token requester computer, an acceptance message from a user device, wherein the acceptance message includes acceptance of a protocol for pre-configuring a device token and one or more additional tokens; providing, by the token requester computer, a token pre-configuration request message to a token service computer, wherein the token pre-configuration request message requests the pre-configuration of a device token to the user device; receiving, by the token requester computer, authentication information from the user device; providing, by the token requester computer, the authentication information to the token service computer, wherein the token service computer verifies the authentication information, activates the device token, activates one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer, and generates a token activation message indicating whether each token is active; and receiving, by the token requester computer, the token activation message from the token service computer.

[0009] Further details regarding embodiments of this disclosure can be found in the detailed description and accompanying drawings. Attached Figure Description

[0010] Figure 1 A block diagram of an interactive system according to an embodiment is shown.

[0011] Figure 2 A block diagram of the components of a token service computer according to an embodiment is shown.

[0012] Figure 3 A block diagram of the components of a token service computer according to an embodiment is shown.

[0013] Figure 4 A flowchart of a device token pre-configuration method with access key registration according to an embodiment is shown.

[0014] Figure 5 A flowchart of an extended pre-configuration method according to an embodiment is shown. Detailed Implementation

[0015] Before discussing the embodiments of this disclosure, some terms can be described in further detail.

[0016] "User" can include a personal or computing device. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user can be a consumer or customer.

[0017] A “user device” can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Additionally, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by a user, which can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that provides access to a network (such as the Internet or a private network).

[0018] A “user identifier” may include any piece of data capable of identifying a user. A user identifier may include any suitable alphanumeric string. In some embodiments, the user identifier may be derived from user identification information. In some embodiments, the user identifier may include an account identifier associated with the user.

[0019] "Interaction" can include mutual interaction or influence. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Exemplary interactions include transactions between two parties and data exchange between two devices. In some embodiments, interaction can include a user requesting access to secure data, secure web pages, secure locations, etc. In other embodiments, interaction can include payment transactions, in which two devices may interact to facilitate payment.

[0020] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets, such as buildings or documents. Examples of credentials can include passwords, passcodes, or confidential messages. In another example, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with that account). This information can be directly related to the account or derived from account-related information. Examples of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some implementations, credentials can be considered sensitive information.

[0021] A "token" can include alternative data elements representing other information. Tokens can be generated by trusted entities. Tokens can represent other information, such as sensitive information used for authentication, authorization, or interaction (e.g., payment account numbers, credentials, or identifiers). Tokens can be uniquely associated with a user, device, account, or interaction and can be designed to facilitate secure interaction while preventing the exposure of original sensitive information. Tokens can be bound to a specific device or account, can be revocable, and are typically valid within the domain of the issuing system or network.

[0022] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation agents, government entities, venue and residential operators, etc.

[0023] A “merchant” can typically be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0024] An "acquiring party" can typically be a business entity that has a business relationship with a particular merchant or other entity (e.g., a commercial bank). Some entities can perform both issuing and acquiring functions. Some implementations can encompass such a single entity as an issuing-acquiring party. The acquiring party can operate an acquiring party computer, which is also generally referred to as a "transfer computer."

[0025] An "authorizing entity" can be the entity making the authorization request. Examples of authorizing entities include publishers, government agencies, document repositories, access administrators, etc.

[0026] "Issuer" can include commercial entities that maintain user accounts (e.g., banks). Issuers can also issue payment credentials to consumers that are stored on user devices such as cell phones, smart cards, tablets, or laptops.

[0027] "Biometric information" can be any human characteristic that is unique to an individual. For example, biometrics can be a person's fingerprints, voice samples, face, DNA, retina, etc.

[0028] A "biometric reader" can include a device for capturing data from a person's biometric sample. Examples of biometric readers can include fingerprint readers, forward-facing cameras, microphones, and iris scanners.

[0029] A “biometric sample” can include data obtained by a biometric reader. This data can be an analog or digital representation of the user’s biometric information, generated before determining the different features needed for a match. For example, a biometric sample of a user’s face could be image data. In another example, a biometric sample of a user’s voice could be audio data.

[0030] A "biometric template" or "biometric sample template" can include a file containing different characteristics extracted from a biometric sample, which can be used during the biometric authentication process. For example, a biometric template can be a binary mathematical file that represents the unique characteristics of an individual's fingerprint, eyes, hands, or voice required to perform accurate authentication of the individual.

[0031] "Authentication information" can include data used to verify identity. Authentication information can include data, credentials, or evidence submitted by a user or device for the purpose of verifying identity in conjunction with the authentication process. Authentication information can include, for example, biometric templates, one-time passwords, passcodes, encrypted credentials, security tokens, personal identification numbers (PINs), or knowledge-based information. Authentication information can be entered by the user or provided by the device and can be evaluated by a computer (e.g., an authentication computer, a token service computer, etc.) using comparison, cryptographic verification, or other suitable techniques to determine whether authentication criteria are met.

[0032] The term "verification" and its derivatives can include the process of using information to determine whether an underlying subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0033] A “processor” can include means for processing things. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon and / or XScale; and / or similar processors.

[0034] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transient computer-readable media whose storage can be executed by a processor to implement desired methods. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0035] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0036] A key based on the Online Fast Identity (FIDO) standard can replace a password and be used to securely authenticate users. FIDO authentication uses standard public-key cryptography to provide authentication. During registration with an online service, the user device creates a new cryptographic key pair bound to the web service domain. The user device retains its private key and registers its public key with the online service. These cryptographic key pairs, known as the key pair, are unique to each online service.

[0037] With FIDO, a user's device must prove ownership of the private key by signing the challenge to complete the login. This can occur once a user logs in locally on their device via biometrics, a local PIN, or by touching a FIDO security key. Login is completed via a challenge response from the user's device and the online service; the service neither sees nor stores the private key.

[0038] Embodiments of this disclosure provide systems and methods for provisioning multiple tokens to a user device while requiring only a single authentication process. Traditionally, when provisioning or activating multiple tokens on a device, a user must perform a separate authentication step for each token, which can be resource-intensive and inefficient. The embodiments provide a technical solution to this inefficiency by enabling the provisioning of several tokens through a single authentication event.

[0039] To facilitate the creation of additional token types, the system utilizes device tokens as the initiator of subsequent provisioning requests. Specifically, the token service computer can use device tokens to initiate token-to-token provisioning requests on behalf of the token requester computer or user device. This process enables the generation of multiple tokens for various token types, such as e-commerce tokens, archive card tokens, etc. Upon successful token provisioning, the token requester computer can be notified of the creation of these additional tokens.

[0040] After completing access key registration, the FIDO (Fast Identity Online) server can bind newly created additional tokens to the originating device, ensuring that each additional token is securely associated with the original device to which the initial device token was pre-configured. The device identifier generated during FIDO registration as part of access key creation allows the system to reliably bind all pre-configured tokens to the same device.

[0041] The process of collecting user consent during device token pre-provisioning has been enhanced to support the pre-provisioning of additional tokens attached to the token requester's computer. By obtaining combined user consent at the outset, the token service computer is authorized to pre-provision additional tokens associated with the token requester and bind them to the same device, provided that the user has completed access key registration.

[0042] Password authentication is an authentication method developed by the Fast Identity Online (FIDO) consortium, which utilizes cryptographic keys generated directly on the user's device. This method provides robust authentication without relying on traditional cryptographic mechanisms. Password authentication ensures strong and secure authentication of the device token pre-provisioning and binding process by leveraging cryptographic key pairs to provide phishing-resistant security.

[0043] Figure 1 A system 100 according to an embodiment of the present disclosure is shown. The system 100 includes a user device 102, an access device 104, a resource provider computer 106, a transmission computer 108, a network processing computer 110, an authorization entity computer 112, a token requester computer 114, an authentication server 116, and a token service computer 118.

[0044] User device 102 can operationally communicate with access device 104, resource provider computer 106, token requester computer 114, and authentication server 116. Access device 104 can operationally communicate with resource provider computer 106. Transmission computer 108 can operationally communicate with resource provider computer 106 and network processing computer 110. Authorization entity computer 112 can operationally communicate with network processing computer 110 and token service computer 118. Token service computer 118 can operationally communicate with network processing computer 110, token requester computer 114, and authentication server 116. Token requester computer 114 can operationally communicate with authentication server 116.

[0045] To simplify the explanation, Figure 1 A specific number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown in the document, whether few or many.

[0046] Secure communication protocols such as, but not limited to, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), SSL, and ISO (e.g., ISO 8583) can be used for transmission. Figure 1 The system 100 illustrated in the diagram represents messages between devices. The communication network may include any and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); and so on. The communication network may use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channels may include secure communication channels, which may be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0047] User device 102 may include one or more computers, laptops, tablets, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), personal digital assistants (PDAs), Internet of Things (IoT) devices, etc. User device 102 may initiate interactions (e.g., transactions) with resource provider computers and / or access devices. For example, user device 102 may select one or more items for interaction at a resource provider location (e.g., a grocery store). During checkout, the user may be instructed to tap (e.g., enter near-field communication range) user device 102 towards access device 104. As another example, a user may initiate checkout using a website hosted by resource provider computer 106 to obtain one or more items.

[0048] Access device 104 may include a device operated by a resource provider. For example, access device 104 may include a mobile device, a POS terminal, a laptop computer, etc. Access device 104 may communicate with another device (e.g., user device 102) to perform an interaction. During the interaction, access device 104 may receive credentials from the user device and may provide interaction data to resource provider computer 106 for authorization of the interaction. In some embodiments, access device 104 may generate an authorization request message that includes at least the interaction data. Access device 104 may provide the authorization request message to resource provider computer 106.

[0049] Resource provider computer 106 may include any suitable computing device operated by a resource provider (e.g., a merchant). In some embodiments, resource provider computer 106 may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a merchant). In some embodiments, resource provider computer 106 may be configured to send data to network processing computer 110 via transport computer 108 as part of a payment verification and / or authentication process for a transaction between a user (e.g., a customer) and the resource provider. Resource provider computer 106 may also be configured to generate authorization request messages for transactions between the resource provider and the user, and / or route authorization request messages to authorization entity computer 112 for transaction processing.

[0050] The transmission computer 108 may include a server computer. The transmission computer 108 may be associated with an acquirer, which may be an entity with a business relationship with a particular merchant or other entity (e.g., a commercial bank). Some entities may perform both issuer and acquirer functions. Some implementations may encompass such a single entity as an issuer-acquirer.

[0051] Network processing computer 110 may include a server computer. Network processing computer 110 may be located between transmission computer 108 and authorization entity computer 112. Network processing computer 110 may include a data processing subsystem, a network, and operations for supporting and transmitting authorization services, exception document services, and clearing and settlement services. For example, network processing computer 110 may include (e.g., via an external communication interface) a server and an information database coupled to the network interface. Network processing computer 110 may represent a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes a VIP system (Visa Integrated Payment System) for processing authorization requests and a Base II system for performing clearing and settlement services. Network processing computer 110 may use any suitable wired or wireless network, including the Internet.

[0052] Authorized entity computer 112 may include a server computer operated by the authorized entity. Authorized entity computer 112 may be associated with an authorized entity, which may be the entity that issued the authorization request. Examples of authorized entities may be issuers, which typically refer to commercial entities (e.g., banks) that maintain user accounts. Issuers may also issue and manage accounts associated with user device 102.

[0053] Token requester computer 114 may include a computer that requests tokens. Token requester computer 114 may request tokens from token service computer 118. Token requester computer 114 may request tokens associated with user device 102. Token requester computer 114 may be a digital wallet computer. In some embodiments, token requester computer 114 may be resource provider computer 106.

[0054] During an interaction involving user device 102, for example, token requester computer 114 may request a token from token service computer 118 associated with user device 102.

[0055] Authentication server 116 may include a computer capable of performing authentication. Authentication server 116 may maintain the association between a master account (PAN) and a device. For example, authentication server 116 may link an account to a device identifier. Authentication server may be a FIDO server capable of performing FIDO-based authentication.

[0056] The token service computer 118 may include a computer that maintains tokens associated with users on user devices. The token service computer 118 can generate and activate tokens. In some embodiments, the token service computer 118 may be represented by a VISA token service computer or a token service computer from an equivalent provider.

[0057] Figure 2 A block diagram of a token service computer 118 according to an embodiment is shown. The exemplary token service computer 118 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include one or more modules. The computer-readable medium 208 may include a token activation module 208A, a token binding module 208B, and a communication module 208C.

[0058] Memory 202 can be used to store data and code. For example, memory 202 can store tokens, access keys, token maps, etc. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0059] Computer-readable medium 208 may include code executable by processor 204 for performing a method comprising: receiving, by a computer, a token pre-provisioning request message from a token requester computer, wherein the token pre-provisioning request message requests the pre-provisioning of a device token to a user device; receiving, by the computer, authentication information from the user device via the token requester computer; verifying, by the computer, the authentication information; activating, by the computer, the device token if the authentication information is valid; activating, by the computer, one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer; generating, by the computer, a token activation message indicating whether each token is active; and providing, by the computer, the token activation message to the token requester computer.

[0060] The token activation module 208A may include code or software executable by the processor 204 for activating a token. The token activation module 208A, in conjunction with the processor 204, can generate and activate a token for a device. The token activation module 208A, in conjunction with the processor 204, can activate device tokens and can activate one or more additional tokens for a device (e.g., a user device). Once activated, the token is recognized as valid by the system and is permitted to be used for security operations such as payment authorization, user authentication, or access control.

[0061] In some embodiments, upon receiving a request to activate a token, the token activation module 208A, in conjunction with the processor 204, can perform a series of operations, including but not limited to verifying the token provisioning status, verifying any authentication requirements, verifying any authorization requirements, and updating the token's status to indicate that it is active and available for use.

[0062] The token binding module 208B may include code or software executable by the processor 204 for binding tokens. The token binding module 208B, in conjunction with the processor 204, can bind (e.g., link) a token to data. The token binding module 208B, in conjunction with the processor 204, can bind a token to a device via a device identifier. The token binding module 208B, in conjunction with the processor 204, can bind a token to an account associated with a user and / or a user device.

[0063] For example, in some embodiments, while user authentication and security registration (e.g., FIDO access key registration) are completed with the authentication server, the token binding module 208B, in conjunction with the processor 204, can continue to bind one or more additional tokens to the user device. This binding process can be a silent binding process, whereby user authentication is not required for each of the one or more additional tokens due to the prior user authentication and security registration. The binding process can ensure that each token is specifically linked to the authenticated device and can only be accessed or used by the device.

[0064] The communication module 208C may include code or software executable by the processor 204 for communicating with other devices. The communication module 208C may be configured or programmed to perform some or all of the functions associated with receiving, sending, and generating electronic messages for transmission via the token service computer 118. Figure 1 Any device shown or from Figure 1 The token service computer 118 may transmit any of the devices shown. When the token service computer 118 receives an electronic message via network interface 206, it may pass the message to communication module 208C. Communication module 208C, in conjunction with processor 204, may identify and parse relevant data based on the specific messaging protocol used. For example, the received information may include identification information, authorization information, request information, response information, and / or any other information that the token service computer 118 may utilize. Communication module 208C, in conjunction with processor 204, may transmit any received information to the appropriate module within network processing computer 108. Communication module 208C, in conjunction with processor 204, may receive information from one or more modules within network processing computer 108 and generate electronic messages in an appropriate data format, conforming to a transmission protocol, such that the messages may be sent to one or more entities within system 100. The electronic message may then be passed to network interface 206 for transmission.

[0065] Network interface 206 may include an interface that allows token service computer 118 to communicate with external computers. Network interface 206 enables token service computer 118 to transmit data to and from another device (e.g., network processing computer 110, authorization entity computer 112, token requester computer 114, authentication server 116, etc.). Some examples of network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot, and a card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transferred through network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may contain data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0066] Figure 3 A block diagram of a token requester computer 114 according to an embodiment is shown. The exemplary token requester computer 114 may include a processor 304. The processor 304 may be coupled to a memory 302, a network interface 306, and a computer-readable medium 308. The computer-readable medium 308 may include one or more modules. The computer-readable medium 308 may include an authentication initiation module 308A and a communication module 308B.

[0067] Memory 302 can be used to store data and code. For example, memory 302 can store tokens, messages, encryption keys, interactive data, etc. Memory 302 can be coupled internally or externally to processor 304 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0068] Computer-readable medium 308 may include code executable by processor 304 for performing a method comprising: receiving, by a token requester computer, an acceptance message from a user device, wherein the acceptance message includes an acceptance of a protocol for a device token and an acceptance of the provision of one or more additional tokens; providing, by the token requester computer, a token provision request message to a token service computer, wherein the token provision request message requests the provision of a device token to the user device; receiving, by the token requester computer, authentication information from the user device; providing, by the token requester computer, the authentication information to the token service computer, wherein the token service computer verifies the authentication information, activates the device token, activates one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer, and generates a token activation message indicating whether each token is valid; and receiving, by the token requester computer, the token activation message from the token service computer.

[0069] The authentication initiation module 308A may include code or software executable by the processor 304 for initiating authentication. The authentication initiation module 308A, in conjunction with the processor 304, can communicate with an authentication server to initiate authentication for a user and / or user device. The authentication initiation module 308A, in conjunction with the processor 304, can communicate with the authentication server using a URL (Uniform Resource Locator) or other suitable web-based communication identification means. The authentication initiation module 308A, in conjunction with the processor 304, can provide the authentication server with a user device identifier, user identifier, account, or other suitable identification information, wherein the authentication server can authenticate the user and / or user device.

[0070] The communication module 308B may include code or software that can be executed by the processor 304 to communicate with other devices. The communication module 308B may be similar to the communication module 208C, and will not be repeated here.

[0071] Network interface 306 may be similar to network interface 206, and will not be repeated here.

[0072] Figure 4 A flowchart illustrating a device token pre-provisioning method with access key registration according to an embodiment is shown. This method can be performed, for example, when adding digital credentials such as cards to a digital wallet maintained by the token requester computer 114 and when performing access key registration. Figure 4 The method described. In some embodiments, reference is made to... Figure 4 The token described can be pre-generated and then bound to user device 102 after registration (e.g., FIDO registration).

[0073] Prior to step 402, user device 102 may access a website provided by token requester computer 114. User device 102 may access an online platform, such as a website or application, provided by token requester computer 114. This initial access allows user device 102 to interact with token requester computer 114, thereby facilitating the presentation of relevant agreements, terms and conditions, and guiding the user through the device token pre-provisioning and access key registration workflow.

[0074] In step 402, user device 102 may provide an acceptance message to token requester computer 114. The acceptance message may include acceptance of a device token provisioning protocol. The protocol may include terms and conditions, which may include provisioning of other token types. The acceptance message may be an acceptance protocol message. The acceptance message may include a request for a token. The acceptance message may include information identifying user device 102, such as a digital signature, device identifier, user identifier, etc.

[0075] In step 404, after receiving the acceptance message, the token requester computer 114 may generate a token pre-configuration request message. The token pre-configuration request message may include a request to pre-configure a device token. The token pre-configuration request message may include information identifying the user device 102. The token requester computer 114 may provide the token pre-configuration request message to the token service computer 118.

[0076] In step 406, after receiving the token pre-provisioning request message, the token service computer 118 may provide the token pre-provisioning request message or a derivative thereof to the authorization entity computer 112. The token service computer 118 may provide the token pre-provisioning request message to the authorization entity computer 112 via an ISO 0100 message or via an application programming interface (API).

[0077] In step 408, the authorizing entity computer 112 may generate a token pre-configuration response message. The token pre-configuration response message may include an authentication request. For example, the authentication request may include an "upgrade" message that requests the token service computer 118 to perform or initiate an upgrade authentication process before pre-configuring a token to the user device 102.

[0078] Authorized entity computer 112 may provide a token pre-configuration response message to token service computer 118 in response to a token pre-configuration request message.

[0079] In step 410, after receiving the token pre-configuration response message, the token service computer 118 may generate a request to obtain a verification method message. The request to obtain a verification method message may be a request to obtain the cardholder verification method (CVM).

[0080] The token service computer 118 can provide the verification method message to the authorized entity computer 112.

[0081] In step 412, the authorizing entity computer 112 may obtain one or more authentication methods in response to the authentication method message. Authentication methods may include, for example, a one-time passcode (OTP), biometric authentication, or other identifying CVMs. The authorizing entity computer 112 may provide the one or more authentication methods to the token service computer 118.

[0082] In step 414, after receiving the verification method, the token service computer 118 may provide the verification method to the token requester computer 114 (e.g., in a verification method list format).

[0083] In step 416, after receiving the verification method from the token service computer 118, the token requester computer 114 may present the verification method to the user device 102. The token service computer 118 may provide the verification method to the user device 102 via a webpage.

[0084] In step 418, the user of user device 102 can select one of the one or more authentication methods. User device 102 can then provide the selected authentication method to token requester computer 114. For example, the user can select a one-time password authentication method.

[0085] In step 420, after receiving the selected verification method, the token requester computer 114 may generate an identification and verification (ID&V) message that includes the selected verification method. The token requester computer 114 may provide the selected verification method to the token service computer 118 in the ID&V message.

[0086] The token service computer 118 can also present input fields in a webpage, which allow user device 102 to enter authentication information (e.g., a password) to authenticate the user and / or user device 102. The user can enter authentication information during step 426 below.

[0087] In step 422, after receiving the selected verification method, the token service computer 118 may initiate the selected verification method. In some embodiments, the token service computer 118 may generate authentication information for the authentication process. For example, if the selected verification method is OTP, the token service computer 118 may generate authentication information as a password for the one-time password verification method.

[0088] After initiating the selected authentication method, the token service computer 118 can notify the authorized entity computer 112 of the selected authentication method. For example, if the selected authentication method is OTP, the token service computer 118 can provide the password to the authorized entity computer 112.

[0089] In step 424, the authorizing entity computer 112 may communicate with the user device 102 regarding the selected authentication method. For example, the authorizing entity computer 112 may directly provide the password (e.g., authentication information) to the user device 102. The authorizing entity computer 112 may provide the password to the user device 102 in a communication channel separate from the communication channel formed between the user device 102 and the token requester computer 114. For example, the authorizing entity computer 112 may provide the password to the user device 102 via Short Message Service (SMS), email, or other communication channels.

[0090] In step 426, after receiving the password from the authorizing entity computer 112, the user device 102 can provide authentication information (e.g., the password or other forms of authentication data, such as a biometric template) to the token requester computer 114 for user authentication. In this example, only the user should have access to another communication channel with the authorizing entity computer 112, and is therefore the only entity capable of obtaining the password. For example, the user can enter the password into a password input field provided by the token requester computer 114 on a webpage.

[0091] Authentication information may include any data, credentials, or evidence submitted by the user or user device 102 to verify identity (e.g., the user's identity, the user device's identity, etc.). Authentication information may include, for example, biometric templates, one-time passwords, passphrases, encrypted credentials, security tokens, personal identification numbers (PINs), or knowledge-based information.

[0092] Biometric templates may include digitally encoded representations of biometric features, such as fingerprints, facial features, iris patterns, voiceprints, or other physiological or behavioral traits. Biometric templates can be used in the biometric authentication process to verify a user's identity by comparing the presented biometric template with stored reference data (e.g., stored biometric templates). One-time passwords may be time-limited or event-based numeric or alphanumeric codes generated for one-time authentication. One-time passwords may be delivered to the user via secure channels such as SMS, email, or dedicated applications and are used to confirm ownership of a specific device or communication method. Passwords or passphrases may include secret alphanumeric strings known only to the user and can be used to authenticate the user's identity in password-based systems. Encryption credentials may include data such as digital signatures, private or public key pairs, or cryptographic tokens generated and used within an encryption authentication framework (e.g., FIDO, PKI, etc.). Security tokens may include physical or virtual devices (e.g., smart cards, USB keys, mobile application tokens, etc.) that can generate and / or store authentication codes or credentials. Personal identification numbers may include digital codes used for authentication. Knowledge-based information may include answers to personal questions or other information known only to authorized users.

[0093] In step 428, after receiving authentication information (e.g., password), the token requester computer 114 may provide the authentication information to the token service computer 118.

[0094] In step 430, after receiving the authentication information, the token service computer 114 may perform the following steps as described in the reference. Figure 5 The described extended pre-configuration method. Figure 5 A flowchart of an extended pre-configuration method according to an embodiment is shown.

[0095] The token service computer 114 can verify the received authentication information (e.g., password, biometric template, etc.). The token service computer 114 can compare the received authentication information with generated or otherwise stored authentication information. For example, the token service computer 114 can compare the received biometric template with a stored biometric template. As another example, the token service computer 114 can compare the received password with a generated password. If the received password and the generated password do not match, the token service computer 114 can terminate the process. If the received password and the generated password match, the token service computer 114 can proceed to step 502.

[0096] In step 502, the token service computer 114 may activate (e.g., create) a device token for the token requester computer 114. The device token may be a token associated with the user device 102 for the token requester computer 114. The device token may uniquely identify the user device 102. The token requester computer 114 may store device tokens associated with data about the user device 102 (e.g., user device account, user device identifier, user account, user identifier, user device public key, etc.).

[0097] In step 504, after activating the device token, the token requester computer 114 may generate an additional token pre-configuration request message that requests authorization to pre-configure an additional token. In some embodiments, the token requester computer 114 may generate one or more additional token pre-configuration request messages for one or more additional tokens.

[0098] Reference Figures 4 to 5 Prior to the described method, the token service computer 118 may determine additional tokens based on a list of additional tokens requested by the token requester computer 114 or a computer associated with it. The token service computer 118 may generate one or more additional token provisioning request messages based on a predetermined list of additional tokens associated with the token requester computer.

[0099] The token requester computer 114 may provide an additional token provisioning request message to the authorizing entity computer 112. In some embodiments, the token requester computer 114 may provide one or more additional token provisioning request messages to the authorizing entity computer.

[0100] In step 506, after receiving the additional token pre-configuration request message, the authorizing entity computer 112 can determine whether to authorize the token service computer 118 to pre-configure one or more additional tokens. The authorizing entity computer 112 can generate an additional token pre-configuration response message indicating whether each additional token has been authorized.

[0101] In some embodiments, the authorizing entity computer 112 may generate an additional token provisioning response message for each of the one or more additional tokens requested to be provisioned. In other embodiments, the authorizing entity computer 112 may generate a single aggregated additional token provisioning response message.

[0102] Authorized entity computer 112 can provide an additional token provisioning response message to token service computer 118.

[0103] In step 508, after receiving one or more additional token provisioning response messages, the token service computer 118 may generate any additional token if authorized by the authorized entity computer 112. For example, the token service computer 118 may activate one or more additional tokens.

[0104] At this point, device tokens and any additional tokens can be created and activated, but may not yet be bound to user device 102. The system can... Figure 4 The binding of the device to the token is completed during steps 432-454.

[0105] return Figure 4 At point 432, after activating the device token and one or more additional tokens, the token service computer 118 may generate a token activation message for each generated token. The token activation message may include initiation information indicating how to initiate the token binding process. The initiation information may include a URL. For example, the token activation message may include a URL to the authentication server 116.

[0106] The token service computer 118 can provide a token activation message to the authorized entity computer 112.

[0107] For example, if the token service computer 118 generates a device token and an additional token, the token service computer 118 can provide the authorization entity computer 112 with a token activation message for the device token and the additional token. In some embodiments, each token activation message can be provided to the authorization entity computer 112 separately. In other embodiments, each token activation message can be provided to the authorization entity computer 112 in a single aggregated token activation message.

[0108] In step 434, the token service computer 118 may provide a token activation message or a single aggregated token activation message to the token requester computer 114.

[0109] In step 436, after receiving a token activation message or a single aggregated token activation message, the token requester computer 114 may notify the user device 102 of the activated token. For example, in some embodiments, the token requester computer 114 may provide the user device 102 with a token activation message or a single aggregated token activation message. In other embodiments, the token requester computer 114 may generate a token activation notification and may provide the token activation notification to the user device 102.

[0110] In step 438, the token requester computer 114 may initiate user authentication to the authentication server 116. The token requester computer 114 may initiate user authentication using a URL, which may be provided in a token activation message used to activate a device token or in a single aggregated token activation message. The token requester computer 114 may provide the authentication server 116 with a user device identifier, user identifier, account, or other suitable identification information.

[0111] In step 440, after receiving a message initiating user authentication, the authentication server 116 may request the user device 102 to perform a registration process. The registration process may include performing authentication to register the user and / or user device 102.

[0112] The authentication server 116 can generate challenges (e.g., authentication challenges) and can provide these challenges to the user device 102. The challenge can be a password challenge. In some embodiments, the challenge may include a user identifier and a random number. The user identifier can be an identifier that uniquely identifies the user and / or user device 102. For example, the user identifier can be a device identifier, a token, a credential, or other identifier such as an email address. The random number can be a one-time password value that can be updated for each challenge to prevent replay attacks.

[0113] As an illustrative example, a challenge can be a random number concatenated with any other suitable data, such as a user identifier. Once user device 102 receives the challenge, and once user device 102 has authenticated the user, user device 102 can use the encryption key to generate a signature for the challenge. When authentication server 116 receives the signed challenge (also known as an authentication assertion), authentication server 116 can verify the signature using the encryption key corresponding to the encryption key used to sign the challenge. Only user device 102 should have access to the signing encryption key; therefore, by verifying the signature, authentication server 116 can determine that the challenge has been signed by user device 102. Authentication server 116 can also further verify that the challenge in the signed challenge matches the sent challenge (e.g., including the same random number and other data).

[0114] In step 442, after receiving the challenge, user device 102 can perform an authentication process to authenticate the user of user device 102 based on the challenge. For example, user device 102 can prompt the user to input biometrics, such as fingerprints, facial features, etc. If the user is authenticated, user device 102 can generate an authentication assertion, which may include a signature. For example, the signature may be a signature created by the user device's cryptographic key through a signature operation on the challenge.

[0115] In some embodiments, the authentication process may include a FIDO authentication process, and the authentication assertion may be a FIDO authentication assertion.

[0116] In some embodiments, user device 102 may perform FIDO registration. WebAuthn can be used to perform FIDO registration. FIDO registration may include a process of making the user known to the authenticator. FIDO registration may include biometric registration, or may involve processes such as acquiring ownership of a non-biometric encrypted storage device and setting a PIN or password for the non-biometric encrypted storage device. Registration may occur as part of the FIDO protocol process, or it may occur outside the FIDO context used by a multipurpose authenticator. During FIDO registration, user device 102 may generate a FIDO proof binary large object (e.g., in a metadata binary large object file) and a public key. The public key may be a FIDO public key.

[0117] In step 444, after performing the registration step, user device 102 may provide an authentication assertion to authentication server 116 (e.g., which may include a FIDO proof binary large object, a public key, and a device identifier) ​​via an iFrame embedded in a website hosted by token requester computer 114 or otherwise. The device identifier can uniquely identify user device 102.

[0118] In step 446, authentication server 116 can verify the authentication assertion registered for user device 102. For example, authentication server 116 can use the public key to verify the signature in the authentication assertion. If the authentication assertion is valid, authentication server 116 can store the authentication assertion and the public key in a database.

[0119] The authentication server 116 can use a device identifier and a reference to the token pre-configured via an iFrame to bind an account (e.g., a primary account) associated with the user to the user device 102. This associates the device token with the user device 102 and the account. During later interactions, the authentication server 116 can determine the account from the received device token. This allows the authentication server 116 to store the account instead of the token requester computer 114 storing the account.

[0120] The authentication server 116 can create binding mappings for device identifiers, accounts, public keys, authentication methods, and timestamps.

[0121] In step 448, the authentication server 116 may notify the token service computer 118 of the binding of an account (e.g., a primary account) to the user device 102. The authentication server 116 may provide the token service computer 118 with a binding notification message, indicating the binding of the account to the user device 102.

[0122] In step 450, the token service computer 118 may perform a silent binding operation with the user device 102 for each additional token. The token service computer 118 may bind the additional tokens to the user device 102 without performing an authentication process for each token binding. The token service computer 118 may rely on the binding performed by the authentication server 116 as proof of authentication for binding the additional tokens to the user device 102.

[0123] In step 452, after each of the additional tokens is bound to the user device 102, the token service computer 118 may generate a device binding notification for the additional tokens and provide it to the authorizing entity computer 112.

[0124] In step 454, the token service computer 118 may provide a batch file to the token requester computer 114. The batch file may include a binding result notification for each attached token and device token.

[0125] The embodiments disclosed herein provide several technical advantages. Conventionally, for each token pre-configured and associated with a user device, a different authentication process must be performed to verify that the user has legitimately requested the pre-configuration of the specific token. This requirement for multiple repetitive authentication processes introduces inefficiency, increases system resource consumption, and can potentially degrade the overall user experience due to the additional time and effort required from the user.

[0126] In contrast, the embodiments described herein enable the provisioning of device tokens and one or more additional tokens through a single, unified user authentication process. By leveraging this single authentication mechanism, the system achieves enhanced efficiency, reduces computational and network overhead, and simplifies the user experience. This approach not only minimizes redundancy in security checks but also maintains authentication standards by ensuring that all provisioned tokens are securely associated with the authenticated user and user device.

[0127] Although the steps in the flowcharts and process flows described above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and these steps may still be within the scope of embodiments of the invention.

[0128] Any software component or function described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, and the like. The computer-readable medium may be any combination of such storage or transmission devices.

[0129] Such programs can also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable media can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0130] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but rather by reference to the pending claims and their full scope or equivalents.

[0131] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0132] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one.”

Claims

1. A method comprising: The computer receives a token pre-assignment request message from the token requester's computer, wherein the token pre-assignment request message requests the pre-assignment of a device token to the user device. The computer receives authentication information from the user device via the token requester's computer; The computer verifies the authentication information; If the authentication information is valid, the device token is activated by the computer; One or more additional tokens are activated by the computer based on a predetermined list of additional tokens associated with the token requester's computer; The computer generates a token activation message, which indicates whether each token is active. as well as The computer provides the token activation message to the token requester computer.

2. The method of claim 1, wherein the computer is a token service computer, and wherein the token pre-provisioning request message is received during an interaction between the token requester computer and the user device.

3. The method according to claim 1, wherein after receiving the token pre-configuration request message, the method further comprises: The computer provides the token pre-configuration request message to the authorized entity computer; The computer receives a token pre-configuration response message from the authorized entity computer in response to the token pre-configuration request message, wherein the token pre-configuration response message instructs the computer to initiate authentication; The computer generates the verification method message; The computer provides the verification method message to the authorized entity computer, wherein the authorized entity computer determines one or more verification methods for pre-configuring the device token; The computer receives the one or more verification methods from the authorized entity computer; as well as The computer provides the one or more verification methods to the token requester computer.

4. The method of claim 3, wherein the token requester computer provides the one or more authentication methods to the user device, wherein the user of the user device selects a selected authentication method from the one or more authentication methods.

5. The method of claim 4, wherein the selected authentication method is used to authenticate the user and / or the user device.

6. The method according to claim 4, wherein the selected verification method is a one-time password verification method.

7. The method of claim 1, wherein after activating the device token, the method further comprises: The computer generates one or more additional token pre-configuration request messages for one or more additional tokens; The computer provides the one or more additional token provisioning request messages to the authorized entity computer, wherein the authorized entity computer determines whether to authorize each additional token in the one or more additional token provisioning request messages. as well as The computer receives one or more additional token provisioning response messages from the authorized entity computer.

8. The method of claim 7, wherein each of the one or more additional token provisioning response messages indicates whether each additional token is authorized for activation.

9. The method of claim 1, wherein the token activation message is an aggregated token activation message, and wherein the token requester computer uses the URL in the aggregated token activation message to initiate user authentication to the authentication server.

10. The method of claim 9, wherein the authentication server performs an authentication process with the user device to bind an account to the user device.

11. The method of claim 10, further comprising: The computer receives a binding notification message from the authentication server, wherein the binding notification message indicates that the account has been bound to the user device; as well as For each of the one or more additional tokens, the computer binds the additional token to the user device without performing an authentication process.

12. The method of claim 11, further comprising: The computer binds a notification to each of the one or more additional tokens generated by the additional token generation device. The computer provides the device binding notification to the authorized entity computer; The computer generates a batch file, which includes a binding result notification for each additional token and the device token; as well as The computer provides the batch file to the token requester computer.

13. A computer, comprising: processor; and A non-transient computer-readable medium, the non-transient computer-readable medium including code executable by the processor to perform a method comprising: Receive a token pre-assignment request message from the token requester computer, wherein the token pre-assignment request message requests the pre-assignment of a device token to the user device. Authentication information is received from the user device via the token requester's computer; Verify the authentication information; If the authentication information is valid, then the device token is activated; One or more additional tokens are activated based on a predetermined list of additional tokens associated with the token requester's computer; Generate a token activation message indicating whether each token is active; and The token activation message is provided to the token requester's computer.

14. The computer of claim 13, wherein after activating the device token, the method further comprises: Generate one or more additional token provisioning request messages for one or more additional tokens; The one or more additional token pre-configuration request messages are provided to the authorized entity computer, wherein the authorized entity computer determines whether to authorize each additional token in the one or more additional token pre-configuration request messages; as well as Receive one or more additional token pre-configuration response messages from the authorized entity computer, each of the one or more additional token pre-configuration response messages indicating whether each additional token is authorized and activated.

15. The computer of claim 13, wherein the computer is a token service computer, wherein the token requester computer initiates user authentication to an authentication server, wherein the authentication server and the user device perform an authentication process, and wherein the method further comprises: Receive a binding notification message from the authentication server, wherein the binding notification message indicates that an account has been bound to the user device; For each of the one or more additional tokens, the additional token is bound to the user device without performing an authentication process; Bind a notification to the additional token generation device; Provide the device binding notification to the authorized entity computer; Generate a batch file, which includes a binding result notification for each attached token and the device token; as well as The batch file is provided to the token requester's computer.

16. The computer of claim 13, wherein the authentication information includes a one-time password or a biometric template, wherein verifying the authentication information includes: The authentication information is compared with the stored authentication information.

17. A method comprising: The token requester computer receives an acceptance message from the user device, wherein the acceptance message includes acceptance of the protocol for the provisioning of a device token and one or more additional tokens; The token requester computer provides a token pre-configuration request message to the token service computer, wherein the token pre-configuration request message requests the pre-configuration of a device token to the user device; The token requester computer receives authentication information from the user device; The token requester computer provides the authentication information to the token service computer, wherein the token service computer verifies the authentication information, activates the device token, activates one or more additional tokens based on a predetermined list of additional tokens associated with the token requester computer, and generates a token activation message indicating whether each token is active. as well as The token requester computer receives the token activation message from the token service computer.

18. The method of claim 17, further comprising: Before receiving the authentication information, the token requester computer receives one or more verification methods from the token service computer; The token requester computer provides the one or more authentication methods to the user device, wherein the user of the user device selects a selected authentication method from the one or more authentication methods; The selected verification method is received by the token requester computer from the user device; as well as The selected verification method is provided by the token requester computer to the token service computer.

19. The method of claim 18, wherein the selected authentication method is used to authenticate the user and / or the user device.

20. The method of claim 17, wherein the token activation message includes a URL, and wherein the method further comprises: The token requester's computer generates a token activation notification; The token activation notification is provided to the user device by the token requester computer; And initiating, by the token requestor computer, a user authentication with an authentication server using the URL, wherein the authentication server performs an authentication process with the user device to bind an account to the user device.

Images