Enhancing security of a secure remote platform system using network authentication

Abstract

A method includes receiving, by a universal authentication application from a resource provider computer, a user credential verification request message, the user credential verification request message including a user identifier, server computer data, and interaction data for an interaction. The universal authentication application sends the user credential verification request message to a browser, the browser invoking an authenticator to verify biometric information of a user. The universal authentication application receives a user credential verification response message from the authenticator. The user credential verification response message includes signed interaction data. The universal authentication application sends the user credential verification response message to the resource provider computer. The resource provider computer provides at least the signed interaction data to a plurality of server computers to retrieve a plurality of portable device credentials respectively associated with the plurality of server computers.

Description

[0001] Cross-referencing related applications

[0002] This application is a PCT application of U.S. Provisional Application No. 62 / 934,988, filed November 13, 2019, and claims priority thereto, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] For example, conventional secure remote platform systems such as Secure Remote Transaction (SRT) systems use browser cookies to authenticate users' devices and retrieve registered account information for different cards. One problem with this is that browser cookies stored on a user's device can be stolen or accidentally deleted. Other types of authentication also exist. For instance, the web standard WebAuthn provides a method for authenticating web application users using other types of information, such as biometric authentication.

[0004] One drawback of combining WebAuthn with biometric authentication is that it may require separate biometric verification for each account credential associated with a user. Therefore, when using different SRT systems to retrieve account information to display a list of cards for interactive selection during an interaction, a separate biometric read may be requested for each SRT system. This is burdensome for both the user and the devices involved in the process. For example, a user may need to enter their biometric information multiple times to allow multiple SRT systems to provide account credentials to be displayed in the card list. This process is even more burdensome for devices because it requires a significant amount of communication across the network, depending on how many SRT systems are requesting the user's biometric authentication. Furthermore, processing capacity becomes bottlenecked when the user device can only request a single biometric read at a time. This increases the overall time required to process the interaction.

[0005] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0006] The embodiments relate to methods and systems for security authentication.

[0007] One embodiment relates to a method comprising: receiving a user credential verification request message from a resource provider computer by a generic authentication application, the user credential verification request message including a user identifier, server computer data, and interaction data for an interaction between the resource provider computer and a user device; sending the user credential verification request message to a web browser by the generic authentication application, the web browser invoking an authenticator to verify the user's biometric information; receiving a user credential verification response message from the authenticator by the generic authentication application, the user credential verification response message including signed interaction data; and sending the user credential verification response message to the resource provider computer by the generic authentication application, wherein the resource provider computer provides at least the signed interaction data to a plurality of server computers to retrieve a plurality of portable device credentials respectively associated with the plurality of server computers.

[0008] Another embodiment relates to a user device, including: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: receiving, by a generic authentication application of the user device, a user credential verification request message from a resource provider computer, the user credential verification request message including a user identifier, server computer data, and interaction data for interaction between the resource provider computer and a user of the user device; sending the user credential verification request message to a web browser by the generic authentication application, the web browser invoking an authenticator to verify the user's biometric information; receiving, by the generic authentication application, a user credential verification response message from the authenticator, the user credential verification response message including signed interaction data; and sending the user credential verification response message to the resource provider computer, wherein the resource provider computer provides at least the signed interaction data to a plurality of server computers to retrieve a plurality of portable device credentials respectively associated with the plurality of server computers.

[0009] One embodiment relates to a method comprising: receiving, by a resource provider computer, an interaction request message including an identification identifier from a user device; providing the identification request message including the identification identifier to a plurality of server computers; receiving, by the resource provider computer, two or more identification response messages from two or more of the plurality of server computers, each identification response message including a user identifier and server computer data; selecting, by the resource provider computer, a selected identification response message from one or more identification response messages; generating, by the resource provider computer, a user credential verification request message including the user identifier, the server computer data of the selected identification response message, and interaction data; sending the user credential verification request message to a universal authentication application, wherein the universal authentication application provides the user credential verification request message to a web browser, the web browser invoking an authenticator to verify the biometric information of a user on the user device; and receiving, by the resource provider computer, a user credential verification response message from the authenticator via the universal authentication application, the user credential verification response message including signed interaction data.

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

[0011] Figure 1 A block diagram of a secure interaction system according to an embodiment is shown.

[0012] Figure 2 A block diagram of the components of a user device according to an embodiment is shown.

[0013] Figure 3 A flowchart illustrating the initial use of a user device and a resource provider computer according to an embodiment is shown.

[0014] Figure 4 A flowchart illustrating the subsequent use of the user device and resource provider computer according to an embodiment is shown.

[0015] Figure 5A and 5B A user interface illustrating an exemplary user experience flow for combining biometric identification with WebAuthn according to various embodiments is shown. Detailed Implementation

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

[0017] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the message is sent to the transaction processing computer and / or the issuer of the payment card to request authorization for the transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0018] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. For example, an authorization response message may include one or more of the following status indicators: Approved – the transaction is approved; Rejected – the transaction is not approved; or Call Center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0019] "Authorizing entity" can be the entity requesting authorization. Examples of authorizing entities include issuers, government agencies, document repositories, access administrators, etc. An authorizing entity can operate an authorizing entity computer. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. An issuer can also issue payment credentials stored on a user device, such as a cellular phone, smart card, tablet computer, or laptop computer, to a user, or in some embodiments, to a user.

[0020] A "checkout element" can be any mechanism that initiates a transaction. For example, a checkout element can include a button on a graphical user interface, which initiates a transaction when the button is selected.

[0021] A cookie (also known as a web cookie, internet cookie, or browser cookie) can be any suitable piece of data sent from a web server and stored on a user's computer. When a user browses a website maintained by a web server, a small data file can be placed on the user's computer by their web browser.

[0022] A "Secure Remote Transaction (SRT) platform" can be any entity capable of facilitating transactions in the manner described. An SRT platform is capable of communicating with initiators, service providers, and transaction processing networks. In some embodiments, an SRT platform may include an SRT server, a token provider, and a transaction processing network. An SRT platform may be configured to perform one or more processes, including: receiving a transaction request from an initiator; identifying an account associated with the transaction; determining an appropriate service provider for the account; enabling the determined service provider to authenticate the user associated with the account; generating a token to be used in the transaction; and providing the token to the initiator to complete the transaction. In some implementations, an SRT platform may also be referred to as a Secure Remote Commerce (SRT) platform.

[0023] The term "resource" generally refers to anything that can be used or consumed. For example, a resource can be a computer resource (such as stored data or a networked computer account), a physical resource (such as a tangible object or physical location), or other electronic resources or communication between computers (such as communication signals corresponding to an account used to execute a transaction). Some non-limiting examples of resources can be goods or services, physical buildings, computer accounts or documents, or payment accounts.

[0024] A "resource provider" can be an entity capable of providing resources such as goods, services, information, and / or access to those resources. Examples of resource providers include merchants, online or other electronic retailers, access devices, secure data access points, etc. A "merchant" can typically be an entity that participates in transactions and can sell goods or services or provide access to goods or services. A "resource provider computer" can be any computing device operated by the resource provider.

[0025] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data (e.g., secure data interaction), a user requesting access to a secure webpage (e.g., secure webpage interaction), a user requesting access to a secure location (e.g., secure location interaction), etc. In other embodiments, an interaction can include a payment transaction in which two devices may interact to facilitate a payment.

[0026] "Interaction data" can be data associated with an interaction. For example, an interaction can be the transfer of digital assets from one party to another. In some embodiments, an interaction can include a transaction between a user and a resource provider. For example, interaction data can include the transaction amount. In some embodiments, interaction data can indicate different entities on one side of the interaction and the value or information exchanged. Interaction data can include the interaction amount, information associated with the sender (e.g., token or account information, alias, device identifier, contact address, etc.), information associated with the receiver (e.g., token or account information, alias, device identifier, contact address, etc.), one-time values ​​(e.g., random values, temporary numbers, timestamps, counters, etc.), and / or any other suitable information. Instances of interaction data can be transaction data.

[0027] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user can also be referred to as a cardholder, account holder, or consumer.

[0028] A “user device” can be a device operated by a user. Examples of user devices include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (such as automobiles), simplified client devices, tablet PCs, and so on. Furthermore, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device may include one or more processors capable of processing user input. A user device may 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 may include any electronic device that can be operated by the user, and said electronic device may 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).

[0029] A “user identifier” can include any piece of data capable of identifying a user. A user identifier can include any suitable alphanumeric string. In some embodiments, the user identifier can be derived from user identification information. The user identifier can be a Universally Unique Identifier (UUID). A UUID can be in any suitable format, such as 32 hexadecimal digits, 16 alphanumeric digits, etc. An example user identifier could be “123e4567-e89b-12d3-a456-426614174000”.

[0030] An "authenticator" may include hardware and / or software for authentication. An authenticator may include a biometric reader configured to process biometric information. An authenticator can acquire and process biometric information to authenticate an individual (e.g., a user) associated with that biometric information. An authenticator may include a biometric reader.

[0031] "Biometrics" 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.

[0032] "Biometric information" can include data related to biometrics. Biometric information can include biometric samples and / or biometric templates.

[0033] 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. In some embodiments, a user device can include a biometric reader (e.g., an authenticator).

[0034] "Biometric samples" can include data obtained by a biometric reader. This data can be an analog or digital representation of a 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.

[0035] 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.

[0036] A "generic authentication application" can include programs or software designed and written to verify the identity of something. A generic authentication application can function as a generic application by receiving user credential verification request messages that include data from multiple different server computers (e.g., an SRT system). A generic authentication application can be configured to receive user credential verification request messages from a resource provider's computer and then provide those messages to a browser on the user's device.

