EP4785520A1

EP4785520A1 - Authentication with relying party and authenticating party

Info

Publication number: EP4785520A1
Application number: EP25880923.5A
Authority: EP
Inventors: Jason LIGHTMAN; Elisa Catherine DUARTE
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2024-10-23
Filing date: 2025-10-23
Publication date: 2026-08-05
Also published as: CN122270888A; WO2026090407A1

Abstract

A computer receives a credential and a user device identifier from a relying party computer. The computer determines whether or not a token related to the user device identifier exists and determines whether or not the credential is associated with a cryptographic authentication process. The computer provides a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer. Based on the status message, the computer receives a challenge request message from the relying party computer. The computer generates a challenge and provides the challenge to a user device via the relying party computer or to the user device. The user device performs an authentication process in response to the challenge and provides an authentication assertion to the computer directly or via the relying party computer. The computer verifies the authentication assertion and provides authentication results to an authorizing entity computer.

Description

AUTHENTICATION WITH RELYING PARTY AND AUTHENTICATING PARTY CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/710,748, filed October 23, 2024, which is herein incorporated by reference in its entirety for all purposes.

BACKGROUND

[0002] Passkeys based on fast identify online (FIDO) standards can replace passwords and can be used to securely authenticate a user. FIDO authentication uses standard public key cryptography techniques to provide authentication. During registration with an online service, a user device creates a new cryptographic key pair that is bound to the web service domain. The user device retains the private key and registers the public key with the online service. These cryptographic key pairs, called passkeys, are unique to every online service.

[0003] With FIDO, the user device must prove possession of the private key by signing a challenge for sign-in to be completed. This can occur once the user verifies the sign-in locally on their device, via a biometric, local PIN, or touch of a FIDO security key. Sign-in is completed via a challenge-response from the user device and the online service; the service does not see or ever store the private key.

[0004] However, such passkey systems face challenges when multiple different entities operating different computers wish to be involved in the authentication process for an interaction. For example, a storage application server may wish to perform passkey type authentication of its users and can implement a passkey authentication process. However, other entities, such as processing networks or authorizing entities may also wish to participate in the authentication of users conducting transactions with credentials or tokens associated with those entities.

[0005] Embodiments of the disclosure address this problem and other problems individually and collectively. SUMMARY

[0006] One embodiment is related to a method comprising: receiving, by an authenticating computer, a credential and a user device identifier from a relying party computer; determining, by the authenticating computer, whether or not a token related to the user device identifier exists; determining, by the authenticating computer, whether or not the credential is associated with a cryptographic authentication process; providing, by the authenticating computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer; based on the status message, receiving, by the authenticating computer, a challenge request message from the relying party computer; generating, by the authenticating computer, a challenge; providing, by the authenticating computer, the challenge to a user device via the relying party computer or to the user device, wherein the user device performs an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer; verifying, by the authenticating computer, the authentication assertion; and providing, by the authenticating computer, authentication results based on the verification to an authorizing entity computer.

[0007] Another embodiment is related to an authenticating computer comprising: a processor; and a non-transitory computer readable medium comprising code, executable by the processor for performing a method comprising: receiving a credential and a user device identifier from a relying party computer; determining whether or not a token related to the user device identifier exists; determining whether or not the credential is associated with a cryptographic authentication process; providing a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer; based on the status message, receiving a challenge request message from the relying party computer; generating a challenge; providing the challenge to a user device via the relying party computer or to the user device, wherein the user device performs an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer; verifying the authentication assertion; and providing authentication results based on the verification to an authorizing entity computer.

[0008] Another embodiment is related to a method comprising: providing, by a relying party computer, a credential and a user device identifier to an authenticating computer, wherein the authenticating computer determines whether or not a token related to the user device identifier exists and determines whether or not the credential is associated with a cryptographic authentication process; receiving, by the relying party computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process from the authenticating computer; based on the status message, generating, by the relying party computer, a challenge request message; providing, by the relying party computer, the challenge request message to the authenticating computer, wherein the authenticating computer generates a challenge; receiving, by the relying party computer, the challenge from the authenticating computer; and providing, by the relying party computer, the challenge to the user device, wherein the user device performs an authentication process in response to the challenge and generates an authentication assertion for authentication verification by the authenticating computer.

[0009] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 shows a block diagram of an authentication system according to embodiments.

[0011] FIG. 2 shows a block diagram of components of an authenticating computer according to embodiments.

[0012] FIG. 3 shows a block diagram of components of a relying party computer according to embodiments.

[0013] FIG. 4 shows a flow diagram illustrating authentication method where no passkey is present according to embodiments.

[0014] FIG. 5 shows a flow diagram illustrating a first passkey present authentication method according to embodiments.

[0015] FIG. 6 shows a flow diagram illustrating a second passkey present authentication method according to embodiments.

[0016] FIG. 7 shows a diagram illustrating an example user interface according to embodiments.

[0017] FIG. 8 shows a block diagram of an authorization system according to embodiments. DETAILED DESCRIPTION

[0018] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0019] A “user” may include an individual or a machine that operates something. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0020] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0021] A “user device identifier” can include a sequence of characters used to identify or refer to a user device. A user device identifier can be associated with a particular user device. A user device identifier can include alphanumeric characters that may refer to a user device. A user device identifier can include a host card emulation device identifier.

[0022] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc.

[0023] A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services. [0024] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issueracquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0025] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.

[0026] An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0027] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0028] A “cryptogram” may include encrypted information. For example, a cryptogram can be a set of text encrypted with an encryption key.

[0029] An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing computer and/or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment 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 a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.

[0030] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval — transaction was approved; Decline — transaction was not approved; or Call Center — response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0031] An “interaction” may refer to a reciprocal action, effect or influence. For example, an interaction could be an exchange or transaction between two or more parties.

[0032] An “iframe” can include an HTML element. An iframe can be an inline frame. An iframe can used to embed a document within a current HTML document. For example, an iframe can provide for the functionality of embedding content from another website or source into a web page, which can act as a webpage within a webpage.

[0033] “WebAuthn” can include a web standard. WebAuthn can include a web standard provided by the World Wide Web Consortium. WebAuthn (also referred to as web authentication) can include an open standard and API that enables passwordless and more secure online login experiences using public-key cryptography. WebAuthn can include a specification of a JavaScript API that allows applications to perform secure authentication for both multi-factor and single-factor scenarios.

[0034] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).

[0035] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