[0037] The "Generic Authentication Application Identifier" can include any data fragment that can identify a Generic Authentication Application. The Generic Authentication Application Identifier can be a unique identifier. For example, the Generic Authentication Application Identifier can identify a Generic Authentication Application to a browser.

[0038] "Portable device" can include a device that can be easily passed or delivered manually. A portable device can be used for interaction. A portable device can include storage technologies (e.g., electronic memory, magnetic stripe, etc.) for storing credentials or tokens associated with a user account. A portable transaction device can take any of the forms described above regarding portable communication devices, or take the form of a card (e.g., an integrated chip card, magnetic stripe card) or a pendant. In some embodiments, the portable transaction device and the user device can be the same device and do not need to be separate devices (e.g., the portable device credentials are securely stored on the user device, etc.). Examples of portable devices can include wearable devices, payment cards such as credit cards, debit cards, and prepaid cards, vehicles with telematics capabilities, etc.

[0039] A “portable device credential” may include any suitable information associated with the portable device. The portable device may be associated with an account. The portable device credential may be directly associated with the account or derived from information associated with the account. Examples of account credentials may include PAN (primary account or “account”), username, expiry date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc.

[0040] 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 like cells. 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. In some embodiments, an SRT system may be referred to as a server computer.

[0041] "Server computer data" may include a set of qualitative or quantitative variable values ​​stored by a server computer. In some embodiments, server computer data may include data related to the server computer. In some embodiments, server computer data may include data related to a user and / or user device associated with the server computer via a portable device. Server computer data may include dependent party data, where the dependent party is the operator of the server computer (e.g., an SRT system). In some embodiments, server computer data may include user profile data. For example, when the server computer is an SRT system and the server computer data includes user profile data, the user profile data may include an identifier, or a reference to the identity of the portable device associated with the user, the user device identity, or the user identity and the user's profile. In some embodiments, server computer data may include a token associated with the portable device, user device data, user data (e.g., address, phone number, etc.), and previous interaction history.

[0042] An "identification identifier" may include a series of characters used to identify a person or thing from a previous encounter or understanding. The identification identifier may include an identifier associated with a user and / or user device. The server computer may evaluate the identification identifier to determine whether a user and / or user device has been identified. A user and / or user device can be identified when the currently evaluated identification identifier matches a previously evaluated, created, or stored identification identifier. In some embodiments, the identification identifier may be a unique identifier associated with a user device. For example, the identification identifier may be a user device identifier (e.g., "123456ABCD", "XYZABC", "987654", etc.).

[0043] A “processor” can include means for performing a task. 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.

[0044] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Instances of memory may 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.

[0045] Conventional platforms employing Secure Remote Transactions (SRT) use browser cookies to authenticate a user's device and retrieve registered account information for different cards (e.g., portable device credentials). However, browser cookies stored on a user's device can be stolen or accidentally deleted. Instead of using cookies, embodiments can integrate WebAuthn with the SRT platform to provide a more secure authentication mechanism using biometrics. One drawback of relying solely on WebAuthn is that separate biometric verification may be required for each portable device credential. Therefore, when retrieving portable device credentials using different server computers (e.g., the SRT system) to display a list of portable device credentials to the user for selection during interaction, a separate biometric read may be requested for each server computer.

[0046] To eliminate the need for separate biometric verification for each dependent request, embodiments can leverage a universal authentication application to provide a trusted proof (e.g., a signed public key and / or signed interaction data) to the resource provider's computer after a single biometric verification. The resource provider's computer can then use the trusted proof to retrieve account information from each SRT system without requiring separate biometric readings from the user request for each SRT system.

[0047] Other issues that the embodiments can address relate to 1) user authentication and 2) user identification. For example, regarding 1) user authentication, the embodiments can address issues related to the current SRT experience, which relies on email one-time passwords (OTPs) for user authentication and verification. Email OTPs are vulnerable to interception and phishing attacks. Additionally, regarding 2) user identification, the embodiments can address the following issues: the current SRT relies on web cookies for user identification, the use of cookies requires consent, is often associated with marketing, and cookies are deleted quite frequently.

[0048] To address one or more of the aforementioned problems, or other issues, embodiments may utilize the following: 1) Most browsers support certain versions of the WebAuthn API to provide strong authentication for the identified user. For example, embodiments may utilize biometric identification of the user device, which can meet strong user authentication requirements. 2) Embodiments may also provide means for securely identifying users on the device using, for example, WebAuthn. This allows embodiments to provide an alternative to cookies, and is persistent on the user device and works across browsers and applications.

[0049] Figure 1 A system 100 according to various embodiments is illustrated. System 100 includes a user device 102, a resource provider computer 104, multiple SRT systems including a first SRT system 106, a second SRT system 108, and an Nth SRT system, and multiple authorization entity computers including a first authorization entity computer 112, a second authorization entity computer 114, and an Nth authorization entity computer 116. User device 102 may include a browser 102A (e.g., a web browser), an authenticator 102B (e.g., a biometric scanner), and a universal authentication application 102C. In some embodiments, the multiple SRT systems may be referred to as multiple server computers. Thus, the first SRT system 106 may be a first server computer.

[0050] User device 102 can perform operational communication with multiple SRT systems, including a first SRT system 106, a second SRT system 108, and an Nth SRT system 110. User device 102 can perform operational communication with resource provider computer 104. Resource provider computer 104 can perform operational communication with multiple SRT systems, including a first SRT system 106, a second SRT system 108, and an Nth SRT system 110. Multiple SRT systems, including a first SRT system 106, a second SRT system 108, and an Nth SRT system 110, can respectively perform operational communication with multiple authorized entity computers, including a first authorized entity computer 112, a second authorized entity computer 114, and an Nth authorized entity computer 116.

[0051] To simplify the explanation, Figure 1 A certain 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 are either fewer or more components.

[0052] Figure 1Messages between devices in System 100 can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583), and / or similar protocols. The communication network can include any one and / or a combination of: 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 can use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channels can include secure communication channels, which can be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0053] User device 102 may include a user-operated device. For example, user device 102 may include a smartphone. User device 102 may be configured to initiate interaction with resource provider computer 104 to obtain or access resources. User device 102 may use browser 102A to connect to web pages hosted by or associated with resource provider computer 104.