[0036] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0037] Cryptographic authentication processes, such as passkeys based on FIDO (Fast Identity Online) standards, provide for secure authentication of users using cryptography keys. Upon registration with an computer, a user device can generate unique cryptographic key(s) that are bound to the domain of the computer. For example, the user device can generate a public private cryptographic key pair, where the private cryptographic key is retained securely on the user device and the cryptographic public key is registered with the computer.

[0038] During authentication, the user device can demonstrate possession of the cryptographic key by signing a challenge issued by the computer, which may require the user to locally authenticate via a biometric input, a PIN, or a physical security key. The computer can validate the response using a corresponding cryptographic key (e.g., a public key of a public private key pair or a symmetric cryptographic key). While this system streamlines authentication for individual computers, complexities arise in scenarios where multiple computers, such as an authenticating computer (which may be operated by an entity associated with a network processing computer that process interaction), storage application servers (e.g., digital wallet server computers which may also be relying party computers), as well as authorizing networks are present during the authentication process, and potentially the authorization process, for a single interaction. [0039] To address these technical challenges, embodiments enable collaboration between distinct entities, such as a relying party (e.g., a digital wallet party) and an authenticating party (e.g., a network processing party), in an authentication process.

[0040] During authentication of a user of a user device, an authenticating computer can receive a credential (e.g., an account identifier, a primary account number (PAN), etc.) and a user device identifier from a relying party computer. The authenticating computer can determine whether or not a token (e.g., a host card emulation (HCE) token) related to the user device identifier exists. For example, the HCE token can be a token provisioned to the user device. The authenticating computer can also determine whether or not the credential is associated with a cryptographic authentication process. The authenticating computer can provide a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer. The relying party computer can perform different processing based on the status indictor. Based on the status message, the authenticating computer can receive a challenge request message from the relying party computer. The authenticating computer can generate a challenge (e.g., a cryptographic challenge that includes a nonce). The authenticating computer can provide the challenge to the user device via the relying party computer or to the user device directly. The means by which the challenge is provided may vary depending upon which computer (e.g., the authenticating computer or the relying party computer) the cryptographic authentication process is associated with. Upon receiving the challenge, the user device can perform an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer. The authenticating computer can then verify the authentication assertion and provide authentication results based on the verification to an authorizing entity computer.

[0041] FIG. 1 shows a system 100 according to embodiments of the disclosure. The system 100 comprises a user device 102, a resource provider computer 104, a relying party computer 106, an authenticating computer 108, a cryptographic authentication process server 110, an authorizing entity computer 112, a transport computer 114, and a network processing computer 116.

[0042] The user device 102 can be in operative communication with the resource provider computer 104, the relying party computer 106, and the authenticating computer 108. The resource provider computer 104 can be in operative communication with the relying party computer 106 and the transport computer 114. The relying party computer 106 can be in operative communication with the authenticating computer 108. In some embodiments, the relying party computer 106 can be in operative communication with the cryptographic authentication process server 110. The authenticating computer 108 can be in operative communication with the cryptographic authentication process server 110 and the authorizing entity computer 112. The network processing computer 116 can be in operative communication with the authorizing entity computer 112 and the transport computer 114.

[0043] For simplicity of illustration, a certain number of components are shown in FIG. 1. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG. 1.

[0044] Messages between the devices of the system 100 illustrated in FIG. 1 can be transmitted using a secure communications 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 the like. The communications network may include any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0045] The user device 102 can include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), personal digital assistants (PDAs), Internet of Things (loT) devices, and/or the like. The user device 102 can initiate interactions (e.g., transactions) with resource provider computers and/or access devices. For example, the user device 102 can select one or more items for the interaction on a webpage hosted by the resource provider computer 104 (e.g., a merchant webpage). [0046] The resource provider computer 104 can include any suitable computational apparatus operated by a resource provider (e.g., a merchant). In some embodiments, the resource provider computer 104 may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a merchant). In some embodiments, the resource provider computer 104 may be configured to send data to the network processing computer 116 via the transport computer 114 as part of a payment verification and/or authentication process for a transaction between the user (e.g., consumer) and the resource provider. The resource provider computer 104 may also be configured to generate authorization request messages for transactions between a resource provider and a user, and route the authorization request messages to the authorizing entity computer 112 for transaction processing.

[0047] The relying party computer 106 can include a server computer. The relying party computer 106 can be operated by a first entity. The relying party computer 106 can manage passkeys created by the user device. The relying party computer 106 can facilitate interactions between the user device 102 and the resource provider computer 104. The relying party computer 106 can obtain interaction data from the resource provider computer 104 during the interaction. The relying party computer 106 can communicate with the authenticating computer 108 to obtain a challenge for authenticating the user during the interaction. In some embodiments, the relying party computer 106 can include a storage application server such as a digital wallet server computer.

[0048] The authenticating computer 108 can include a server computer. The authenticating computer 108 can be operated by a second entity. The authenticating computer 108 can manage passkeys created by the user device 102. The authenticating computer 108 can generate challenges for authenticating the user during the interaction.

[0049] The cryptographic authentication process server 110 can include a server that stores passkeys. The cryptographic authentication process server 110 can include a database. The database can include any suitable database. The database may be a conventional, fault tolerant, relational, scalable, secure database such as those commercially available from Oracle™ or Sybase™.

[0050] The transport computer 114 can include a server computer. The transport computer 114 may be associated with an acquirer, which may be an entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers.

[0051] The network processing computer 116 can include a server computer. The network processing computer 116 may be disposed between the transport computer 114 and the authorizing entity computer 112. The network processing computer 116 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the network processing computer 116 may comprise a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The network processing computer 116 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The network processing computer 116 may use any suitable wired or wireless network, including the Internet.

[0052] In some embodiments, the authenticating computer 108 can be a part of the network processing computer 116. As such, the network processing computer 116 can be the authenticating computer 108.

[0053] The authorizing entity computer 112 can include a server computer operated by an authorizing entity. The authorizing entity computer 112 may be associated with an authorizing entity, which may be an entity that authorizes a request. An example of an authorizing entity may be an issuer, which may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue and manage an account associated with the user device 102.

[0054] As an illustrative example, the user may conduct a transaction with the resource provider (e.g., a merchant) using the user device 102. The transaction may be a payment transaction (e.g., for the purchase of a good or service), an access transaction (e.g., for access to a transit system), or any other suitable transaction. The user device 102 may indicate payment account information (e.g., a PAN) to the resource provider electronically, such as in an online transaction. [0055] In order to authorize a transaction, an authorization request message can be generated by the resource provider computer 104 and then forwarded to the transport computer 114. After receiving the authorization request message, the authorization request message is then sent to the network processing computer 116. The network processing computer 116 then forwards the authorization request message to the corresponding authorizing entity computer 112 associated with an authorizing entity associated with the user's payment account.

[0056] After the authorizing entity computer 112 receives the authorization request message, the authorizing entity computer 112 sends an authorization response message back to the network processing computer 116 to indicate whether the current transaction is authorized (or not authorized). The network processing computer 116 then forwards the authorization response message back to the transport computer 114. In some embodiments, network processing computer 116 may decline the transaction even if the authorizing entity computer 112 has authorized the transaction, for example depending on a value of the fraud risk score. The transport computer 114 then sends the response message back to the resource provider computer 104.

[0057] After the resource provider computer 104 receives the authorization response message, the resource provider computer 104 may then provide the authorization response message for the user. The resource provider may provide a web page or other indication of the authorization response message as a virtual receipt. The receipts may include transaction data for the transaction.

[0058] FIG. 2 shows a block diagram of an authenticating computer 108 according to embodiments. The exemplary authenticating computer 108 may comprise a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer readable medium 208. The computer readable medium 208 can comprise a number of modules. The computer readable medium 208 can comprise a mapping module 208A and a challenge module 208B.

[0059] The memory 202 can be used to store data and code. For example, the memory 202 can store cryptographic keys, mapping tables, verification information, etc. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. [0060] The computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: receiving, by an authenticating computer, a credential and a user device identifier from a relying party computer; determining, by the authenticating computer, whether or not a token related to the user device identifier exists; determining, by the authenticating computer, whether or not the credential is associated with a cryptographic authentication process; providing, by the authenticating computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer; based on the status message, receiving, by the authenticating computer, a challenge request message from the relying party computer; generating, by the authenticating computer, a challenge; providing, by the authenticating computer, the challenge to a user device via the relying party computer or to the user device, wherein the user device performs an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer; verifying, by the authenticating computer, the authentication assertion; and providing, by the authenticating computer, authentication results based on the verification to an authorizing entity computer.

[0061] The mapping module 208A may comprise code or software, executable by the processor 204, for identifying related data items. The mapping module 208A, in conjunction with the processor 204, can utilize mapping table to identify one data entry in the mapping table to another data entry in the mapping table. The mapping module 208A, in conjunction with the processor 204, can utilize a token to credential mapping table and a credential to cryptographic authentication process mapping table. For example, the mapping module 208 A, in conjunction with the processor 204, can identify a token in the token to credential mapping table using a credential. As another example, the mapping module 208A, in conjunction with the processor 204, can identify a cryptographic authentication process in the credential to cryptographic authentication process mapping table using a credential.

[0062] The challenge module 208B may comprise code or software, executable by the processor 204, for creating and verifying challenges. The challenge module 208B, in conjunction with the processor 204, can generate challenges that are cryptographic challenges that can challenge a device to authenticate a user of the device. The challenge module 208B, in conjunction with the processor 204, generate a nonce to include in the challenge. The nonce can be a random value. The challenge module 208B, in conjunction with the processor 204, can also obtain a relying party identifier and a user identifier. The challenge module 208B, in conjunction with the processor 204, can generate a challenge using the nonce, the relying party identifier, and the user identifier.

[0063] The network interface 206 may include an interface that can allow the authenticating computer 108 to communicate with external computers. The network interface 206 may enable the authenticating computer 108 to communicate data to and from another device (e.g., the relying party computer 106, the user device 102, the cryptographic authentication process server 110, the authorizing entity computer 112, etc.). Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include Wi-FiTM. Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.

[0064] FIG. 3 shows a block diagram of a relying party computer 106 according to embodiments. The exemplary relying party computer 106 may comprise a processor 304. The processor 304 may be coupled to a memory 302, a network interface 306, and a computer readable medium 308. The computer readable medium 308 can comprise a number of modules. The computer readable medium 308 can comprise a communication module 308A.

[0065] The memory 302 can be used to store data and code. For example, the memory 302 can store cryptographic keys, interaction data, etc. The memory 302 may be coupled to the processor 304 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.

[0066] The computer readable medium 308 may comprise code, executable by the processor 304, for performing a method comprising: providing, by a relying party computer, a credential and a user device identifier to an authenticating computer, wherein the authenticating computer determines whether or not a token related to the user device identifier exists and determines whether or not the credential is associated with a cryptographic authentication process; receiving, by the relying party computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process from the authenticating computer; based on the status message, generating, by the relying party computer, a challenge request message; providing, by the relying party computer, the challenge request message to the authenticating computer, wherein the authenticating computer generates a challenge; receiving, by the relying party computer, the challenge from the authenticating computer; and providing, by the relying party computer, the challenge to the user device, wherein the user device performs an authentication process in response to the challenge and generates an authentication assertion for authentication verification by the authenticating computer.

[0067] The communication module 308A may comprise code or software, executable by the processor 304, for communicating. The communication module 308A, in conjunction with the processor 304, can to communicate with other computers, devices, and entities in a system. The communication module 308A may comprise or include code, instructions, routines, subroutines, etc., that may be used by the processor 304 in order to enable the relying party computer 106 to communicate with other computers or devices, including user devices, resource provider computers, authenticating computers, etc. using any appropriate communications protocol. The communication module 304A may comprise code or instructions, executable by the processor 304 for sending, receiving, formatting, and interpreting requests, messages, payloads and other data.

[0068] The network interface 306 may similar to the network interface 206 and will not be repeated here.

[0069] FIG. 4 shows a flow diagram illustrating authentication method where a user’s credential is not associated with a cryptographic authentication process is present according to embodiments. A method 400 illustrated in FIG. 4 can be performed by the user device 102, the resource provider computer 104, the relying party computer 106, the authenticating computer 108, and the authorizing entity computer 112. The method 400 can provide for secure authentication of users and/or user devices during interactions between a user and a resource provider, where a user’ s credential is not associated with a cryptographic authentication process (e.g., is not associated with a passkey and FIDO authentication method). [0070] At step 402, a user device 102 can initiate an interaction (e.g., an access request interaction, a payment transaction, a data transfer interaction, etc.) with a resource provider computer 104. For example, the user device 102 can display a resource provider webpage in a browser to the user of the user device 102. The user can select resources and can select to checkout. In some embodiments, the user device 102 can accept input from the user related to the interaction. For example, the user device 102 can accept a credential (e.g., a primary account number) and/or other information from the user for the interaction. The user device can provide the credential and/or other information related to the interaction to the resource provider computer 104.