[0054] Browser 102A may include a computer program with a graphical user interface for displaying and navigating between web pages on the World Wide Web. When a user of user device 102 requests a web page from a specific website (e.g., a resource provider's web page), browser 102A retrieves the necessary content from a web server and then displays the page on user device 102.

[0055] In some embodiments, browser 102A may be device software on user device 102, which is an Internet of Things (IoT) device (e.g., a smart car, a smart refrigerator, a television streaming device, etc.). In other embodiments, browser 102A may be a marketplace website or application (e.g., a messaging application, an online marketplace, a social media website with a marketplace, etc.). In still other embodiments, browser 102A may be an operating system (OS) interface (e.g., a Windows application that provides an interface to the World Wide Web, iOS, Android OS, etc.).

[0056] User device 102 can be configured to send data to resource provider computer 104 and receive data about the interaction from resource provider computer 104. For example, user device 102 can provide resource provider computer 104 with an interaction request message that includes an identification identifier and any interaction data associated with the interaction.

[0057] Resource provider computer 104 can be operated by a resource provider (e.g., a merchant, payment service provider, location access service, etc.). Resource provider computer 104 can receive interaction request messages and then provide an identification identifier to each of the multiple SRT systems. Each SRT system (e.g., 106, 108, and 110) can determine whether the identification identifier matches a previously evaluated, created, and / or stored identification identifier (e.g., determining whether the user and / or user device 102 is identified). Each SRT system (e.g., 106, 108, and 110) can provide resource provider computer 104 with an identification response message indicating that the user and / or user device 102 is identified or indicating that the user and / or user device 102 is not identified.

[0058] In some embodiments, each identification response message includes a user identifier and server computer data. The user identifier may identify the user of user device 102. The server computer data may include dependent information. The server computer data may include an identity reference to a user profile (e.g., a digital reference to a profile associated with the user of user device 102). The server computer data may also include any suitable data related to the user profile (e.g., a token number sent to the user's portable device), user interaction history (e.g., interaction data related to previously performed interactions), user-related data (e.g., telephone number, mailing address, email address, date of birth, postal code, demographic information, etc.), and / or any other information describing the user and / or user device 102. In some embodiments, the server computer data may further include data related to the server computer (e.g., an SRT system) on which the server computer data is stored. For example, the server computer data may include the server computer IP address, server computer identifier, the name of the server computer operator, a digital certificate issued to the server computer by a certificate authority, the server computer public key, and / or other data identifying and / or providing communication with the server computer.

[0059] Then, the resource provider computer 104 can select an identification response message from one or more identification response messages received from multiple SRT systems. For example, the resource provider computer 104 can be configured to select the first received identification response message, which indicates that the user and / or user device 102 has been identified.

[0060] Resource provider computer 104 may be further configured to generate a user credential verification request message based on the selected identification response message and send it to the general authentication application 102C of user device 102. The user credential verification request message may include a user identifier, server computer data of the selected identification response message, and interaction data.

[0061] User device 102 can be configured to receive data from resource provider computer 104 via generic authentication application 102C. In some embodiments, generic authentication application 102C can also receive user credential verification request messages, regardless of server computer data included therein. For example, generic authentication application 102C is configured to receive user credential verification request messages that include server computer data originating from a first SRT system 106, a second SRT system 108, or an Nth SRT system 110.

[0062] The Universal Authentication Application 102C can provide a user credential verification request message to the browser 102A of the user device 102. The browser 102A can be configured to modify the user credential verification request message to include the source of the message (e.g., Universal Authentication Application 102C, SRT system, etc.). The browser 102A then provides the user credential verification request message to the authenticator 102B.

[0063] Authenticator 102B can be configured to evaluate the source of a user credential verification request message. For example, Authenticator 102B can determine whether the user credential verification request message originates from a trusted entity, computer, etc. Authenticator 102B can then obtain user biometric information to authenticate the user. For example, Authenticator 102B may include a biometric scanner, such as a fingerprint scanner. User device 102 can prompt the user to scan their fingerprint on the fingerprint scanner. Authenticator 102B can obtain a biometric sample and generate a biometric template based on the biometric sample. Authenticator 102B can further compare the biometric template with previously stored biometric templates associated with the user of user device 102. If the generated biometric template matches a previously stored biometric template, Authenticator 102B determines that the user is trustworthy. If the generated biometric template does not match a previously stored biometric template, Authenticator 102B determines that the user is untrustworthy (e.g., not the correct user).

[0064] In some embodiments, the authenticator 102B may use any suitable private key to sign the interaction data received in the user credential verification request message (e.g., sign it cryptographically).

[0065] After authenticating the user and signing the interaction data, the authenticator 102B can generate a user credential verification response message and send it to the universal authentication application 308. The user credential verification response message may include at least the signed interaction data.

[0066] Resource provider computer 104 can be configured to transmit signed interaction data with multiple SRT systems (e.g., first SRT system 106, second SRT system 108, and Nth SRT system 110). Each SRT system can evaluate the signature of the signed interaction data using a previously stored public key corresponding to the private key used by authenticator 102B. For example, the public key and private key could be the user device's public key and private key, respectively. If the SRT system determines that the signature is valid, the SRT system can provide a profile (e.g., a user profile including portable device credentials) to resource provider computer 104.

[0067] Resource provider computer 104 can provide the received portable device credentials to user device 102. User device 102 can be configured to display the portable device credentials to the user. The user can select a portable device credential to use in the current interaction. User device 102 can then transmit the selected portable device credential to resource provider computer 104.

[0068] Resource provider computer 104 can be configured to communicate with an SRT system associated with a selected portable device credential to complete an interaction. For example, resource provider computer 104 can generate an authorization request message, which can be provided to the relevant SRT system.

[0069] The SRT system can process authorization request messages to determine whether to authorize an interaction. In some embodiments, the SRT system can process authorization request messages together with authorization entity computers (e.g., first authorization entity computer 112, second authorization entity computer 114, and Nth authorization entity computer 116). For example, in some embodiments, first authorization entity computer 112 can be configured to authorize any suitable request, including access to data, access to location, or approval of payment. In some embodiments, first authorization entity computer 112 can be operated by an account issuer. Typically, an issuer is an entity that issues and maintains user accounts (e.g., a bank). Accounts can be credit, debit, prepaid, or any other type of account.

[0070] Figure 2A block diagram of a user device 200 according to an embodiment is shown. The exemplary user device 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a computer-readable medium 208, and an authenticator 210. The computer-readable medium 208 may include a browser 208A and a universal authentication application 208B.

[0071] Memory 202 can be used to store data and code. 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). For example, memory 202 can store identification identifiers, etc.

[0072] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: receiving a user credential verification request message from a resource provider computer by a generic authentication application, the user credential verification request message including a user identifier, server computer data, and interaction data for interaction between the resource provider computer and a user device; sending the user credential verification request message to a web browser by the generic authentication application, the web browser invoking an authenticator to verify the user's biometric information; receiving a user credential verification response message from the authenticator by the generic authentication application, the user credential verification response message including signed interaction data; and sending the user credential verification response message to a resource provider computer, wherein the resource provider computer provides at least signed interaction data to a plurality of server computers to retrieve credentials for a plurality of portable devices respectively associated with the plurality of server computers.

[0073] Browser 208A, also known as a web browser, is a software application used to access information on the World Wide Web. Browser 208A, in conjunction with processor 204, can access web pages from specific websites. Browser 208A, in conjunction with processor 204, can retrieve content from a web server and then display the page on user device 200. For example, once a web page is retrieved, the rendering engine of browser 208A, in conjunction with processor 204, displays the web page on the display (e.g., screen) of user device 200. In some embodiments, browser 208A, in conjunction with processor 204, can utilize an internal cache of web page resources to improve loading time for subsequent accesses to the same page. The cache can store any suitable data so that the data does not need to be downloaded from the server again.

[0074] Generic Authentication Application 208B may include programs or software designed and written for verifying the identity of something. Generic Authentication Application 208B, in conjunction with processor 204, can receive user credential verification request messages, which include server computer data originating from multiple different server computers (e.g., an SRT system). Generic Authentication Application 208B, in conjunction with processor 204, may receive user credential verification request messages from resource provider computers and then provide the user credential verification request messages to browser 208A on user device 200. In some embodiments, Generic Authentication Application 208B may be associated with a Generic Authentication Application Identifier. The Generic Authentication Application Identifier can identify Generic Authentication Application 208B to browser 208A.

[0075] Network interface 206 may include an interface that allows user device 200 to communicate with an external computer. Network interface 206 enables user device 200 to transmit data to and from another device (e.g., a resource provider computer). Some examples of network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transmitted via 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 include 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.

[0076] The embodiments may use the systems and devices described herein to perform at least the user's security authentication. Figure 3 -5 describes some instances of this type of method.

[0077] Figure 3 A flowchart illustrating the initial use of a user device and a resource provider's computer according to an embodiment is shown. The description will be within the context of a user (e.g., a consumer) initiating their first interaction (e.g., a transaction) with a resource provider (e.g., a merchant / payment service provider). Figure 3 The method 300 described herein allows a user to register during the initiation of an interaction. However, it should be understood that the invention can be applied to other situations (e.g., a user's first request to access a secure webpage).

[0078] In step 1, the user can choose to interact with the resource provider computer 304 in a specific manner. For example, the user can choose to interact with the SRT option on the user device 302. Interacting with the SRT option can be a button provided to the user on the browser 310 displaying the resource provider's webpage. For example, when the user accesses the resource provider computer's webpage via the browser 310 on the user device 302, the user can choose to interact with the resource provider computer 304 using SRT. The user device 302 can send a message to the resource provider computer 304 instructing the user to make the selection. For example, the user device 302 can send an interaction request message to the resource provider computer 304. The interaction request message can include instructions to utilize SRT during the interaction. The interaction request message can also include an identification identifier, the selection of items (e.g., products, data, etc.), date, time, and / or any other information related to the user requesting to perform the interaction with the resource provider computer 304.

[0079] The interaction request message includes interaction data. The interaction data may include data associated with an interaction between the user of user device 302 and the resource provider of resource provider computer 304. For example, the interaction may include a transaction between the user and the resource provider. The interaction data may include the transaction amount, the resource provider identifier, and the user device identifier. In some embodiments, the interaction data may indicate different entities of the interacting parties and the value or information exchanged. In other embodiments, the interaction data may further include information associated with the sender (e.g., token or account information, alias, device identifier, contact address, etc.), information associated with the receiver (e.g., token or account information, alias, device identifier, contact address, etc.), one-time values ​​(e.g., random values, temporary numbers, timestamps, counters, etc.), and / or any other suitable information.

[0080] The identification identifier may include an identifier associated with the user and / or user device 302. The identification identifier may be uniquely assigned to the user and / or user device 302. When another device (e.g., resource provider computer 304, server computer, etc.) communicates with user device 302, the other device may evaluate the identification identifier to determine whether user device 302 is identified. If the other device has previously encountered the identification identifier, it can identify user device 302. For example, the other device (e.g., server computer, etc.) may store the identification identifier of user device 302 after registering user device 302 (e.g., as performed at step 15). For example, in some embodiments, the identification identifier may be a user device identifier (e.g., “123456ABCD”, “XYZABC”, “987654”, etc.).

[0081] In step 2, after receiving the interaction request message, the resource provider computer 304 may generate requests to multiple server computers 306 (e.g., one or more SRT systems) to identify the user of the user device 302 and / or, in some embodiments, to determine whether the user device 302 is recognized by one or more server computers. For example, the resource provider computer 304 may determine that the interaction request message includes an instruction to process the interaction using SRT. The resource provider computer 304 may then generate an identification request message including an identification identifier.

[0082] In step 3, after generating the identification request message, the resource provider computer 304 can send the identification request message to multiple server computers 306.

[0083] In step 4, after receiving the identification request message, each of the plurality of server computers 306 can determine whether the user and / or user device 302 has been identified based on the identification identifier. For example, the server computer can determine whether the received identification identifier matches a previously stored identification identifier. Figure 3 In an example, each of the multiple server computers 306 can determine that the identification identifier has not been identified (e.g., it does not match a previously stored identifier).

[0084] In step 5, each of the plurality of server computers 306 may generate an identification response message indicating whether the identification identifier has been identified. In some embodiments, the identification response message generated separately at each server computer may include the identification identifier.

[0085] In step 6, each of the plurality of server computers 306 may send an identification response message to the resource provider computer 304. For example, each server computer may respond to the resource provider computer 304 with an indication of whether the user and / or user device 302 has been identified. For example, during initial use, the user may not be identified. In this case, for example, the server computer may respond with "No".