[0071] At step 404, after receiving the interaction data (e.g., including the credential, an amount, a timestamp, and/or any other interaction related data), the resource provider computer 104 can provide the interaction data to the relying party computer 106.

[0072] At step 406, after receiving the interaction data from the resource provider computer 104 for the interaction between the user device 102 and the resource provider computer 104, the relying party computer 106 can generate a device identifier request message. The relying party computer 106 can provide the device identifier request message to the user device 102. The relying party computer 106 can identify the user device 102 using a phone number, user identifier, or other identification information that is included in the interaction data.

[0073] The user device 102 can respond to the relying party computer 106 with the user device identifier (e.g., a host card emulation device identifier). The user device identifier can be referred to as a first user device identifier.

[0074] At step 408, after receiving the user device identifier from the user device 102, the relying party computer 106 can provide the credential and the first user device identifier to the authenticating computer 108.

[0075] In some embodiments, at step 410, the authenticating computer 108 can communicate directly with the user device 102 to request additional device data. The authenticating computer 108 can communicate with the user device 102 using a JavaScript program (or other suitably created program) that is loaded onto the user device 102. As an example, the additional device data can include a user device public key that is associated with a user device private key stored in the user device 102. [0076] The user device 102 can provide the additional device data to the authenticating computer 108.

[0077] At step 412, the authenticating computer 108 can 1) determine whether or not a token related to the user device identifier exists and 2) determine whether or not the credential is associated with a cryptographic authentication process (e.g., a passkey process as identified by a cryptographic key, which may be referred to as a passkey).

[0078] To determine whether or not a token related to the user device identifier exists, the authenticating computer 108 can utilize a token to credential mapping table. The authenticating computer 108 can utilize the credential, received from the relying party computer 106, to search the token to credential mapping table for a token and a user device identifier that are associated with the credential. The token can also be associated with a token identifier. The token identifier can be an host card emulation token identifier and the token can be an host card emulation token. The authenticating computer 108 may have received this information in a prior registration process.

[0079] If a token associated with the credential exists in the token to credential mapping table, then the authenticating computer 108 can generate an indication that the token exists.

[0080] If no token exists in the token to credential mapping table, then the authenticating computer 108 can generate an indication that the token does not exist. In some embodiments, when no token exists (e.g., the user device 102 does not have an HCE token for interactions), the authenticating computer 108 can perform an enrollment process with the user device 102 to generate and provision a token to the user device 102 and store a new mapping of the credential to the token into the token to credential mapping table.

[0081] The authenticating computer 108 can then determine whether or not the credential is associated with a cryptographic authentication process. The authenticating computer 108 can utilize a credential to cryptographic authentication process mapping table (e.g., a PAN to passkey mapping table). The authenticating computer 108 can utilize the credential to search the credential to cryptographic authentication process mapping table for a cryptographic authentication process that is associated with the credential. The cryptographic authentication process can include a cryptographic key such as a passkey.

[0082] If a cryptographic authentication process is associated with the credential (e.g., the credential is associated with a passkey) in the credential to cryptographic authentication process mapping table, then the computer can generate an indication that a cryptographic authentication process exists.

[0083] If no cryptographic authentication process is associated with the credential (e.g., the credential is not associated with a passkey) in the credential to cryptographic authentication process mapping table, then the computer can generate an indication that no cryptographic authentication process exists.

[0084] At step 414, the authenticating computer 108 can generate a status message. The status message can indicate whether or not the credential is associated with the cryptographic authentication process to the relying party computer. For example, the status message can include the indication of whether or not the cryptographic authentication process exists for the credential.

[0085] In some embodiments, the status message can also include the indication of whether or not the credential is associated with a token.

[0086] The authenticating computer 108 can provide the status message to the relying party computer 106.

[0087] As an illustrative example, the status message as illustrated in FIG. 4 can indicate that a token exists, but the credential is not associated with a cryptographic authentication process (e.g., is not associated with a passkey).

[0088] At step 416, after receiving the status message from the authenticating computer 108, the relying party computer 106 can determine that the credential is not associated with a cryptographic authentication process. The relying party computer 106 can generate a signature request message. The signature request message can request a user device 102 to generate a signature utilizing a particular cryptographic key stored by the user device 102. The relying party computer 106 can provide the signature request message to the user device 102.

[0089] After receiving the signature request message from the relying party computer 106, the user device 102 can create a signature using a cryptographic key that is associated with the token and is stored in the user device 102.

[0090] The cryptographic key can be a symmetric cryptographic key. For example, the cryptographic key can be a symmetric cryptographic key, where a first instance of the symmetric cryptographic key is securely stored by the user device 102 and a second instance of the symmetric key is securely stored by the authenticating computer 108. As such the symmetric key pair can include a user device symmetric cryptographic key and an authenticating computer symmetric cryptographic key.

[0091] In other embodiments, the cryptographic key can be an asymmetric cryptographic key. For example, the cryptographic key can be a private key of a public private key pair. The cryptographic key can be a user device private key that corresponds to a user device public key. The user device private key can be utilized to sign data, while the user device public key can be utilized to verify signed data.

[0092] The cryptographic key can be replenished (e.g., updated) over time. In some embodiments, the authenticating computer 108 or other device, such as a network processing computer, can provide new cryptographic keys to the user device 102. For example, the authenticating computer 108 can provide a new cryptographic key to the user device 102 once per day, once per week, once per month, once per year, etc. In other embodiments, the cryptographic key can be derived from data and symmetrically updated by the user device 102 and the authenticating computer 108. For example, the cryptographic key can be derived from timestamps, credentials, tokens, cryptographic keys, counters, nonces, etc.

[0093] The user device 102 can generate a signature response message comprising the signature. The user device 102 can provide the signature response message to the relying party computer 106.

[0094] At step 418, after obtaining the signature from the user device 102, the relying party computer 106 can generate a challenge request message. The challenge request message can include the signature. The challenge request message can include a request for an authentication challenge that is to be provided to the user device 102 to challenge the user device 102 and/or the user to authenticate.

[0095] The relying party computer 106 can provide the challenge request message to the authenticating computer 108.

[0096] At step 420, after receiving the challenge request message from the relying party computer 106, the authenticating computer 108 can verify the signature that is included in the challenge request message. The authenticating computer 108 can verify the signature using an second cryptographic key that corresponds to a first cryptographic key utilized by the user device 102 (e.g., the user device cryptographic key). [0097] In some embodiments, the second cryptographic key can be a symmetric key that is symmetric to the user device cryptographic key, where the second cryptographic key is an authenticating computer cryptographic key.

[0098] In other embodiments, the second cryptographic key can be an asymmetric key that is symmetric to the user device cryptographic key. For example, the user device cryptographic key can be a user device private key and the second cryptographic key can be a user device public key.

[0099] If the signature is valid, then the authenticating computer 108 can proceed with step 422. If the signature is not valid, then the authenticating computer 108 can terminate the process and notify the relying party computer 106 of the invalid signature.

[0100] At step 422, the authenticating computer 108 can generate a challenge. The challenge can be a cryptographic challenge. In some embodiments, the challenge can include a relying party identifier, a user identifier, and a nonce. The relying party identifier can be a website’s domain. In some embodiments, the domain can be hashed before being stored by the authenticating computer 108 to preserve privacy. For example, the relying party identifier can be relyingParty.com, relyingParty.Visa.com, etc. The user identifier can be an identifier that uniquely identifies the user and/or the user device 102. For example, the user identifier can be a device identifier, the token, the credential, or other identifier such as an email address. The nonce can be a one-time cryptographic value that that can be updated for each challenge to prevent replay attacks.

[0101] As an illustrative example, the challenge can be the nonce concatenated with any other suitable data (e.g., the relying party identifier, and the user identifier, etc.). Once the user device obtains the challenge, the user device 102 can generate a signature on the challenge using a cryptographic key once the user device 102 authenticates the user. When the authenticating computer 108 receives the signed challenge (also referred to as an authentication assertion), the authenticating computer 108 can verify the signature using a cryptographic key that corresponds to the cryptographic key used to sign the challenge. Only the user device 102 should have access to the signing cryptographic key, therefore, by validating the signature, the authenticating computer 108 can determine that the challenge was signed by the user device 102. The authenticating computer 108 can also further verify that the challenge in the signed challenge matches the sent challenge (e.g., includes the same nonce, as well as other data). [0102] The authenticating computer 108 can generate a challenge response message comprising the challenge. The authenticating computer 108 can provide the challenge response message to the relying party computer 106 in response to the challenge request message.

[0103] At step 424, after receiving the challenge response message from the authenticating computer 108, in some embodiments, the relying party computer 106 can provide the challenge to the user device 102 and can invoke a WebAuthn API.

[0104] At step 426, after receiving the challenge, the user device 102 can perform an authentication process to authenticate the user of the user device 102 based on the challenge. For example, the user device 102 can prompt the user to input a biometric, such as a fingerprint, facial structure, etc. The user device 102 can generate an authentication assertion, which can include a signature, if the user is authenticated. For example, the signature can be a signature created by a user device cryptographic key by signing the challenge.

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

[0106] At step 428, after performing the authentication process, the user device 102 can provide the authentication assertion to the relying party computer 106. The user device 102 can also provide additional data related to the authentication process, such as a public key associated with the signature.

[0107] At step 430, after receiving the authentication assertion, the relying party computer 106 can provide the authentication assertion and the public key to the authenticating computer 108. In some embodiments, the relying party computer 106 can verify the signature in the authentication assertion with the public key.

[0108] At step 432, the authenticating computer 108 can verify the signature in the authentication assertion using the public key. If the authentication assertion is valid, then the authenticating computer 108 can store the authentication assertion and public key in a database, such as in the cryptographic authentication process server 110 or at the authenticating computer 108.

[0109] At step 434, the authenticating computer 108 can provide authentication results to the authorizing entity computer 112. The authentication results can indicate whether or not the authentication assertion is valid. [0110] FIG. 5 shows a flow diagram illustrating a first passkey present authentication method according to embodiments. Steps 502-512 can be similar to steps 402-512 described in reference to FIG. 4 and will not be repeated here. A method 500 illustrated in FIG. 5 can be performed by the user device 102, the resource provider computer 104, the relying party computer 106, the authenticating computer 108, and the authorizing entity computer 112. The method 500 can provide for secure authentication of users and/or user devices during interactions between a user and a resource provider, where a user’s credential is associated with a cryptographic authentication process (e.g., is associated with a passkey and FIDO authentication method) and the cryptographic authentication process is associated with the relying party computer 106.

[OHl] At step 514, the authenticating computer 108 can generate and provide a status message to the relying party computer 106. The status message can include an indication of whether or not the cryptographic authentication process exists for the credential. For the example described in reference to FIG. 5, the status message can indicate that a cryptographic authentication process does exist for the credential (e.g., a passkey does exist and is associated with the credential).

[0112] The status message can also indicate a computer with which the cryptographic authentication process is associated. For example, the cryptographic authentication process can be associated with the relying party computer 106 or the authenticating computer 108. For the example described in reference to FIG. 5, the status message can indicate that the cryptographic authentication process is associated with the relying party computer 106 (e.g., the passkey is associated with the relying party computer 106).

[0113] The cryptographic authentication process may be associated with the relying party computer 106 when the relying party computer 106 maintains a server and/or database for the cryptographic authentication process, for example, such the cryptographic authentication process server 110. The cryptographic authentication process server 110 can be integrated into the relying party computer 106 or can be a separate computer that is in communication with the relying party computer 106.

[0114] At step 516, the relying party computer 106 can generate a challenge request message comprising a request for a challenge. The challenge request message, in some embodiments, can include details related to the interaction. For example, the challenge request message can include the interaction data provided from the resource provider computer 104 to the relying party computer 106. The relying party computer 106 can provide the challenge request message to the authenticating computer 108.

[0115] At step 518, after receiving the challenge request message, the authenticating computer 108 can generate a challenge. The challenge can be a cryptographic challenge. The authenticating computer 108 can generate a challenge response message comprising the challenge. The authenticating computer 108 can provide the challenge response message to the relying party computer 106.

[0116] At step 520, after obtaining the challenge from the authenticating computer 108, the relying party computer 106 can provide the challenge to the user device 102. In some embodiments, the relying party computer 106 can provide the challenge to the user device 102 using a WebAuthn API.

[0117] At step 522, after receiving the challenge, the user device 102 can perform an authentication process to authenticate the user of the user device 102. The authentication process can be an authentication process (e.g., a FIDO authentication process) based on the challenge. If the user is authenticated, then the user device 102 can generate an authentication assertion.

[0118] At step 524, after generating the authentication assertion, the user device 102 can provide the FIDO assertion to the relying party computer 106.

[0119] At step 526, after receiving the authentication assertion, the relying party computer 106 can verify the FIDO assertion.

[0120] At step 528, the relying party computer 106 can provide the authentication assertion to the authenticating computer 108.