[0086] In step 7, after receiving an indication that the user is not identified, the resource provider computer 304 may request the user to enter portable device credentials. In some embodiments, the resource provider computer 304 may request portable device credentials via browser 310. In some embodiments, the resource provider computer 304 may send a portable device credential request message to the user device 302.

[0087] In step 8, the user can enter a portable device credential. The portable device credential may include any suitable information associated with the portable device linked to the user account. For example, the portable device credential may be directly associated with the account or may be derived from information associated with the account. The portable device credential may include any combination of PAN (primary account or "account"), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc., and these items may be linked together in any way. The user device 302 may receive the portable device credential via an input device (e.g., a touchscreen, keyboard, etc.).

[0088] In step 9, after receiving the portable device credential, user device 302 may provide the portable device credential to resource provider computer 304. The portable device credential may be sent from user device 302 to resource provider computer 304 in any suitable secure manner. For example, the portable device credential or a message containing the portable device credential may be encrypted in such a way that resource provider computer 304 is configured to decrypt the portable device credential or a message containing the portable device credential.

[0089] In step 10, after receiving the portable device credentials, the resource provider computer 304 may generate an authorization request message. The authorization request message may include at least interaction data and the portable device credentials. In some embodiments, the authorization request message may further include an identification identifier, such that at step 15, the selected server computer may store the identification identifier when registering the user.

[0090] In step 11, the resource provider computer 304 may send an authorization request message to the selected server computer. The selected server computer may be the server computer associated with the portable device credential. For example, the first digit, last digit, first four digits, middle two digits, etc., of the portable device credential may indicate which server computer the portable device credential is associated with. For example, the portable device credential may include the following numbers as its first 16 digits: “1234567890123456”. The resource provider computer 304 may determine that the selected server computer is the first server computer among a plurality of server computers 306 because the portable device credential begins with the number “1”.

[0091] In step 12, after receiving the authorization request message from resource provider computer 304, the selected server computer may send a request for profile data to user device 302 for user registration. The request for profile data may include requests for email address, telephone number, mailing address, date of birth, and / or any other data related to the user.

[0092] In step 13, after receiving a request for configuration file data from a selected server computer among a plurality of server computers 306, user device 302 may prompt the user to enter the configuration file data. The user may provide configuration file data (e.g., email address, phone number, and / or any other suitable user data that can be used to identify the user) to user device 302. In other embodiments, the configuration file data may already be stored in user device 302. In this case, in step 13, user device 302 may retrieve the configuration file data from memory.

[0093] In step 14, after obtaining the configuration file data, user device 302 can provide the configuration file data to the selected server computer.

[0094] In step 15, after receiving the configuration file data from user device 302, the selected server computer can register the user. For example, the selected server computer among a plurality of server computers 306 can store the configuration file data and identification identifier in a database (e.g., a configuration file database). The selected server computer can further associate portable device credentials with the configuration file data and / or identification identifier.

[0095] In step 16, the selected server computer can generate a user identifier for the user. The user identifier may be a Universally Unique Identifier (UUID). In some embodiments, for example, the UUID may include a 128-bit number. The selected server computer may store the user identifier along with configuration file data in a database.

[0096] In addition, the selected server computer may generate server computer data or retrieve server computer data from storage. Server computer data may include any suitable data related to user profiles, user interaction history, and / or user-related data. For example, a user profile may include a token number issued to the user's portable device. User interaction history may include interaction data related to previously performed interactions. User-related data may include telephone number, mailing address, email address, date of birth, postal code, demographic information, and / or any other information describing the user. Server computer data may further include data related to the server computer storing the server computer data. For example, server computer data may include the server computer's IP address, server computer identifier, the name of the server computer operator, digital certificates issued to the server computer by a certificate authority, the server computer's public key, and / or other data identifying and / or providing communication with the server computer. The selected server computer may retrieve server computer data from a server computer data database maintained by the selected server computer.

[0097] In step 17, the selected server computer may send a credential creation request to the general authentication application 308 (which may be part of the authentication abstraction layer). The credential creation request may be a request to set user biometric information on the authenticator 312 on the user device 302 for authentication. The credential creation request includes a user identifier and server computer data.

[0098] In some embodiments, the credential creation request may also include a Universal Authentication Application (UCA) identifier that identifies the Universal Authentication Application. For example, the UCA identifier may be an alphanumeric value that uniquely identifies the Universal Authentication Application to the browser 310 and / or the authenticator 312. In some embodiments, the UCA identifier may include a digital signature, hash, or other cryptographic security identifier. By using the UCA identifier, the browser 310 and / or the authenticator 312 understand that the request originates from a trusted source. It should also be noted that the UCA identifier may also be used in… Figure 4 The corresponding process steps in the text.

[0099] In step 18, after receiving the credential creation request from the selected server computer, the generic authentication application 308 can forward the credential creation request to the browser 310 of the user device 302. The generic authentication application 308 may be a program installed on the user device 302 and can route the credential creation request to the browser 310 within the user device 302. In some embodiments, the generic authentication application 308 can verify the validity of the credential creation request (e.g., the request includes an appropriate digital signature from a trusted party, the request includes a user identifier and server computer data, etc.).

[0100] In step 19, browser 310 may forward the credential creation request to authenticator 312 of user device 302. In some embodiments, browser 310 may modify the credential creation request to form a credential request issued by the authenticator, the request may include a source (e.g., the origin of the request), a user identifier, and server computer data.

[0101] In some embodiments, if the credential creation request message includes a Generic Authentication Application (GAAP) identifier, browser 310 can verify the GAAP identifier. For example, browser 310 can determine whether the GAAP identifier is the same as an identifier stored in a list of acceptable identifiers (e.g., a whitelist). As another example, if the GAAP identifier is a signature formed by the private key (or other suitable cryptographic key) of GAAP 308, browser 310 can cryptographically verify the signature using the public key of GAAP 308.

[0102] In other embodiments, browser 310 may provide a Generic Authentication Application Identifier (GAIPI) to authenticator 312 and invoke authenticator 312 to verify the GAIPI. Upon receiving a credential creation request message including the GAIPI, authenticator 312 may verify the GAIPI in any suitable manner described herein. In some embodiments, both browser 310 and authenticator 312 may verify the GAIPI.

[0103] The authenticator 312 may be a component installed on the user device 302, which may receive and / or capture biometric samples, convert biometric samples into biometric templates, perform any appropriate verification cryptographic process (e.g., sign the public key with the private key), and / or relay data to other components of the user device 302.

[0104] In step 20, the authenticator 312 may prompt the user to set credentials (e.g., biometric information). In step 21, the user device 302 may display a prompt from the authenticator 312 to the user. The user device 302 can then receive input biometric information from the user. In step 22, the user device 302 may provide the input biometric information to the authenticator 312 in any suitable manner, depending on the type of authenticator used by the user device 302. For example, the user may place their finger on a fingerprint scanner.

[0105] In step 23, after receiving biometric information from the user, the authenticator 312 may store the biometric information (e.g., as a biometric template) in a secure memory. The authenticator 312 may store the user's biometric information associated with, for example, a user identifier.

[0106] In step 24, after storing the biometric information, the authenticator 312 can sign the public key with its private key. In some embodiments, the public and private keys can be the authenticator's public and private keys. In other embodiments, the public and private keys can be the user device's public and private keys. The private key can be stored in secure storage or in software (e.g., a host card emulator (HCE)) on the user device 302. The private key can be associated with a digital certificate issued by a certificate authority. Therefore, the selected server computer can verify the certificate chain that returns the private key to the certificate authority. The authenticator 312 can sign the public key with its private key to form a digital signature on the signed public key.

[0107] In step 25, after authenticating the user and signing the public key, the authenticator 312 can send the signed public key to the universal authentication application 308. In some embodiments, the authenticator 312 can send the signed public key to the browser 310, which can then relay the signed public key to the universal authentication application 308.

[0108] In step 26, after receiving the signed public key, the general authentication application 308 can send the signed public key to a selected server computer among a plurality of server computers 306 (and, if the server computer does not already have the public key, send the public key).

[0109] In step 27, the selected server computer can verify the signed public key. If the selected server computer determines that the signed public key is valid, it can associate the signed public key, authenticator 312, user, and / or received data related to the user with each other. The selected server computer can store the signed public key along with configuration file data in a database. The signed public key can be used in subsequent interactions to verify signed interaction data, such as... Figure 4 Step 20 will be described in further detail below.

[0110] In step 28, the selected server computer may determine whether to authorize the interaction or process the transaction to obtain authorization (e.g., by sending an authorization request message to the authorizing entity computer). The selected server computer may determine whether to authorize the interaction based on interaction data, user device 302, resource provider computer 304, portable device credentials, fraud rate or rules, and / or any other suitable information that may affect whether the interaction is authorized. If the selected server computer determines that the interaction is authorized between the user and the resource provider, the selected server computer may generate an indication of authorized interaction. If the selected server computer determines that the interaction is unauthorized, the selected server computer may generate an indication of unauthorized interaction.

[0111] In step 29, a selected server computer among the plurality of server computers 306 may generate an authorization response message or forward an authorization response message it has received from the authorization entity computer. The authorization response message may include an indication of whether the interaction is authorized. In some embodiments, the authorization response message may further include a user identifier and / or any other device identification information.

[0112] In step 30, the selected server computer may then send an authorization response message to the resource provider computer 304. Once the resource provider computer 304 receives the authorization response message (not shown), it can evaluate it. The resource provider computer 304 can determine whether the authorization response message indicates that the interaction is authorized. If the interaction is authorized, the resource provider computer 304 can provide the user device 302 with an interaction response message indicating that the interaction is authorized.

[0113] Resource provider computer 304 may further provide the requested resources to the user of user device 302. For example, resource provider computer 304, or a computer prompted by resource provider computer 304, may issue physical products to the user, provide digital files to user device 302, allow user device 302 to access secure web pages, allow user access to secure locations, place orders for delivery to the user's location, and / or perform any other appropriate action to complete the interaction.

[0114] Figure 4 A flowchart illustrating subsequent use of a user device and a resource provider computer according to an embodiment is shown. The process will be described in the context of a user (e.g., a consumer) initiating an interaction (e.g., a transaction) with a resource provider (e.g., a merchant / payment service provider) after the user (e.g., a consumer) has previously registered with one or more server computers (e.g., an SRT system). Figure 4 Method 400. However, it should be understood that the present invention can be applied to other situations (e.g., a user requesting access to a secure webpage, a user requesting data transfer, a user requesting access to a secure location, etc.).

[0115] In step 1, the user can initiate an interaction with the resource provider computer 404 using user device 402, such as a transaction, a secure location access request, or a secure webpage access request. For example, when accessing a webpage on the resource provider computer via browser 410 on user device 402, the user can choose to interact using SRT. User device 402 can send an interaction request message including an identification identifier to resource provider computer 404. The identification identifier can be a unique identifier associated with user device 402. For example, the identification identifier can be a user device identifier (e.g., "123456ABCD", "XYZABC", "987654", etc.).

[0116] The interaction request message may further include interaction data for the interaction between the user of user device 402 and the resource provider of resource provider computer 404. For example, for a user attempting to access a secure location (e.g., a locked building, an employee-only location, a government building, etc.), the interaction data may be secure location access request data. The interaction data may include door numbers, location addresses, and / or other location identification information. A user may have multiple portable devices that allow access to different locations. For example, a user may have a first portable device that allows access to their employer's building and a second portable device that allows access to their residence. The first portable device may be associated with a first server computer. The second portable device may be associated with a second portable device. In other embodiments, the interaction data may be data associated with a purchase transaction.

[0117] In step 2, after receiving the interaction request message from user device 402, resource provider computer 404 generates an identification request message. The identification request message may include an identification identifier. The identification request message may be a message querying the server computer whether user device 402 has been identified.

[0118] In step 3, the resource provider computer 404 may provide the identification request message to multiple server computers 406. For example, the resource provider computer 404 may send the same identification request message to each server computer (e.g., the SRT system).

[0119] In step 4, after receiving the identification request message, each of the plurality of server computers 406 can determine whether the user device 402 has been identified. For example, the server computer can compare the received identification identifier with a plurality of stored identifiers in an identifier database. The plurality of stored identifiers can be configured during the registration step (e.g., during...). Figure 3 Step 15) is stored in the identifier database. The server computer can determine whether the identification identifier matches the stored identifier.

[0120] In step 5, each of the plurality of server computers 406 may generate an identification response message. For example, if a server computer determines that user device 402 is not identified (e.g., the identification identifier does not match the stored identifier), the server computer may generate an identification response message that includes an indication that the user is not identified.

[0121] If the server computer determines that user device 402 has been identified (e.g., the identification identifier matches a stored identifier), the server computer may generate an identification response message that includes an indication that the user has been identified, the user identifier, and server computer data. The user identifier may be an identifier that identifies the user and may include any suitable alphanumeric string. In some embodiments, the user identifier is a Universally Unique Identifier (UUID) (e.g., “123e4567-e89b-12d3-a456-426614174000”). The server computer data may be dependent-party information, where the server computer is the dependent party. The server computer data may be an identity reference to a user profile (e.g., a numerical reference to a profile associated with the user of user device 402). The server computer data may include a token number sent to the user's portable device, user interaction history, user-related data (e.g., telephone number, mailing address, email address, date of birth, postal code, demographic information, etc.), and / or any other information describing the user and / or user device 402. The server computer data may also include a server computer identifier.

[0122] In some embodiments, the identification response message indicating that the user device 402 has been identified may further include a token indicating the type of interaction to be performed. For example, the token may have a type equal to "SRT-webAuthN", "universal_auth" or other suitable type, which instructs the resource provider computer 404 to process the interaction with the universal authentication application 408.

[0123] In step 6, after generating the identification response message, each of the plurality of server computers 406 sends the identification response message to the resource provider computer 404. For example, the plurality of server computers 406 may include three different server computers. A first server computer may determine that user device 402 is identified, a second server computer may determine that user device 402 is identified, and a third server computer may determine that user device 402 is not identified. Each server computer sends a separately generated identification response message to the resource provider computer 404. For example, the first server computer may send a first identification response message, which includes an indication that the user is identified, a user identifier, and first server computer data. The second server computer may send a second identification response message, which includes an indication that the user is identified, a user identifier, and second server computer data. The third server computer may send a third identification response message, which includes an indication that the user is not identified. In some embodiments, the user identifier provided by the different server computers may be the same user identifier. In other embodiments, the user identifier provided by the different server computers may be different.

[0124] In step 7, after receiving multiple identification response messages from multiple server computers 406, resource provider computer 404 can select an identification response message from the multiple identification response messages (e.g., a selected identification response message). For example, resource provider computer 404 may receive three identification response messages from three different server computers. In some embodiments, resource provider computer 404 may select the first received identification response message. In other embodiments, resource provider computer 404 may select the first received identification response message that includes an indication that user device 402 has been identified. In yet another embodiment, resource provider computer 404 may randomly select one of the identification response messages that includes an indication that user device 402 has been identified. For example, during steps 8-18, data included in the selected identification response message may be utilized.

[0125] In some embodiments, resource provider computer 404 may generate a list (or other data structure) of server computers among a plurality of server computers 406, which provide an identification response message including an indication that user device 402 has been identified. For example, resource provider computer 404 may create a list of participating server computers.

[0126] After selecting the chosen identification response message, the resource provider computer 404 can generate a user credential verification request message (e.g., the "credentials.get" command). The user credential verification request message includes the user identifier, the server computer data of the chosen identification response message, and interaction data.

[0127] In step 8, after selecting the chosen identification response message, the resource provider computer 404 may send a user credential verification request message to the general authentication application 408.

[0128] In some embodiments, the user credential verification request message may further include a generic authentication application identifier (GAIP) that identifies the generic authentication application 408. For example, the GAIP identifier may include a digital signature or hash value. In some embodiments, the resource provider computer 404 may store the GAIP identifier and may retrieve it from memory to include it in the user credential verification request message. In other embodiments, the resource provider computer 404 may receive the GAIP identifier from one or more of a plurality of server computers 406.

[0129] In step 9, after receiving the user credential verification request message, the universal authentication application 408 can send the user credential verification request message to the browser 410 of the user device 402. In some embodiments, the universal authentication application 408 can be installed on the user device 402. For example, the universal authentication application 408 can forward the user credential verification request message to the browser 410, which calls the authenticator 412 to verify the user's biometric information.

[0130] In step 10, after receiving the user credential verification request message, the browser 410 can provide the user credential verification request message to the authenticator 412.

[0131] In some embodiments, browser 410 may modify the user credential verification request message to form a modified user credential verification request message (e.g., authenticatorGetCredential()). The modified user credential verification request message may include a user identifier, server computer data, and source. The source may indicate where the message originated (e.g., from the server computer via generic authentication application 408, originating from the server computer, generic authentication application 408, etc.). Then, in step 10, browser 410 may provide the modified user credential verification request message to authenticator 412.

[0132] In some embodiments, if the user credential verification request message includes a Generic Authentication Application (GAAP) identifier, browser 410 can verify the GAAP identifier. For example, browser 410 can determine whether the GAAP identifier is the same as an identifier stored in a list of acceptable identifiers. As another example, if the GAAP identifier is a signature formed by the private key (or other suitable cryptographic key) of GAAP 408, browser 410 can cryptographically verify the signature using the public key of GAAP 408.

[0133] In other embodiments, browser 410 may provide a Universal Authentication Application Identifier (GAIPI) to authenticator 412 and invoke authenticator 412 to verify the GAIPI. Upon receiving a credential creation request message including the GAIPI, authenticator 412 may verify the GAIPI in any suitable manner described herein. In some embodiments, both browser 410 and authenticator 412 may verify the GAIPI.