[0121] At step 530, after receiving the authentication assertion from the relying party computer 106, the authenticating computer 108 can verify the authentication assertion.

[0122] At step 532, the authenticating computer 108 can provide authentication results to the authorizing entity computer 112. The authentication results can include the authentication assertion or can include an indication of whether or not the user was authenticated.

[0123] FIG. 6 shows a flow diagram illustrating a second passkey present authentication method according to embodiments. Steps 602-612 can be similar to steps 402-412 described in reference to FIG. 4 and will not be repeated here. A method 600 illustrated in FIG. 6 can be performed by the user device 102, the resource provider computer 104, the relying party computer 106, the authenticating computer 108, and the authorizing entity computer 112. The method 600 can provide for secure authentication of users and/or user devices during interactions between a user and a resource provider, where a user’s credential is associated with a cryptographic authentication process (e.g., is associated with a passkey and FIDO authentication method) and the cryptographic authentication process is associated with the authenticating computer 108.

[0124] At step 614, the authenticating computer 108 can provide a status message to the relying party computer 106 indicating that a passkey exists and that the passkey is associated with the authenticating computer 108.

[0125] At step 616, the relying party computer 106 can generate and provide a passkey challenge request message to the authenticating computer 108. The passkey challenge request message can include a request for a passkey challenge. The passkey challenge request message can include the interaction data obtained from the resource provider computer 104 at step 602.

[0126] At step 618, the authenticating computer 108 can generate and provide an iframe to the relying party computer 106. The iframe can be an inline frame that is an HTML element that loads another HTML page within the document. An iframe can be utilized to load another webpage within the parent webpage. An iframe can load code from a referenced source and can render the code as a website that is then put entirely within the parent browsing page. From the user’s perspective, the webpage appears as a single webpage. The authenticating computer 108 can generate the iframe from code that is stored by the authenticating computer 108

[0127] At step 620, after receiving the iframe from the authenticating computer 108, the relying party computer 106 can open the iframe on the webpage that the user device 102 is accessing to perform the interaction with the resource provider computer 104. The relying party computer 106 can open the iframe as a visible iframe or an invisible iframe.

[0128] At step 622, after the iframe has been opened on the webpage, the authenticating computer 108 can provide the challenge and can invoke the WebAuthn API to the user device 102 via the iframe.

[0129] At step 624, after receiving the challenge, the user device 102 can perform an authentication process to authenticate the user of the user device 102. The authentication process can be a FIDO authentication process based on the challenge. If the user is authenticated, then the user device 102 can generate an authentication assertion.

[0130] At step 626, the user device 102 can provide the authentication assertion to the authenticating computer 108 in response to the challenge.

[0131] At step 628, the authenticating computer 108 can verify the authentication assertion.

[0132] At step 630, the authenticating computer 108 can provide the authentication assertion to the relying party computer 106.

[0133] At step 632, the authenticating computer 108 can provide authentication results to the authorizing entity computer 112. The authentication results can include the authentication assertion or can include an indication of whether or not the user was authenticated.

[0134] FIG. 7 shows a diagram illustrating an example user interface according to embodiments. The diagram illustrated in FIG. 7 includes a first user interface 700 and a second user interface 750.

[0135] The first user interface 700 can be displayed on the user device 102. The first user interface 700 can be displayed when the user device 102 receives the challenge. For example, the first user interface 700 can be configured to be presented on the display of the user device 102 upon receiving the challenge from the authenticating computer 108 or the relying party computer 106. The first user interface 700 can engage and prompt the user to verify their identity in connection with a specific interaction, such as a payment transaction or access request.

[0136] The first user interface 700 can include a verify now button 702 that can indicate the user to verify their identity for the interaction. The first user interface 700 also includes an amount 704 that indicates the amount of the interaction. The first user interface 700 also includes a resource provider identifier 706. The resource provider identifier 706 can include the name of the resource provider involved in the interaction. This information can reassure the user regarding the legitimacy and origin of the request.

[0137] Upon user selection of the verify now button 702, the user device 102 can transition to display the second user interface 750. The second user interface 750 can be configured to present a verification prompt 752. The verification prompt 752 can instruct and guide the user to complete the authentication step. For example, the verification prompt 752 can prompt the user to input a biometric identifier (e.g., fingerprint, a facial pattern, etc.) or by performing another form of authentication as supported by the user device.

[0138] FIG. 8 shows a block diagram of an authorization system according to embodiments. FIG. 8 shows a system 800 according to embodiments of the disclosure. The system 800 comprises a user device 802, a resource provider computer 804, a transport computer 806, a network processing computer 808, and an authorizing entity computer 810.

[0139] The user device 802 can be in operative communication with the resource provider computer 804, which can be in operative communication with the transport computer 806. The network processing computer 808 can be in operative communication with the transport computer 806 and the authorizing entity computer 810.

[0140] The user device 802 can include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), personal digital assistants (PDAs), Internet of Things (loT) devices, and/or the like. The user device 802 can initiate interactions (e.g., transactions) with resource provider computers. For example, the user device 802 can select one or more items for the interaction on a webpage hosted by the resource provider computer 804. During the interaction, the user device 802 can provide credentials to the resource provider computer 804 and can provide interaction data to the resource provider computer 804 for authorization of the interaction.

[0141] The resource provider computer 804 can include any suitable computational apparatus operated by a resource provider (e.g., a merchant). In some embodiments, the resource provider computer 804 may include one or more server computers that may host one or more websites associated with the resource provider. In some embodiments, the resource provider computer 804 may be configured to send data to the network processing computer 808 via the transport computer 806 as part of a payment verification and/or authentication process for a transaction between the user (e.g., consumer) and the resource provider. The resource provider computer 804 may also be configured to generate authorization request messages for transactions between the resource provider and the user, and route the authorization request messages to the authorizing entity computer 810 for transaction processing.

[0142] The transport computer 806 can include a server computer. The transport computer 806 may be associated with an acquirer, which may be an entity (e.g., a bank or other account maintaining entity) that has a relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers.

[0143] The network processing computer 808 can include a server computer. The network processing computer 808 may be disposed between the transport computer 806 and the authorizing entity computer 810. The network processing computer 808 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the network processing computer 808 may comprise a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The network processing computer 808 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The network processing computer 808 may use any suitable wired or wireless network, including the Internet.

[0144] The authorizing entity computer 810 can include a server computer operated by an authorizing entity. The authorizing entity computer 810 may be associated with an authorizing entity, which may be an entity that authorizes a request. An example of an authorizing entity may be an issuer, which can include an entity that maintains an account for a user. An issuer may also issue and manage an account associated with the user device 802.