[0134] Figure 4 Steps 11-13 are similar to Figure 3 Steps 20-22 will not be repeated in detail here. In step 11, after receiving the user credential verification request message, the authenticator 412 may request the user to verify user credentials (e.g., the user's biometric information) based on the received request. For example, the authenticator 412 may prompt the user to scan a fingerprint or otherwise capture a suitable biometric sample as a biometric template. As an illustrative example, the authenticator 412 may prompt the user device 402 to display a biometric information capture message to the user (e.g., on the screen of the user device 402). In step 12, the user device 402 may receive the biometric information input by the user. In step 13, the biometric information may be provided to the authenticator 412.

[0135] In step 14, after receiving the biometric information, the authenticator 412 can verify that the biometric information matches previously stored biometric information associated with the user. For example, previously stored biometric information may be previously stored in... Figure 3At step 23. If the authenticator 412 determines that the received biometric information matches previously stored biometric information, the authenticator 412 may proceed to step 15. If the authenticator 412 determines that the received biometric information does not match previously stored biometric information, the authenticator 412 may repeat step 11 and may again prompt the user to enter biometric information via user device 402. In some embodiments, the authenticator 412 may prompt the user to enter biometric information any predetermined number of times until the entered biometric information matches the stored biometric information. After the predetermined number of times, due to too many failed attempts, the authenticator 412 may stop requesting biometric information from the user. The authenticator 412 may provide an authentication failure message (not shown) to the resource provider computer 404 via the universal authentication application 408.

[0136] In step 15, after authenticating the user, the authenticator 412 can sign the interaction data using its private key. The private key can be the authenticator's private key or the user device's private key. In some embodiments, the private key can be stored in secure hardware components or in software.

[0137] In step 16, authenticator 412 may provide the signed interaction data to universal authentication application 408. In some embodiments, authenticator 412 may provide the signed interaction data to browser 410, which then routes the signed interaction data to universal authentication application 408. In other embodiments, authenticator 412 may combine a user identifier or other suitable data to provide the signed interaction data.

[0138] In step 17, after receiving the signed interaction data, the general authentication application 408 can send the signed interaction data to the resource provider computer 404.

[0139] At step 18, after receiving the signed interaction data, the resource provider computer 404 can determine which of the multiple server computers 406 should provide the signed interaction data to. For example, the resource provider computer 404 can utilize the list of participating server computers by sending the signed interaction data to each server computer in the list of participating server computers.

[0140] In step 19, the resource provider computer 404 may provide the signed interaction data to multiple server computers 406. In some embodiments, the signed interaction data may be provided to two or more server computers in a profile request message (e.g., getSRTProfile(signed interaction data)). In some embodiments, the resource provider computer 404 may send the signed interaction data to each server computer, which provides an identification response message including an indication that the user device 402 was identified at step 7.

[0141] In step 20, after receiving the signed interaction data, each of the plurality of server computers 406 (e.g., participating server computers) can verify the signed interaction data. For example, each participating server computer can verify the signature of the signed interaction data. The signature can be verified using a previously stored public key corresponding to the private key used to sign the interaction data. For example, the stored public key could be a public key received by the participating server computer from user device 402 during registration. For example, the participating server computer can... Figure 3 The system receives the public key of user device 402 at step 26.

[0142] If the server computer determines that the signature of the signed interaction data is valid, the server computer can proceed to step 21. If the server computer determines that the signature of the signed interaction data is invalid, the server computer can terminate the interaction and / or provide an invalid signature notification to the resource provider computer 404.

[0143] In step 21, after verifying the signature of the signed interaction data, each participating server computer can provide a profile to resource provider computer 404. In some embodiments, the profile may include one or more profiles associated with a user of user device 402. The profile may include portable device credentials (e.g., payment card data) associated with the user. For example, the server computer may send a getSRTProfile response (e.g., a list of portable device credentials) to resource provider computer 404. Each participating server computer may provide different portable device credentials to resource provider computer 404.

[0144] In some embodiments, the server computer may mask portable device credentials to form masked portable device credentials. Masking portable device credentials can further enhance the security of portable device credentials, ensuring that the portable device credentials themselves are not provided to resource provider computer 404 or potentially malicious parties intercepting messages. The server computer may mask portable device credentials in any suitable manner. For example, the server computer may delete a first predetermined number of portable device credentials. Each of the plurality of server computers 306 may provide the masked portable device credentials to resource provider computer 304 instead of providing the portable device credentials. Resource provider computer 404 may obtain each of the masked portable device credentials from different server computers based on signed interaction data generated by the authenticator.

[0145] As an illustrative example, resource provider computer 404 may provide signed interaction data to a first server computer and a second server computer (e.g., participating server computers), but not to a third server computer (e.g., a non-participating server computer). Both the first and second server computers can independently verify the signature of the signed interaction data. After verifying the signature, the first and second server computers can retrieve portable device credentials associated with the public key and therefore with user device 402. The portable device credentials can be stored in any suitable database or memory location for each different server computer.

[0146] For example, a first server computer can obtain a first portable device credential that allows a user to access their employer's building. A second server computer can obtain a second portable device credential that allows a user to access their residence. The first portable device credential can be for a first portable device, and the second portable device credential can be for a second portable device. The first portable device can be different from the second portable device. Both the first and second portable devices can be associated with a user of user device 402.

[0147] As an additional example, the first server computer may obtain a first portable device credential, which may include credit card information (e.g., PAN, CVV, expiry date, etc.) issued by a first authorized entity from a first authorized entity computer. The second server computer may obtain a second portable device credential, which may include debit card information issued by a second authorized entity from a second authorized entity computer.

[0148] The first server computer can provide the first portable device credentials to the resource provider computer 404. The second server computer can provide the second portable device credentials to the resource provider computer 404.

[0149] In some embodiments, a first server computer may mask a first portable device credential to form a masked first portable device credential, and then provide the masked first portable device credential to a resource provider. The first server computer may mask the first portable device credential in any suitable manner. For example, the first server computer may mask the first portable device credential by deleting a first predetermined number of digits, a last predetermined number of digits, and / or an intermediate predetermined number of digits from the first portable device credential. For example, the first portable device credential may include the account "123456789123456". The first server computer may mask the first portable device credential to form masked first portable device credentials such as "3456", "***3456", "1234", "**56789**", etc. A second server computer may similarly mask a second portable device credential to form a masked second portable device credential, and then provide the masked second portable device credential to resource provider computer 404.

[0150] In step 22, after receiving portable device credentials from one or more server computers (e.g., participating server computers), resource provider computer 404 may generate a list of portable device credentials. The list of portable device credentials may be an ordered list including the portable device credentials received from each server computer. In some embodiments, the resource provider computer may sort the cards in the card list in any suitable manner. In some embodiments, resource provider computer 404 may generate the list using received masked portable device credentials.

[0151] In step 23, the resource provider computer 404 may provide a list of portable device credentials to the user device 402.

[0152] In step 24, after receiving the list of portable device credentials, user device 402 may display the list of portable device credentials on any suitable display (e.g., a screen) to present the portable device credentials to the user for selection. The user can select any portable device credential from the list. User device 402 may receive the selection of portable device credentials via user input.

[0153] For example, user device 402 may present a list of portable device credentials to the user, including a first portable device credential allowing access to their employer's building and a second portable device credential allowing access to their residence. The user can choose which portable device credential to use. For example, the user can choose to use the second portable device credential to access their residence. However, it should be understood that in some embodiments, a particular portable device credential may not be limited to a specific use case, such as location. Instead, in some embodiments, the user can choose any of the presented portable device credentials to perform an interaction. For example, two different portable device credentials associated with two different credit cards may be presented to the user. The user can choose which credit card to use for the current interaction (e.g., a transaction), where the success of the interaction does not depend on which portable device credential is selected.

[0154] At step 25, after receiving the selection of the selected portable device credential from the user, the user device 402 may send the selected portable device credential to the resource provider computer 404. In some embodiments, if the portable device credential was previously blocked by the server computer, the user may select a blocked portable device credential, and then the user device 402 may send the blocked portable device credential to the resource provider computer 404.

[0155] In step 26, after receiving the selected portable device credentials, the resource provider computer 404 may generate an authorization request message that includes at least the selected portable device credentials.

[0156] In step 27, after generating the authorization request message, the resource provider computer 404 may send the authorization request message to the server computer associated with the selected portable device credentials.

[0157] In step 28, after receiving the authorization request message, the server computer can determine whether to authorize the interaction. The server computer can determine whether to authorize the interaction based on any suitable data known to the server computer (e.g., interaction data, server computer data, etc.). The server computer can generate an indication of whether the interaction is authorized. For example, if the server computer determines that the interaction is authorized, it can generate an indication of authorized interaction. If the server computer determines that the interaction is unauthorized, it can generate an indication of unauthorized interaction. In some embodiments, the server computer can send an authorization request message to the authorizing entity computer to obtain authorization for the transaction.

[0158] Additionally, during step 28, after determining whether to authorize the interaction, the server computer may generate an authorization response message in response to the authorization request message. The authorization response message may include an indication of whether the interaction is authorized. In other embodiments, the server computer may receive the authorization response message from the authorizing entity computer.

[0159] In step 29, after an authorization response message has been generated or received, the server computer may send an authorization response message to the resource provider computer 404. Once the resource provider computer 404 receives the authorization response message (not shown), it can evaluate it. The resource provider computer 404 can determine whether the authorization response message indicates that the interaction is authorized. If the interaction is authorized, the resource provider computer 404 can provide the user device 402 with an interaction response message indicating that the interaction is authorized. The resource provider computer 404 can further provide the requested resources to the user of the user device 402. For example, the resource provider computer 404, or a computer prompted by the resource provider computer 404, can deliver physical products to the user, provide digital files to the user device 402, allow the user device 402 to access secure web pages, allow the user to enter secure locations, place orders for delivery to the user's location, and / or perform any other appropriate actions to complete the interaction.

[0160] In other embodiments, after step 24, when the user selects a blocked portable device credential from the list of blocked portable device credentials, the user device 402 may determine a token reference identifier associated with the selected blocked portable device credential. The token reference identifier may have been previously stored on the user device 402. Each blocked portable device credential may correspond to a different token reference identifier. For example, a user may be associated with two blocked portable device credentials. A first blocked portable device credential may correspond to a first token reference identifier. A second blocked portable device credential may correspond to a second token reference identifier. In some embodiments, the token reference identifier may include a unique alphanumeric identifier. Each portable device credential may correspond to a token reference identifier.

[0161] Once user device 402 determines a token reference identifier corresponding to the selected masked portable device credential, user device 402 can provide the token reference identifier to resource provider computer 404 (e.g., in step 25). In some embodiments, user device 402 can provide the token reference identifier and the selected masked portable device credential to resource provider computer 404. In yet another embodiment, the token reference identifier associated with the selected masked portable device credential can be provided to a server computer among a plurality of server computers 406. The server computer can then use the token reference identifier to obtain a stored token. This token can then be used to conduct transactions. The token can be provided directly to resource provider computer 404 or via user device 402, and resource provider computer 404 can generate and send an authorization request message including the token. In other embodiments, after receiving any interaction data (e.g., transaction data) from resource provider computer 404, the server computer can generate an authorization request message including the token.

[0162] The resource provider and / or server computer can then send an authorization request message, including the token and the interaction data, to the transmission computer (not shown). The transmission computer can be operated by an acquiring party, which is typically a system of an entity (e.g., a bank) with a business relationship with a particular merchant, wallet provider, or another entity.

[0163] Upon receiving an authorization request message, the transmitting computer forwards the message to a processing network computer (not shown). The processing network computer can be configured to provide authorization services as well as clearing and settlement services for payment transactions. The processing network computer may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. The processing network computer can forward authorization requests received from the transmitting computer to the authorization entity computer via a communication channel.

[0164] In some embodiments, the processing network computer may modify the authorization request message to replace the token with a portable device credential. The processing network computer may modify the authorization request message in conjunction with a token provider computer (not shown). For example, after receiving the authorization request message, the processing network computer may provide the token from the authorization request message to the token provider computer in a portable device credential request message.

[0165] A token provider computer can be a system that provides services for tokens. In some embodiments, the token provider computer can facilitate requesting, determining (e.g., generating), and / or issuing tokens, and maintaining established mappings of tokens to primary accounts (PANs) and / or other portable device credentials in a repository (e.g., a token vault). In some embodiments, the token provider computer can establish a token security level for a given token to indicate the confidence level of the token-PAN binding. The token provider computer may include or communicate with a token vault storing generated tokens. The token provider computer can support token processing for payment transactions submitted using tokens by de-tokenizing the token to obtain portable device credentials. After determining the portable device credentials associated with the token, the token provider computer can provide a portable device credential response message including the portable device credentials to the processing network computer.

[0166] Upon receiving the portable device credential response message, the processing network computer can modify the authorization request message to replace the token with the portable device credential. In some embodiments, the processing network computer can add the portable device credential to the authorization request message, such that the authorization request message includes the token, interaction data, and the portable device credential. The processing network computer then sends the authorization request message to the authorization entity computer (not shown).

[0167] The authorizing entity computer can be operated by the account issuer that issues and maintains the user account for user device 402. For example, the authorizing entity computer can be a first authorizing entity computer operated by a first authorizing entity that issues the selected portable device credential and maintains the account associated with the selected portable device credential. The authorizing entity computer can determine whether to authorize the interaction based on the interaction data, token, portable device credential, and / or data associated with the user and / or user device 402 stored in the authorizing entity computer. The authorizing entity computer can generate an indication of whether the interaction is authorized. The authorizing entity computer can generate an authorization response message that includes the indication of whether the interaction is authorized. In some embodiments, the authorization response message may further include the portable device credential and / or interaction data. In some embodiments, the authorization response message may further include a token. After generating the authorization response message, the authorizing entity computer can send the authorization response message to the processing network computer.

[0168] Upon receiving the authorization response message, in some embodiments, the processing network computer may modify the authorization response message to replace the portable device credentials with a token. The processing network computer may then provide the authorization response message to the transmitting computer.

[0169] After receiving an authorization response message from the processing network computer, the transmission computer may provide the authorization response message to the resource provider computer 404 if it has received an authorization request message from the resource provider computer 404, or it may provide the authorization response message to the server computer if it has received an authorization request message from one of the multiple server computers 406.

[0170] In some embodiments, user device 402 may perform a second interaction. For example, the aforementioned interaction request message may be a first interaction request message, the identification request message may be a first identification request message, one or more identification response messages may be one or more first identification response messages, server computer data may be first server computer data, the identification response message may be a first identification response message, the user credential verification request message may be a first user credential verification request message, the server computer data may be first server computer data, the interaction data may be first interaction data, the interaction may be a first interaction, the user credential verification response message may be a first user credential verification response message, the signed interaction data may be first signed interaction data, and the multiple portable device credentials may be multiple first portable device credentials.

[0171] User device 402 may initiate a second interaction with resource provider computer 404 or another resource provider computer. User device 402 may provide a second interaction request message including an identification identifier. After resource provider computer 404 or other resource provider computer receives the identification identifier, resource provider computer 404 or other resource provider computer may provide a second identification request message including the second identification identifier to multiple server computers.

[0172] Each server computer can determine whether the identification identifier has been recognized, as described herein, and then generate a second identification response message. Each server computer can provide the second identification response message to the resource provider computer 404 or other resource provider computers.

[0173] Resource provider computer 404 or other resource provider computers may receive one or more second identification response messages from one or more of a plurality of server computers. Each second identification response message includes a user identifier and second server computer data (compared to the first server computer data in the first interaction). However, it should be understood that each server computer provides different server computer data. In this example, the first and second are used to distinguish between the first interaction and the second interaction.

[0174] Then, the resource provider computer 404 or another resource provider computer can select a second selected identification response message from one or more identification response messages. The second identification response message is received from a server computer different from the server computer that received the first identification response message.

[0175] After selecting the second selected identification response message, the resource provider computer 404 or other resource provider computer can generate a second user credential verification request message, which includes a user identifier, second server computer data from the second selected identification response message, and second interaction data. Then, the resource provider computer 404 or other resource provider computer sends the second user credential verification request message to the general authentication application.

[0176] Then, the general authentication application receives a second user credential verification request message, which includes a user identifier, second server computer data, and second interaction data between the resource provider (or another resource provider computer) and the user of user device 402 for a second interaction. The first server computer data may originate from the first server computer, and the second server computer data may originate from the second server computer.

[0177] The universal authentication application can then send a second user credential verification request message to a web browser, which invokes an authenticator to verify the user's biometric information. After the authenticator authenticates the user, as described herein, the universal authentication application receives a second user credential verification response message from the authenticator. The second user credential verification response message includes second signed interaction data.

[0178] Then, the universal authentication application sends the second user credential verification response message to resource provider computer 404 in other resource provider computers. Resource provider computer 404 or other resource provider computers then receive the second user credential verification response message from the authenticator via the universal authentication application. Then, if the server computer verifies the signature of the second signed interaction data, resource provider computer 404 or other resource provider computers can provide the second signed interaction data to multiple server computers 406 to obtain portable device credentials or masked portable device credentials associated with the user. Then, resource provider computer 404 or other resource provider computers and other devices in the system can perform a process similar to steps 22-29 of the second interaction.

[0179] Figure 5A and 5BA user interface illustrating an exemplary user experience flow for combining biometric identification with WebAuthn according to various embodiments is shown. Figure 5A and 5B This includes various images (e.g., frames) displayed on the user device's screen. Each frame may correspond to... Figure 3-4 The steps in the process. For example, at frame 510, the user can select a resource (e.g., a pair of shoes) and proceed to checkout on a webpage maintained by the resource provider's computer.

[0180] At frame 520, after the user selects to checkout, the user device may prompt the user to verify their identity (e.g., by providing biometric information). The user can then input their biometric information into the user device's authenticator. For example, the user can scan their fingerprint, facial recognition, etc., on the user device. The user device's authenticator can then authenticate the user based on the input biometric information. If the user's input biometric information matches stored biometric information, the user device can begin displaying from frame 530.

[0181] At frame 530, the user device may display an indication that the user's fingerprint has been identified (e.g., the user has been authenticated).

[0182] At frame 540, after the user device receives the list of portable device credentials (as described above), the user device may prompt the user to select a portable device credential presented in the list. For example, the user may associate with multiple portable device credentials, which are displayed to the user for selection during interaction. The user may select at least one portable device credential (e.g., a card account).

[0183] At frame 550, after a portable device credential has been selected, the user device may prompt the user for confirmation. After the user confirms the interaction using the selected portable device credential, the user device may provide the selected portable device credential to the resource provider's computer.

[0184] At frame 560, after the resource provider communicates with the server computer regarding the authorization of the interaction, the user device can display a confirmation message to the user. The confirmation message can indicate whether the interaction has been authorized, thereby ending the interaction between the user device and the resource provider's computer.

[0185] The embodiments disclosed herein offer numerous advantages. For example, conventional secure remote platform systems such as SRT systems use browser cookies to authenticate user devices and retrieve registered account information for different cards. One problem with this is that browser cookies stored on the user's device can be stolen or accidentally deleted. The embodiments provide the advantage that browser cookies do not need to be stored on the user's device. Therefore, user data security is enhanced, and the data storage requirements of the user's device are reduced.

[0186] Embodiments of this disclosure further offer advantages over relying solely on WebAuthn, which provides a method for authenticating users of a web application using other types of information, such as biometric authentication. One drawback of combining WebAuthn with biometric authentication is that separate biometric verification may be required for each account credential associated with a user. Therefore, when retrieving account information using different SRT systems to display a list of cards for interactive selection during interaction, separate biometric reads may be requested for each SRT system.

[0187] This is burdensome for both the user and the devices involved in the process. For example, a user needs to enter their biometric information multiple times to allow multiple SRT systems to provide portable device credentials to be displayed in the card list. The embodiments provide the advantage of requesting biometric information once, even while multiple SRT systems are waiting for user authentication before providing portable device credentials. Furthermore, the embodiments offer the advantage of reducing the number of communications within the system. For example, if three SRT systems are involved, conventionally each SRT system needs to communicate with the user device to request biometric authentication. However, according to various embodiments, a single user credential verification request can be provided to a universal authentication application on the user device, thereby reducing the number of communications with the user device by 66% (in this example).

[0188] The embodiments offer additional advantages. In conventional methods (e.g., using WebAuthn alone), processing capacity becomes limited when a user device can only request a single biometric read at a time. This increases the overall processing time for the interaction. The embodiments offer the advantage of shorter processing times because only a single biometric authentication process is required.

[0189] Although the steps in the flowcharts and process flows 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 they may still be present in embodiments of the invention.

[0190] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as 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 (e.g., hard disk drive or floppy disk), or optical media (e.g., optical disc (CD) or digital versatile optical disc (DVD)), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0191] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium 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.

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

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

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