[0145] As an illustrative example of processing an interaction, a user of the user device 802 may initiate an interaction with the resource provider computer 804. The interaction may be a payment transaction (e.g., for the purchase of a good or service), an access transaction (e.g., for access to a transit system), or any other suitable transaction. The user device 802 can indicate payment account information to the resource provider electronically, such as in an online transaction. In some cases, the user device 802 can provide interaction data including data such as a credential(e.g., a primary account number), indications of one or more selected items for the interaction, and/or any other data related to initiating, processing, authenticating, and/or authorizing the interaction. [0146] In some embodiments, the authorization process may occur after the authentication process described herein. For example, after the authentication results are provided to the authorizing entity computer 810 by the authenticating computer 108, the user device 802 and the resource provider computer 804 can perform an authorization process for an interaction between the user device 802 and the resource provider computer 804.

[0147] In order to authorize the transaction, the resource provider computer 804 can generate an authorization request message and forward the authorization request message to the transport computer 806. After receiving the authorization request message, transport computer 806 can transmit the authorization request message to the network processing computer 808.

[0148] Upon receiving the authorization request message, the network processing computer 808 can evaluate the authorization request message. In some embodiments, the network processing computer 808 can determine whether or not to deny the interaction based on evaluated security values. The network processing computer 808, in conjunction with a token vault, can modify the authorization request message to replace any included tokens with primary account numbers that are associated with the tokens.

[0149] The network processing computer 808 can then provide the authorization request message to the authorizing entity computer 810.

[0150] After receiving the authorization request message, the authorizing entity computer 810 can determine whether or not to authorize the interaction. The authorizing entity computer 810 can generate an indication of whether or not the interaction is authorized. The authorizing entity computer 810 can generate an authorization response message in response to the authorization request message. The authorization response message can include the indication of whether or not the interaction is authorized. The authorizing entity computer 810 can then provide the authorization response message to the network processing computer 808.

[0151] In some embodiments, the authorizing entity computer 810 can link the authentication results (e.g., as received in step 632 of FIG. 6 from the authenticating computer 108) to the authorization request message. The authorizing entity computer 810 can determine whether or not to authorize the interaction based the authentication results.

[0152] The network processing computer 808 can provide the authorization response message to the transport computer 806. In some embodiments, the network processing computer 808 may decline the interaction even if the authorizing entity computer 810 has authorized the interaction, for example depending on a security value or other determined value.

[0153] After receiving the authorization response message, the transport computer 806 can provide the authorization response message to the resource provider computer 804.

[0154] After receiving the authorization response message from the transport computer 806, the resource provider computer 804 can provide the authorization response message to the user device 802. For example, the resource provider computer 804 may provide a web page or other indication of the authorization response message to the user device.

[0155] At the end of the day, a normal clearing and settlement process can be conducted by the network processing computer 808. A clearing process is a process of exchanging financial details between an acquirer and an authorizing entity to facilitate posting to a user's payment account and reconciliation of the user's settlement position.

[0156] According to embodiments, a first entity can be a relying party of the relying party computer 106 and a second entity can be an authenticating party of the authenticating computer 108. When the relying party computer 106 wants to perform authentication (e.g., of a user of the user device 802), and when a cryptographic authentication process is associated with the user’s credential (e.g., a passkey exists for the user), the relying party computer 106 can call an API of the authenticating computer 108 along with interaction data and a user device identifier and request authentication of the user. During authentication, the authenticating computer 108 can generate a cryptographic challenge for the user device 802. Depending on which computer the cryptographic authentication process is associated (e.g., the user’s passkey is associated with the relying party computer 106 or the authenticating computer 108), the system can provide the challenge to the user device 802 in a different manner. For example, if the cryptographic authentication process is associated with the relying party computer 106, then the relying party computer 106 can provide the challenge to the user device using a WebAuthn application programming interface. If the cryptographic authentication process is associated with the authenticating computer 108, then the authenticating computer 108 can generate an iframe and can provide the ifirame to the relying party computer 106, where the relying party computer 106 opens the iframe in a webpage accessed by a browser of the user device 802 during the interaction between the user device 802 and the resource provider computer 104, where the challenge is provided to the user device 802 via the iframe. [0157] As an illustrative example, in some embodiments, the second entity can be Visa, and the first entity can be a Payment Wallet (e.g., xPay Wallet). Authentication service provisioned cryptographic keys (e.g., passkeys) can have a relying party domain of “visa.PaymentWallet.com,” with related origins of “auth.visa.com.” Doing so can allow the second entity (e.g., Visa) to use authentication service provisioned cryptographic keys (e.g., passkeys) in the federated model while maintaining attribution to the first entity (e.g., Payment Wallet). The first entity relying party passkeys can have an secure payment confirmation (SPC) flag turned on to support user interface optimizations.

[0158] In some embodiments, the authenticating computer 108 can perform payment passkey eligibility look up. To do so, the relying party computer 106 (e.g., a first entity such as Payment Wallet xPay Wallet) can execute device intelligence (e.g., provided by a second entity such as Visa) and sends an HCE device identify obtain from the user device 802, a credential (e.g., a primary account number), and the device intelligence request identifier to the authenticating computer 108. The authenticating computer 108 can look up in a mapping table to determine whether or not a cryptographic authentication process (e.g., a payment passkey which can be associated with the payment Wallet or with Visa) already exists for the credential. If yes, the authenticating computer 108 can return a message (e.g., a status message) to the relying party computer 106 that payment authentication can be performed with the existing cryptographic authentication process.

[0159] If no cryptographic authentication process exists (e.g., no payment passkey exists) and the HCE token does exist, then the relying party computer 106 can send a request to the authenticating computer 108 to create a challenge (e.g., a cryptographic challenge such as a FIDO challenge) with a signed HCE device certificate for the HCE token. The authenticating computer 108 can respond with a challenge for the relying party computer 106 to use in passkey registration. The relying party computer 106 can prompt the user device 802 to perform local authentication for payment authentication and passkey provisioning. The relying party computer 106 can then create an automatic passkey upgrade with a relying party identifier of ‘visa.PaymentWallet.com’ and ‘Visa’ as the credential identifier. The relying party computer 106 can then send an authentication assertion (e.g., a FIDO authentication assertion), public key, and all required metadata to the authenticating computer 108 to complete passkey registration. The authenticating computer 108 can then send notification of payment passkey registration to an authorizing entity computer 810 (e.g., which can be operated by an account issuer). [0160] If the passkey exists, then the relying party computer 106 can provide an authentication request to the authenticating computer 108 including a merchant name, an amount, and a purchase currency (e.g., for dynamic linking). The authenticating computer 108 can respond with an iframe access code to allow access to an invisible ifirame for authentication. The relying party computer 106 can open the iframe to “auth.visa.com” (in some embodiments, an invisible iframe) in a browser or application of the user device 802. The authenticating computer 108, through a cross-origin iframe, can trigger the WebAuthn get call. The authenticating computer 108, can verify the authentication assertion and can respond with the result to the relying party computer 106.

[0161] Embodiments of the disclosure have a number of advantages. For example, embodiments allow for different entities to provision and manage passkeys while allowing for efficient passkey determination during an interaction.

[0162] Embodiments of the invention allow different entities to authenticate a user can conduct a transaction in a seamless fashion, using cryptographic authentication processes, and leveraging prior user registration processes. In embodiments, a storage application entity such as a digital wallet operator can operate a relying party computer and perform cryptographic authentication processes such as FIDO passkey authentication processes, while another entity such as a processing network can authenticate users using prior registration data and/or other cryptographic processes. When combined, embodiments of the invention also provide greater interaction security as compared to situations where one entity performs all authentication processing. Embodiments of the invention also relieve any one single entity from performing all authentication processing for transactions.

[0163] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0164] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. 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), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0165] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present 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 any of the results mentioned herein to a user.

[0166] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0167] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0168] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:

1. A method comprising:

receiving, by an authenticating computer, a credential and a user device identifier from a relying party computer;

determining, by the authenticating computer, whether or not a token related to the user device identifier exists;

determining, by the authenticating computer, whether or not the credential is associated with a cryptographic authentication process;

providing, by the authenticating computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer;

based on the status message, receiving, by the authenticating computer, a challenge request message from the relying party computer;

generating, by the authenticating computer, a challenge;

providing, by the authenticating computer, the challenge to a user device, wherein the user device performs an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer;

verifying, by the authenticating computer, the authentication assertion; and providing, by the authenticating computer, authentication results based on the verification to an authorizing entity computer.

2. The method of claim 1, wherein the challenge is provided to the user device via the relying party computer.

3. The method of claim 1, wherein the authentication assertion is a FIDO authentication assertion.

4. The method of claim 1, wherein the status message indicates that the credential is associated with the cryptographic authentication process and is associated with the authenticating computer.

5. The method of claim 4, further comprising:

after receiving the challenge request message, generating, by the authenticating computer, an iframe; and providing, by the authenticating computer, the iframe to the relying party computer, wherein the relying party computer opens the iframe in a webpage accessed by a browser of the user device during an interaction between the user device and a resource provider computer, wherein the challenge is provided to the user device via the iframe.

6. The method of claim 1, wherein the status message indicates that the credential is associated with the cryptographic authentication process and is associated with the relying party computer.

7. The method of claim 6, wherein providing the challenge to the user device comprises:

providing, by the authenticating computer, the challenge to the relying party computer, wherein the relying party computer provides the challenge to the user device using a WebAuthn application programming interface.

8. The method of claim 1, wherein determining whether or not the token related to the user device identifier exists comprises:

obtaining, by the authenticating computer, a token to credential mapping table; and

searching, by the authenticating computer, the token to credential mapping table for the token and the user device identifier using the credential.

9. The method of claim 1, wherein determining whether or not the credential is associated with the cryptographic authentication process comprises:

obtaining, by the authenticating computer, a credential to cryptographic authentication process mapping table; and

searching, by the authenticating computer, the credential to cryptographic authentication process mapping table for the cryptographic authentication process using the credential.

10. The method of claim 1, wherein the challenge includes a nonce.

11. The method of claim 1, wherein the user device generates a signature during an authentication process with a user of the user device using a cryptographic key stored in the user device, wherein the signature is included in the authentication assertion.

12. The method of claim 11, further comprising:

validating, by the authenticating computer, the signature using a cryptographic key stored in the authenticating computer.

13. The method of claim 12, wherein the user device identifier is a host card emulation device identifier, and wherein the token is a host card emulation token.

14. An authenticating computer comprising:

a processor; and

a non-transitory computer readable medium comprising code, executable by the processor for performing a method comprising:

receiving a credential and a user device identifier from a relying party computer;

determining whether or not a token related to the user device identifier exists;

determining whether or not the credential is associated with a cryptographic authentication process;

providing a status message indicating whether or not the credential is associated with the cryptographic authentication process to the relying party computer;

based on the status message, receiving a challenge request message from the relying party computer;

generating a challenge;

providing the challenge to a user device via the relying party computer or to the user device, wherein the user device performs an authentication process in response to the challenge and provides an authentication assertion to the authenticating computer directly or via the relying party computer;

verifying the authentication assertion; and

providing authentication results based on the verification to an authorizing entity computer.

15. The authenticating computer of claim 14, wherein the authentication results include the authentication assertion or an indication of whether or not a user of the user device was authenticated, wherein the authorizing entity computer stores the authentication results.

16. The authenticating computer of claim 14, wherein the challenge is a cryptographic challenge, and wherein the authentication assertion includes a signature that is formed by the user device signing the cryptographic challenge with a cryptographic key.

17. The authenticating computer of claim 14, wherein the challenge includes a nonce.

18. A method compri sing :

providing, by a relying party computer, a credential and a user device identifier of a user device to an authenticating computer, wherein the authenticating computer determines whether or not a token related to the user device identifier exists and determines whether or not the credential is associated with a cryptographic authentication process;

receiving, by the relying party computer, a status message indicating whether or not the credential is associated with the cryptographic authentication process from the authenticating computer;

based on the status message, generating, by the relying party computer, a challenge request message;

providing, by the relying party computer, the challenge request message to the authenticating computer, wherein the authenticating computer generates a challenge;

receiving, by the relying party computer, the challenge from the authenticating computer; and

providing, by the relying party computer, the challenge to the user device, wherein the user device performs an authentication process in response to the challenge and generates an authentication assertion for authentication verification by the authenticating computer.

19. The method of claim 18, further comprising:

receiving, by the relying party computer, interaction data from a resource provider computer, wherein the interaction data comprises the credential; and

receiving, by the relying party computer, the user device identifier from the user device.

20. The method of claim 18, further comprising:

receiving, by the relying party computer, the authentication assertion from the user device; and providing, by the relying party computer, the authentication assertion to the authenticating computer for authentication verification.