Claims

1. A method for security authentication, the method comprising: The general authentication application receives a user credential verification request message from the resource provider's computer. The user credential verification request message includes a user identifier, server computer data, and interaction data for the interaction between the resource provider and the user device on the resource provider's computer. The general authentication application sends the user credential verification request message to the web browser, and the web browser calls the authenticator to verify the user's biometric information. The general authentication application receives a user credential verification response message from the authenticator, the user credential verification response message including signed interaction data; as well as The general authentication application sends the user credential verification response message to the resource provider computer, wherein the resource provider computer is programmed to provide at least the signed interactive data to a plurality of server computers, receive a first portable device credential associated with the first server computer from a first server computer, and receive a second portable device credential associated with the second server computer from a second server computer, wherein the first portable device credential is different from the second portable device credential.

2. The method of claim 1, wherein the universal authentication application is a component on the user device.

3. The method of claim 2, wherein the user device further comprises the authenticator.

4. The method of claim 1, wherein the server computer data is first server computer data, and wherein, prior to receiving the user credential verification request message, the resource provider computer performs the following operations: a) receiving an interaction request message including an identification identifier from the user device; b) providing an identification request message including the identification identifier to the plurality of server computers; c) receiving one or more identification response messages from one or more of the plurality of server computers, each identification response message including the user identifier and the server computer data associated with each corresponding server computer; d) selecting a selected identification response message from the one or more identification response messages; and e) generating the user credential verification request message, the user credential verification request message including the user identifier, the first server computer data of the selected identification response message, and the interaction data.

5. The method of claim 4, wherein the universal authentication application provides a user credential verification request message to the web browser for the interaction, wherein the universal authentication application receives the user credential verification request message from the resource provider computer, regardless of which of the plurality of server computers is associated with the selected identification response message.

6. The method of claim 1, wherein the server computer data originates from any one of the plurality of server computers.

7. The method of claim 1, wherein the authenticator determines whether to verify the user's biometric information based at least on the server computer data.

8. The method of claim 7, wherein the first portable device credential and the second portable device credential are shielded portable device credentials, wherein the resource provider computer obtains each of the shielded portable device credentials from a different server computer based on the signed interaction data generated by the authenticator.

9. The method according to claim 1, wherein the user credential verification request message is a first user credential verification request message, the server computer data is first server computer data, the interaction data is first interaction data, the interaction is a first interaction, the user credential verification response message is a first user credential verification response message, and the signed interaction data is first signed interaction data. The method further includes: The general authentication application receives a second user credential verification request message from the resource provider computer or another resource provider computer. The second user credential verification request message includes the user identifier, second server computer data, and second interaction data for a second interaction between the resource provider computer and the user device, wherein the first server computer data originates from the first server computer and the second server computer data originates from the second server computer. The general authentication application sends the second user credential verification request message to the web browser, and the web browser calls the authenticator to verify the user's biometric information. The general authentication application receives a second user credential verification response message from the authenticator, the second user credential verification response message including second signed interaction data; as well as The general authentication application sends a second user credential verification response message to the resource provider computer, wherein the resource provider computer provides at least the second signed interaction data to at least one of the plurality of server computers to retrieve the first portable device credential associated with the first server computer or the second portable device credential associated with the second server computer.

10. A user equipment, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: The user device's general authentication application receives a user credential verification request message from the resource provider's computer. The user credential verification request message includes a user identifier, server computer data, and interaction data for the interaction between the resource provider's computer and the user of the user device. The general authentication application sends the user credential verification request message to the web browser, and the web browser calls the authenticator to verify the user's biometric information. The universal authentication application receives a user credential verification response message from the authenticator, the user credential verification response message including signed interaction data; and The general authentication application sends the user credential verification response message to the resource provider computer, wherein the resource provider computer is programmed to provide at least the signed interactive data to a plurality of server computers, receive a first portable device credential associated with the first server computer from a first server computer, and receive a second portable device credential associated with the second server computer from a second server computer, wherein the first portable device credential is different from the second portable device credential.

11. The user device of claim 10, wherein after the authenticator verifies the user's biometric information, the authenticator signs the interaction data using a private key.

12. The user device of claim 10, wherein the user identifier is a universally unique identifier.

13. The user device according to claim 10, wherein the user credential verification request message is a first user credential verification request message, the server computer data is first server computer data, the interaction data is first interaction data, the interaction is a first interaction, the user credential verification response message is a first user credential verification response message, and the signed interaction data is first signed interaction data. The method further includes: The general authentication application receives a second user credential verification request message from the resource provider computer or another resource provider computer. The second user credential verification request message includes the user identifier, second server computer data, and second interaction data for a second interaction between the resource provider computer and the user device, wherein the first server computer data originates from the first server computer and the second server computer data originates from the second server computer. The general authentication application sends the second user credential verification request message to the web browser, and the web browser calls the authenticator to verify the user's biometric information. The general authentication application receives a second user credential verification response message from the authenticator, the second user credential verification response message including second signed interaction data; as well as The general authentication application sends a second user credential verification response message to the resource provider computer, wherein the resource provider computer provides at least the second signed interaction data to at least one of the plurality of server computers to retrieve the first portable device credential associated with the first server computer or the second portable device credential associated with the second server computer.

14. The user device of claim 10, wherein the interaction is secure data interaction, secure web page interaction, or secure location interaction.

15. A method for security authentication, the method comprising: The resource provider's computer receives an interactive request message, including an identification identifier, from the user device; The resource provider computer provides an identification request message, including the identification identifier, to multiple server computers; The resource provider computer receives two or more identification response messages from two or more of the plurality of server computers, each identification response message including a user identifier and server computer data; The resource provider's computer selects one or more identification response messages from the selected identification response messages; The resource provider's computer generates a user credential verification request message, which includes the user identifier, the server computer data of the selected identification response message, and interaction data. The resource provider's computer sends the user credential verification request message to the general authentication application, wherein the general authentication application provides the user credential verification request message to the web browser, and the web browser calls the authenticator to verify the user's biometric information on the user device. The resource provider's computer receives a user credential verification response message from the authenticator via the general authentication application. The user credential verification response message includes signed interaction data. The resource provider computer provides the signed interaction data to the plurality of server computers, wherein each of the plurality of server computers verifies the signature of the signed interaction data. as well as The resource provider's computer receives portable device credentials from the plurality of server computers.

16. The method of claim 15, further comprising: An ordered list of the portable device credentials is generated by the resource provider's computer; The resource provider computer provides the ordered list of portable device credentials to the user device, wherein the user device displays the ordered list of portable device credentials to its user, receives a selection of a portable device credential from the ordered list, and provides the selection of the portable device credential to the resource provider computer; and The resource provider's computer receives the selection of the portable device credentials from the user device.

17. The method of claim 16, further comprising: The resource provider's computer generates an authorization request message that includes at least the selection of portable device credentials; The resource provider computer provides the authorization request message to the server computer, wherein the server computer determines whether to authorize the interaction associated with the signed interaction data and the portable device credentials, and generates an authorization response message including at least an indication of whether the interaction is authorized; as well as The resource provider's computer receives the authorization response message from the server computer.

18. The method of claim 15, wherein the interaction request message is a first interaction request message, the identification request message is a first identification request message, the one or more identification response messages are one or more first identification response messages, the server computer data is first server computer data, the identification response message is a first identification response message, the user credential verification request message is a first user credential verification request message, the interaction data is first interaction data, the user credential verification response message is a first user credential verification response message, and the signed interaction data is first signed interaction data. The method further includes: The resource provider's computer receives a second interaction request message, including an identification identifier, from the user device; The resource provider computer provides a second identification request message, including the identification identifier, to the plurality of server computers; The resource provider computer receives one or more second identification response messages from one or more of the plurality of server computers, each second identification response message including the user identifier and second server computer data; The resource provider computer selects a second selected identification response message from the one or more identification response messages, wherein the second identification response message is received from a server computer different from the server computer that received the first identification response message; The resource provider's computer generates a second user credential verification request message, which includes the user identifier, the second server computer data of the second selected identification response message, and second interaction data. The resource provider's computer sends the second user credential verification request message to the general authentication application, wherein the general authentication application provides the second user credential verification request message to the web browser, and the web browser calls the authenticator to verify the biometric information of the user on the user device. as well as The resource provider's computer receives a second user credential verification response message from the authenticator via the general authentication application. The second user credential verification response message includes second signed interaction data.

19. The method of claim 15, wherein selecting the identification response message from the one or more identification response messages further comprises: The resource provider's computer selects the first received identification response message from the one or more identification response messages, wherein the first received identification response message is the selected identification response message.

Images