WO2026030384A1 - Method and system for secure cryptographic authentication - Google Patents

Abstract

Embodiments are directed to methods and systems for authenticating users of user devices using passkeys, particularly during interactions with resource providers (e.g., computer systems that provide online resources), thus enabling convenient and secure authentication of users. During an interaction, device data from a user device can be provided to a passkey server. The passkey server can determine a device identifier corresponding to the user device using device fingerprinting. The passkey server can identify that the user device is capable of performing authentication using a digital signature and additionally identify a public key corresponding to the user device. The passkey server can transmit a challenge message to the user device, which can sign the challenge message using its private key and transmit the resulting digital signature back to the passkey server. The passkey server can verify the digital signature using the public key in order to authenticate the user device.

Description

METHOD AND SYSTEM FOR SECURE CRYPTOGRAPHIC AUTHENTICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application, which claims priority to U.S. Provisional Application No. 63/677,033, filed on July 30, 2024, which is herein incorporated by reference in its entirety.

BACKGROUND

[0002] Various processes, activities, or other interactions involve the authentication of entities or devices, e.g., involving determining whether an entity or device is who or what they proport to be. For example, in order to access their emails on a web-based email hosting service, a user might provide a username and password. Under the assumption that the password is only known to the authentic user, presentation of a correct username and password is sufficient to authenticate the user. A computer system associated with the email hosting service can verify that the password is correct (e.g., based on the provided username), thereby authenticating the user, and then allow the user to access their emails.

[0003] Many authentication methods can be generally categorized based on the concepts of “something they know”, “something they have”, and “something they are”. In other words, a user can be authenticated based on some knowledge, e.g., a password, that is known to the user but presumably not known to users at large (“something they know”), an object, such as a smartphone, that is known to be possessed by the user (“something they have”), or some generally immutable property of the user, e.g., a biometric, such as a fingerprint, that is largely unique to the user (“something they are”). Demonstrating such knowledge, possession, or characteristic may be sufficient for a user to generally verify their identity.

[0004] “Multi-factor authentication” (MFA) has seen increasing use in authentication processes due to its security benefits. Rather than authenticating based on a single factor, such as a password, a user can be authenticated using multiple factors. For example, after a user inputs a password into a login form, a server computer may automatically transmit a text message to a phone number associated with the user. The text message may contain a one-time password (OTP) that the user may be instructed to provide to the login form. If the user is able to provide the OTP, it demonstrates that the user both knows the password and is possession of the phone (satisfying “something they have”). Under the assumption that it is more difficult for a hacker or other malicious user to both steal a phone and a password (rather than steal either one individually), such an MFA process is more secure than a similar single-factor authentication process. In some cases, authentication using MFA is either strongly recommended or required, e.g., for sensitive information or in particular jurisdictions.

[0005] Unfortunately, there are some difficulties with implementing secure multi-factor authentication, particularly for certain devices or “device ecosystems”. For example, a device manufacturer may require that a user has a single account across all their devices, e.g., the user has a single account that they can use to access their smartphone or their tablet, and can e.g., check messages sent to their smartphone using their tablet. While this may be convenient to the user, it may “violate” some of the principles of MFA described above. For example, if after authenticating through a first factor (e.g., via “something they know”, such as a password), an OTP is sent to a user’s smartphone, but the user instead reads the OTP off their tablet, then the user providing that OTP does not demonstrate that the user is in possession of their smartphone. One could argue that this is not truly two- factor authentication or is instead a weaker form of two-factor authentication.

[0006] This weaker form of authentication can lead to various security concerns. For example, a user’s live-in partner could use a “shared” tablet (but tied to an account of the user) in order to access the user’s private emails, medical records, etc., e.g., by authenticating as the user using an OTP sent to the user’s smartphone but shared via a synced account. As another example, a user’s child could use a shared tablet in order to make unauthorized purchases in an application store, e.g., by authenticating as the user using an OTP sent to the user’s smartphone but shared via a synced account. [0007] Further, the variety and number of authentication systems that users now regularly interact with can create a frustrating user experience. Recent studies suggest that average Internet users have to remember over 100 passwords for the various services they use online. Additionally, many websites or other services may have multiple authentication options, e.g., authenticating using the website’s “inhouse” authentication service (e.g., a registered user account), or via an “outsourced” authentication service (e.g., via an account registered on a social media website, with a large email provider, etc.), meaning that even if a user does remember or possess relevant authentication credentials, they also need to remember the mechanism by which they are authenticated, creating further difficulty for users.

[0008] Embodiments address these and other problems, individually and collectively.

SUMMARY

[0009] This Summary is provided to introduce a selection of concepts in a simplified form that are further described herein in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0010] Embodiments of the present disclosure are directed to various methods and systems for performing authentication using cryptography, particularly for the authentication of users of user devices (e.g., users of smartphones, laptop computers, desktop computers, other personal electronic devices, etc.). Embodiments of the present disclosure can enable highly accurate and secure authentication of users in a manner that is friction-free, requires little action on the part of users, and can be achieved using authentication factors that are already familiar to users.

[0011] Some embodiments involve establishing “one-to-one” device bindings between user devices and passkeys (including, e.g., Fast Identity Online or “FIDO” passkeys). Unlike authentication using synchronized passkeys, in embodiments, a user device can only use a passkey to perform authentication provided there is an established binding between that passkey and device information that can be used to identify that device (e.g., as established or recorded by a “passkey server”, described in more detail below). Thus, authentication via methods according to embodiments demonstrates that the user is in possession of “something they have”, as the passkey cannot be used if they are not in possession of the device to which the passkey is bound. Further, provided that the passkey can only be accessed or used provided that the user provides some other form of authentication (e.g., either by inputting a password or providing a biometric sample such as a fingerprint scan), methods according to embodiments naturally provide a convenient form of two-factor authentication.

[0012] Further, embodiments of the present disclosure can be used in networks and systems which involve multiple parties and computer systems, which may have more complex authentication processes or requirements. As a general example, a user (operating a user device) may be authenticated as part of an interaction with a resource provider (operating a resource provider computer), e.g., prior to that resource provider providing access to a resource to the user or user device. However, the resource provider may rely on another party or computer system (e.g., a processing network operating a passkey server, as described in more detail further below) to authenticate the user, rather than performing authentication itself. Moreover, any number of additional parties (e.g., an authorizing entity operating an authorizing entity computer) may want proof or some attestation that the user was authenticated, e.g., in order to authorize the interaction between the user and the resource provider. Methods according to embodiments can be used to securely authenticate users in a friction-free manner, while also informing any other relevant entities or computer systems (e.g., resource provider computers, authorizing entity computers, etc.) that those users have been authenticated.

[0013] Such networks and systems may involve large numbers of resource providers, authorizing entities, etc., highlighting a technical advantage of embodiments of the present disclosure. A passkey server according to embodiments can identify and recognize user devices across many interactions with different resource providers, thus enabling a user to register a passkey once, then use it with any resource provider. This reduces the need for users to perform tedious authentications or authentication enrollment steps with individual resource providers or authorizing entities. For example, after interacting with one resource provider (e.g., a video streaming service that the user must authenticate with in order to watched streamed videos), a user device could generate a passkey as part of a registration process, which the user could subsequently use to interact with another resource provider (e.g., an email service provider that the user must authenticate with in order to access their email address). In this way, methods according to embodiments can greatly simplify authentication processes for users, while still providing a strong form of multi-factor authentication.

[0014] In more detail, one embodiment is directed to a method performed by a server computer. The server computer can receive an initialization request message from a user device interacting with a resource provider computer to conduct an interaction. The initialization request message can comprise device data associated with the user device. The server computer can determine a device identifier based on the device data. The server computer can additionally determine a session identifier and determine that the user device is capable of performing an authentication process using a digital signature. The server computer can transmit the session identifier (e.g., to the resource provider computer or the user device). The server computer can receive the session identifier and interaction data associated with the interaction. The interaction data can comprise a credential. The server computer can identify a database record from a database. The database record can indicate that the credential is associated with the device identifier and a public key of a public-private key pair. The server computer can transmit a challenge message to the user device. The user device can sign the challenge message using a private key of a public-private key pair to produce the digital signature. The server computer can receive the digital signature. The server computer can validate the digital signature using the public key of the public-private key pair. The server computer can provide a message indicating that the user device is authenticated.

[0015] Another embodiment is directed to a method performed by a user device interacting with a resource provider website operated by a resource provider computer to conduct an interaction. The user device can transmit an initialization request message comprising device data associated with the user device to a server computer. The server computer can determine a device identifier based on the device data, determine a session identifier, and can determine that the user device is capable of performing an authentication process using a digital signature. The user device can receive the session identifier. The user device can transmit the session identifier and interaction data associated with the interaction to the server computer. The interaction data can comprise a credential. The server computer can identify a database record in a database, which can indicate that the credential is associated with the device identifier and a public key of a public-private key pair. The user device can receive a challenge message from the server computer. The user device can sign the challenge message using a private key of the public-private key pair, thereby producing a digital signature. The user device can transmit the digital signature to the server computer. The server computer can validate the digital signature using the public key of the public-private key pair and provide a message indicating that the user device is authenticated.

[0016] In addition to the methods described above (and other methods), some embodiments are directed to computer systems or other devices that can be configured to perform the methods described above or other methods. For example, one embodiment is directed to a computer system (e.g., a server computer or a user device) comprising a processor and a non-transitory computer-readable medium coupled to the processor. The non-transitory computer-readable medium can comprise code executable by the processor for performing the methods described above (or other methods described in the detailed description below).

[0017] A better understanding of the nature and advantages of embodiments of the present disclosure may be gained with reference to the following detailed description and the accompanying drawings. Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present disclosure. Further features and advantages of the present disclosure, as well as the structure and operation of various embodiments of the present disclosure, are described in detail below with respect to the accompanying drawings. In the drawings, like reference numbers can indicate identical or functionally similar elements.

TERMS

[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 smartphone, 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 “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers include merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc.

[0022] A “merchant” may typically be an entity that engages in transactions and can sell goods and services or otherwise provide access to goods or services.

[0023] A “transporter” or "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 issuer-acquirers. A transporter may operate a “transport computer” (also referred to as an “acquirer computer”). [0024] 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.

[0025] 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, smartcard, tablet, or laptop to the consumer.

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

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

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

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

[0030] 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 CW (card verification value), a dCW (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.

[0031] 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., PCS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG. 1 shows a four-party network in which an interaction between a resource provider and a user can be authorized and performed. [0034] FIG. 2 shows a diagram of credentials and their association with user identity data, authentication devices, and passkeys.

[0035] FIG. 3 shows a sequence diagram of a process for performing an interaction and enrolling a user in a passkey-based authentication system according to embodiments.

[0036] FIGs. 4A-4G show several exemplary user device views that a user could see when performing an interaction and enrolling in a passkey-based authentication system according to embodiments.

[0037] FIG. 5 shows a sequence diagram of a process for authenticating a user during an interaction using a passkey-based authentication system according to embodiments.

[0038] FIGs. 6A-6D shows several exemplary user device views that a user could see when performing an interaction and authenticating using a passkey-based authentication system according to embodiments.

[0039] FIG. 7 shows a system block diagram of a user device according to some embodiments.

[0040] FIG. 8 shows a system block diagram of a passkey server according to some embodiments.

DETAILED DESCRIPTION

[0041] Embodiments of the present disclosure are directed to various methods and systems for authenticating users of user devices using passkeys (including FIDO passkeys or other similar passkeys) securely stored on those user devices. These can include methods and systems for registering or otherwise enrolling users in such authentication systems, e.g., enabling those users to authenticate using passkeys instead of (or in addition to) other authentication methods. Such passkeys can be “device bound”, e.g., a passkey can only be used for authentication if there is an established binding between that passkey and a corresponding user device, e.g., as recorded by a passkey server. This is advantageous because it provides additional security, as the use of such passkeys demonstrates that the user is in possession of a user device, thus providing one factor of multi-factor authentication. [0042] Embodiments of the present disclosure can be used in contexts that involve interactions between resource providers and users of user devices, e.g., interactions in which a user may be provided access to a resource (e.g., a video stream from a streaming service resource provider) provided that they are successfully authenticated (and in some cases also authorized). As discussed above in the Summary, one advantage of the embodiments is that such passkeys can be used by users to securely authenticate with various resource providers without requiring specific registration with those resource providers. Thus, a user could, e.g., use the same passkey to access a streaming service provided by one resource provider and an online banking account associated with another resource provider, thus providing a much more convenient and “frictionless” user experience.

[0043] Such users and resource providers can exist in four-party networks, networks in which interactions between e.g., four parties (and any number of applicable computing systems) are mediated (at least in part) by a processing network. Thus, in order to better orient the reader, an exemplary four-party network 100 is described below with reference to FIG. 1 is illustrative and not limiting.

[0044] The exemplary four-party network 100 can comprise a resource provider 102, a user 104, a transporter 106 (also referred to as an “acquirer”) and an authorizing entity 108 (also referred to as an “issuer”). In general, a four-party network can be used to authorize interactions between resource providers (such as resource provider 102) and users (such as user 104). Such an interaction could comprise, e.g., user 104 attempting to access a video streaming service or an email hosting service provided by resource provider 102, or e.g., a transaction between a merchant resource provider 102 and a customer user 104.

[0045] Further, the four-party network 100 can be organized into “domains”, generally containing various computer systems or devices “operated by” or “relevant to” corresponding entities, which can be used by those entities in order to perform various operations associated with the four-party network 100, e.g., authenticating users in order to perform interactions between users and resource providers. For example, interoperability domain 116 (also referred to as a “processing network domain”) can include processing network 110 (and any number of applicable processing network servers) as well as, e.g., a directory server and any number of other applicable computer systems that enable the processing network 110 to perform its functions (as described in more detail further below). As another example, the authorizing entity domain 114 can include an authorizing entity computer, e.g., a computer system associated with authorizing entity 108 that performs function associated with authorizing interactions between resource providers and users, as well as e.g., an access control server that verifies the identities of users and performs risk assessment in the context of interactions between resource providers and users. As yet another example, the resource provider domain 112 can include a resource provider computer (associated with the resource provider) that can provide resources to user 104, e.g., a server computer associated with a video streaming service that can stream video to a user device operated by user 104, as well as various other applicable computer systems, such as an “authentication server computer”, which can perform various steps associated with authenticating users. In some cases, the user 104 and any applicable user device can be considered part of the resource provider domain.

[0046] Some interactions (e.g., transactions) between resource providers and users may be “authorized” prior to the interaction taking place. In some cases, an interaction may be authorized based (in part) on a credential (e.g., a payment account number or “PAN”) issued to the user 104 by authorizing entity 108 (e.g., an issuing bank). As an example, a payment transaction may be authorized provided that the user 104 has a valid credential corresponding to a payment account with enough funds (or a sufficient line of credit) to pay for any resources provided by the resource provider 102 to the user 104 as part of the transaction.

[0047] To this end, during an interaction, the user 104 can show or otherwise provide their credential to the resource provider 102 during an interaction. However, ultimately the authorizing entity 108 (having issued the credential to the user 104) will authorize the interaction. The resource provider 102 may have an established relationship with transporter 106 (e.g., as transporter 106 may comprise an acquiring bank that maintains a payment account on behalf of resource provider 102). Moreover, authorizing entity 108 may be one of a large number of authorizing entities (e.g., an issuing bank of a large number of issuing banks). [0048] The processing network 110 can provide various services related to interactions, including services related to routing authorization request messages (e.g., requesting authorizations for interactions corresponding to provided credentials) and authorization response messages (e.g., indicating whether such interactions are authorized or are not authorized). Rather than attempting to directly contact authorizing entity 108 and request authorization themself, the resource provider 102 can generate an authorization request message and transmit it to transporter 106, e.g., via an access terminal (e.g., a point-of-sale terminal) to a transporter computer. Transporter 106 can then transmit the authorization request message to processing network 110, which can identify authorizing entity 108 and route the authorization request message to authorizing entity 108.

[0049] Authorizing entity 108 can then perform any applicable analysis in order to determine whether to authorize the interaction or not (e.g., via an authorizing entity computer). Authorizing entity 108 can generate an authorization response message, indicating whether the interaction has been authorized or not. Authorizing entity 108 can transmit the authorization response message back to processing network 110, which can then route the authorization response message to transporter 106. Transporter 106 can then transmit the authorization response message to resource provider 102, which can then complete or terminate the interaction based on the authorization response message, e.g., completing the interaction if the authorization response message indicates the interaction is “approved” and terminating the interaction if the authorization is “declined”.

[0050] One related aspect of authorization is “authentication”, which can involve authenticating the user 104 prior to authorizing the interaction. Conceivably, a thief could steal the user’s 104 credential, then pose as the user 104 and attempt to perform an interaction with resource provider 102, e.g., attempt to purchase goods or services using the user’s 104 money or credit. For this reason, it is generally prudent to authenticate user 104 prior to, or as part of, the authorization process. Methods and systems according to embodiments, as described in more detail below, can be used to authenticate users in four-party networks (or other situation), thus enabling users and resources providers to securely and safely perform interactions. FIG. 2 generally depicts exemplary associations between user identity data, credentials, authentication devices, and passkeys, which may be helpful for understanding authentication methods and systems according to embodiments.

[0051] As described above, authorizing an interaction between a resource provider and a user may involve the use of a credential, e.g., an interaction may be approved by an authorizing entity computer if a valid credential has been presented (in addition to any number of additional considerations, e.g., if the user is successfully authenticated) and denied if a valid credential has not been presented. FIG. 2 shows a first credential 214 and a second credential 216. A credential may be considered a sensitive form of data, depending in part on the types of interactions (e.g., access to sensitive medical records, transactions, etc.) that the credential can be used to authorize. As such, credentials that are stolen or leaked may need to be reissued. However, in some cases it can be a hassle to reissue credentials, both for users associated with those credentials and authorizing entities that issue those credentials. For example, a PAN may be associated with a physical payment card, and reissuing a PAN (e.g., if the original PAN was stolen) may involve manufacturing and shipping a new credit card to a user.

[0052] To this end (and for other various reasons), in some cases tokenized credentials can be used in place of their underlying credentials, particularly in interactions in which an underlying physical object (e.g., a physical payment card) is not provided (e.g., a “card-not-present” interaction). FIG. 2 shows first tokenized credential 218, second tokenized credential 220, third tokenized credential 222, and fourth tokenized credential 224. A tokenized credential can be defined or generated based on its underlying credential, e.g., a tokenized credential could comprise a pseudorandom number generated using the underlying credential as a “seed value”, such that the underlying credential cannot be determined based on analysis of the tokenized credential. The tokenized credential could be used to authorize interactions in place of the underlying credential. The advantage of using tokenized credentials is that if a tokenized credential is stolen or leaked, it can quickly be deactivated and a new tokenized credential can quickly be generated from the underlying credential, e.g., by generating a new pseudorandom number. Because the underlying credential cannot be determined from inspection of the tokenized credential, the underlying credential remains secure, and a new underlying credential (and e.g., a physical object such as a payment card) does not need to be issued to a user.

[0053] Regardless, in some embodiments of the present disclosure various user identity data 202 can be associated with credentials or corresponding tokenized credentials. Such user identity data 202 can be used to identify users (or associated user devices) corresponding to credentials, e.g., by a passkey server, e.g., for the purpose of determining whether a user device is registered to perform passkeybased authentication, as described in more detail further below with reference to FIGs. 3 and 5. FIG. 2 shows various examples of user identity data 202, including a user’s name 204, address 206, phone number 208, email address 210, embedded identity document (EID) number 212 (e.g., associated with an eSIM of a smartphone user device owned by a user), or various other user identity data 202.

[0054] First credential 214 and second credential 216 (or any applicable corresponding tokenized credentials) can be associated with various authentication devices, which can comprise user devices that can be used in order to authenticate users in some methods according to embodiments. FIG. 2 shows a first user device 226, a second user device 228, a third user device 230, a fourth user device 232, and a fifth user device 234. In FIG. 2, the first credential 214 can be associated with the first user device 226, the second user device 228, and the third user device 230. The second credential 216 can be associated with the third user device 230, the fourth user device 232, and the fifth user device 234. In some cases, such credentials can be stored in their corresponding user device in any applicable manner, e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc.

[0055] During an interaction with a resource provider, a user could use a corresponding user device to provide a credential to a resource provider computer in order to be authorized to perform the interaction. For example, a user could use a web browser on their user device to navigate to a website hosted by the resource provider computer and provide their credential to that resource provider via a web form (see e.g., FIG. 4A, view 402, in which a credential 430 is provided to a resource provider via a field on a web form). The credential could be forwarded to an authorizing entity computer in an authorization request message via a transporter computer and a processing network, e.g., as discussed above with reference to FIG. 1 . The authorizing entity computer could generate an authorization response message (e.g., approving or declining the interaction) and transmit the authorization response message back to the resource provider computer. However, in order to authorize the interaction and complete it, the user may first need to be authenticated, e.g., using authentication methods and systems according to embodiments.

[0056] As such, in some embodiments, “passkeys” (e.g., FIDO passkeys or similar passkeys) can be used to authenticate users of user devices. FIG. 2 shows a first passkey 236, a second passkey 238, a third passkey 240, and a fourth passkey 242, which can be associated with various user devices 226-234. Unlike other credentials, passkeys can be used to perform authentication without needing to be shared or transmitted. As such, passkeys are resistant to fishing, brute force attacks, man-in-the-middle attacks, and various other methods used to commit identity theft and fraud.

[0057] In general terms, in passkey-based authentication methods according to embodiments, authentication can be performed using public-private key pairs. A passkey can generally comprise or relate to these public and private keys. An authentication device (e.g., a user device) can securely store a private key, e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc. The public key can be stored at a passkey server. In order to authenticate a user, the passkey server can transmit a “challenge message” (also referred to as an “assertion challenge”) to a user device possessed by the user. The user device can then sign the challenge message using the private key and send the resulting digital signature back to the passkey server. The passkey server can verify the digital signature using the public key, thereby authenticating the user. A registration process can generally involve the generation of such a public-private key pair, secure storage of the private key on a user device, transmission of the public key to the passkey server, etc.

[0058] More specifically, during the course of an interaction with a resource provider, the user could use their user device (e.g., first user device 226) to provide a credential (e.g., first credential 214) to a resource provider computer. This process can trigger further authentication of the user via passkeys. A passkey server can then transmit a challenge message to the user device, which the user device can then sign using the private key corresponding to the user’s passkey (e.g., first passkey 236). The user device can then return the resulting digital signature to the passkey server, which can then verify the digital signature using the corresponding public key. The passkey server can then forward the digital signature and any other relevant information (e.g., interaction details (e.g., an amount spent, a merchant identifier, a timestamp, etc.), an assertion that the passkey server verified the digital signature, etc.) to an authorizing entity computer, which can then authorize the interaction (or not) based on the passkey-based authentication of the user. In some embodiments, the user device may only sign the challenge message if the user “unlocks” the passkey by providing a biometric (e.g., a fingerprint or thumbprint scan, facial identification, an iris scan, etc.) or by providing a personal identification number (PIN) or password, thus providing a form of two-factor authentication.

[0059] As described above, “synchronized devices”, e.g., different devices that may correspond to the same manufacturer and share the same account (e.g., a smartphone and tablet manufactured by the same device manufacturer and owned by the same user) may weaken some forms of multi-factor authentication, including passkey-based authentication. For example, FIG. 2 shows a scenario in which fourth passkey 242 is shared between third user device 230, fourth user device 232, and fifth user device 234. In such a case, using fourth passkey during authentication does not necessarily verify that the user is in possession of a specific user device (e.g., third user device 230), as such a passkey could instead be used by fourth user device 232 or fifth user device 234.

[0060] To address this, methods and systems according to embodiments can provide for a form of “device-binding” between passkeys and user devices, such that a passkey can only be used to authenticate a user when it is used in conjunction with its corresponding user device during authentication. As such, passkey-based authentication methods according to embodiments guarantee that a user is in possession of their corresponding user device during authentication, thus providing a stronger form of multi-factor authentication security, particularly if biometric scans performed on user devices are required to “unlock” passkeys for passkey-based authentication. [0061] In general terms, a passkey server according to embodiments can record a binding between credentials, corresponding passkeys, and various user identity data 202, particularly device-related data (such as Embedded Identity Document numbers, International Mobile Equipment Identity Numbers, etc.). Using such a binding, during an authentication process, the passkey server can use the device-related data to identify the user device and determine whether the user device has an associated and uniquely-bound passkey. If the user device has an associated passkey, the passkey server can generate a challenge message and send it to the user device as part of the authentication process. If the user device does not have an associated passkey, the user can be authenticated through other means (e.g., the use of “3-D Secure”, as described in more detail with reference to FIG. 3) and the user can later be offered an opportunity to enroll in passkey-based authentication, e.g., via an enrollment message sent to the user device and displayed to the user.

[0062] Moreover, a passkey-based authentication registration process according to embodiments can be integrated into existing interaction processing and authentication methods, creating a convenient and user-friendly experience. For example, after being authenticated with an email service provider by providing login details, a user could be prompted to register with a passkey-based registration service according to embodiments. For subsequent login attempts, rather than having to input their login details, the user’s passkey could be used to authenticate the user. As another example, after being authenticated (e.g., using a 3-D Secure authentication process) as part of performing an online transaction with an e- commerce merchant, a user could be prompted to create a passkey that is associated with a user device and a payment credential (e.g., a payment account number or PAN). For subsequent transactions, the user could be authenticated using their passkey rather than through other authentication processes.

[0063] FIG. 3 shows a sequence diagram corresponding to an interaction between a user 350 and a resource provider. In the interaction, the user 350 has not yet registered with a passkey-based authentication system according to embodiments. After the user 350 is authenticated via an alternative authentication process, such as 3D Secure (step S312), the user 350 can enroll in passkey-based authentication (steps S316-S328). Afterwards, the user 350 can then use their passkey to authenticate with the same resource provider or other resource providers in subsequent authentications, e.g., as described in more detail below with reference to FIG. 5.

[0064] The computers, devices, and entities in FIG. 3 can generally be divided into a resource provider domain 368 (including user 350, user device 352, resource provider computer 354, and authentication server computer 356 (e.g., a 3-D Secure authentication server)), interoperability domain 370 (including directory server 358, passkey server 360, and processing network 362), and authorizing entity domain 372 (including access control server 364 and authorizing entity computer 366).

[0065] Generally, as described above with reference to FIG. 1 , an authorizing entity (operating authorizing entity computer 366) may have issued a credential (e.g., a PAN) to user 350. Such a credential may be used in order to authorize an interaction (e.g., a transaction) between the user 350 and a resource provider (e.g., a merchant), e.g., an interaction carried out via user device 352 and resource provider computer 354. Such an interaction could comprise an ecommerce transaction carried out by the user 350 by accessing a resource provider website (associated with the resource provider computer 354) via user device 352.

[0066] In order to authorize an interaction between user 350 and a resource provider operating resource provider computer 354, an authorization request message may be generated (e.g., by resource provider computer 354, which may contain interaction details (e.g., a transaction amount, an identifier associated with the resource provider, a timestamp, the credential used as part of the interaction, etc.). Such an authorization request message may be transmitted to the authorizing entity computer 366 via processing network 362 (e.g., a processing network such as VisaNet). The authorizing entity computer 366 can approve or decline the interaction based on the authorization request message, generate an authorization response message to that effect, and e.g., transmit the authorization response message back to the resource provider computer 354 (e.g., via processing network 362). The resource provider computer 354 can then complete or terminate the interaction based on the authorization response message and e.g., display a status message to the user 350 via a display on user device 352. [0067] In more detail, at step S302, a user 350 operating a user device 352 can conduct an interaction with a resource provider via resource provider computer 354. User device 352 may be interacting with a resource provider website (e.g., a “first resource provider website”) operated by resource provider computer 354 in order to conduct the interaction. “Conducting” an interaction can take various forms depending on the nature of the resource provider and any resources provided by that resource provider. For example, user 350 could conduct an interaction by providing a credential (e.g., a password) to a web form associated with an email hosting service and clicking or otherwise selecting a “login” button. As another example, a user could conduct an interaction (transaction) with a merchant resource provider by inputting a credential (e.g., a PAN) into a web form and clicking or otherwise selecting a “checkout” button, thereby signaling their intent to pay for any goods or services in their virtual cart. FIG. 4A shows a view 402 of a smartphone user device displaying a resource provider website (e.g., hosted by resource provider computer 354) corresponding to a resource provider URL 428 via a browser application. As part of the interaction, the user has provided a credential 430 (e.g., a credit card number) into an associated field in the resource provider website. The user can signal their intent to make a purchase using the provided credential by selecting a checkout button 438.

[0068] Referring back to FIG. 3, at step S304, an initialization request message (e.g., a first initialization request message) can be transmitted to passkey server 360 (sometimes more generically referred to as a “server computer”). The passkey server 360 can receive the initialization request message from the user device 352, e.g., via resource provider computer 354 and/or authentication server computer 356 or from the resource provider computer 354 itself. The initialization request message can comprise device data associated with the user device 352. In some embodiments, an HTML “iframe” embedded in the resource provider website can be used to transmit the device data from the user device 352 to the passkey server 360, e.g., via a user device SDK (e.g., accessible by a browser application) that enables device data to be read from the user device 352.

[0069] The device data can include any suitable data that can be used to identify the user device 352, e.g., via “device fingerprinting” processes. For example, the device data can include a numerical or alphanumerical code that can be used to identify the user device 352 (e.g., a phone number, an international mobile equipment identity (IMEI) number, an embedded identity document (EID) number, etc.). The device data can also include, as examples, an IP address, geolocation data, a browser type or browser version number, processor data (e.g., identifying a processor or microprocessor type or model number), a model number, a manufacturer name, an operating system identifier, device component data (e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.), etc.

[0070] The passkey server 360 can determine a device identifier based on the device data. The device identifier can uniquely identify the user device 352 based on its associated device data. There are various ways that the passkey server 360 can determine a device identifier based on the device data. For example, the passkey server 360 could rely on an external authentication provider or device intelligence provider, which could generate the device identifier based on the provided device data and return the device identifier to the passkey server 360. As another alternative, the passkey server 360 could hash the device data (or some subset of the device data), thereby generating a device hash. Provided that the device data provided by a given user device is consistent, the device hash is consistent, and thus the device hash can be used to identify the user device 352. As such, in some embodiments the device identifier can comprise the device hash.

[0071] As described in more detail in subsequent steps, the device identifier can be used by the passkey server 360 to look up a database record corresponding to user device 352. Such a database record can indicate whether user device 352 is enrolled in a passkey-based authentication system according to embodiments, e.g., if a passkey (or a component of a passkey, e.g., a related public key) is recorded in the database record and is associated with the user device 352 and any applicable credential (e.g., the credential provided at step S302, e.g., a PAN).

[0072] Additionally at step S304, the passkey server 360 can also determine a session identifier (e.g, a “first session identifier”). The session identifier can generally identify the interaction between the user 350 and the resource provider, or e.g., a “session” associated with the interaction, e.g., a particular “authentication session” taking place in order to authenticate the user 350. Such a session identifier can be determined in any appropriate manner, e.g., a session identifier could comprise the next sequential number in a sequence of numbers used as session identifiers.

[0073] Further, the passkey server 360 can determine that the user device 352 is capable of performing an authentication process using a digital signature, e.g., is capable of performing passkey-based authentication methods according to embodiments. The passkey server 360 can make this determination based on the received device data. For example, in some embodiments, in which the user 350 and user device 352 are authenticated via FIDO passkeys, the passkey server 360 can determine that the user device is capable of performing the authentication process using the digital signature by determining that the user device is FIDO compatible. The passkey server 360 could determine, based on the device data, whether the user device 352 has any appropriate APIs for performing authentication using a digital signature, e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.), and whether the user device can support any appropriate authentication protocols (e.g., the client to authenticator protocol CTAP1 or CTAP2).

[0074] The passkey server 360 can also determine whether the user device 352 has any form of secure memory that can be used to securely store a private key for authentication (e.g., a private key that can be used to generate the digital signature), such as a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), a “vault”, “keychain”, etc. The passkey server 360 can further determine whether the user device 352 possesses any hardware or components that may be used for user authentication, e.g., a biometric interface (such as a fingerprint scanner or a camera for performing an iris scan or facial recognition) as part of determining whether the user device 352 is capable of performing an authentication process using a digital signature.

[0075] At step S306, the passkey server 360 can transmit the session identifier to the resource provider computer 354. Alternatively or additionally, the passkey server 360 can transmit the session identifier to user device 352. The passkey server 360 can additionally transmit a flag indicating that the user device 352 is capable of performing an authentication process using a digital signature, e.g., that the user device 352 is capable of performing a FIDO authentication process. In some embodiments, the passkey server 360 can transmit the session identifier and the flag via the authentication server computer 356 (which can comprise a 3-D Secure server).

[0076] At step S308, the passkey server 360 can receive the session identifier (e.g., a “first session identifier”) and interaction data associated with the interaction (also referred to as a “first interaction”). The interaction data can comprise a credential (e.g., a PAN), as well as various other data, such as a resource provider identifier (e.g., a merchant identifier), an interaction amount (e.g., a transaction amount), a currency, a transaction UUID (unique universal identifier), etc. The passkey server 360 can receive the session identifier and the interaction data from the resource provider computer 354, e.g., via authentication server computer 356. Alternatively, the passkey server 360 can receive the session identifier and interaction data from the user device 352 instead of the resource provider computer 354.

[0077] At step S310, the passkey server 360 can determine that the credential is not associated with the device identifier, e.g., that there is no database record corresponding to the credential and the device identifier. The passkey server 360 can further determine that the credential is not associated with a public key of a public-private key pair, i.e. , a public key corresponding to a passkey (e.g., a FIDO passkey). In this way, the passkey server 360 can determine that the user device 352 is not enrolled into a passkey-based authentication system according to embodiments. Optionally at step S310, the passkey server 360 can store the device data in association with the device identifier in a database record, e.g., for later use during enrollment.

[0078] Steps S304-S310 generally do not require any input on behalf of the user. As such, during these steps, the user 350 could be displayed a brief “loading” or “working” screen on user device 352, e.g., as depicted in view 404 of FIG. 4A.

[0079] Referring back to FIG. 3, at step S312, given that the credential is not associated with the device identifier, the passkey server 360 can initiate an alternative authentication process. The user device 352 can be authenticated via the alternative authentication process. The authentication process can be performed by the user device 352 and the authorizing entity computer 366 or access control server 364. This may be useful as an authorizing entity (e.g., an issuing bank) associated with the authorizing entity computer 366 or access control server 364 may have initially issued the credential to the user 350, and consequently the authorizing entity may be better suited to authenticate the user 350 and the user device 352. After the alternative authentication process is performed, the passkey server 360 can provide a message (e.g., a “first message”) indicating that the user device 352 is authenticated, e.g., to any device, entity, or system depicted in FIG. 3. Such a message can contain a cryptogram indicating that the user 350 has been verified or authenticated.

[0080] Various alternative authentication processes are possible. In some embodiments, the alternative authentication process can comprise a 3-D secure authentication process performed by the user device 352 and the authorizing entity computer 366. Such a 3-D secure authentication process can involve the use of a “3-D Secure Protocol”, such as the “EMV® 3-D Secure Protocol”. A 3-D Secure Protocol process flow will not be described in detail herein. More specific details about 3-D Secure Protocols can be found in the “EMV® 3-D Secure Protocol and Core Functions Specification” (e.g., version 2.2.0 updated June 2023). However, in general terms, 3-D Secure Protocols enables authentication steps to be performed in order to authorize an interaction, usually by an authorizing entity. 3-D Secure Protocols can support various different authentication methods, which may be set based on the preferences of authorizing entities, assessments of risk or security requirements, etc. For example, a 3-D Secure Protocol could involve an authorizing entity computer 366 transmitting a one-time password (OTP) or a verification link to the user device 352 (e.g., via a text message) and requesting that the user 350 either input the one-time password into a form (e.g., via a web browser running on user device 352) or click the verification link.

[0081] After the alternative authentication process is performed, the user 350 can subsequently be offered an opportunity to enroll in a passkey-based authentication system according to embodiments (e.g., in steps S316-S328), which may provide user 350 with a more streamlined authentication process for future interactions using their credential. This enrollment process can benefit from the alternative authentication process, i.e. , the user 350 can be enrolled in the passkeybased authentication system given that they have successfully been authenticated via the alternative authentication process (e.g., given that they have been authenticated via 3-D Secure).

[0082] Step S312 generally corresponds to views 406-412 of FIG. 4B-4C. As depicted in view 406, a message can be displayed to the user via the user device, e.g., in an iframe or via any other suitable means. Such a message can indicate that the user may need to perform additional authentication steps before the interaction can be authorized. In addition, interaction details can be displayed to the user via the message, e.g., indicating an interaction amount (e.g., a transaction amount), a resource provider identifier (e.g., the name of a merchant), etc., enabling the user to review and confirm the interaction details before submitting to the alternative authentication process. As shown in view 408, the user may be prompted to perform a biometric authentication (e.g., in displayed message 432). Upon completing biometric authentication, the user may be prompted to approve or cancel the interaction (view 410), which may additionally involve displaying interaction details to the user. Afterwards, the user can be shown a verification screen (view 412). Various other 3-D Secure Challenge steps can be performed, as described in more detail in the EMV® 3-D Secure Protocol and Core Functions Specification, which may not be visible to the user.

[0083] Referring back to FIG. 3, at step S314, after the user 350 has been authenticated, an authorization process can be performed for the interaction. An authorization request message (e.g., comprising an ECI 05 authentication indicator) can be sent to authorizing entity computer 366 from resource provider computer 354, e.g., via processing network 362 (e.g., a payment processing network such as VisaNet). The authorizing entity computer 366 can review the authorization request message and any relevant data therein. For example, the authorization request message may contain a cryptogram indicating that the user 350 has been authenticated via the alternative authentication process, as well as various interaction details associated with the interaction. The authorizing entity computer 366 can approve or decline the interaction (e.g., approving the interaction provided that user 350 has been successfully authenticated and declining otherwise) and generate an authorization response message, which can be relayed back to the resource provider computer 354 (e.g., via processing network 362). The resource provider computer 354 can then complete or terminate the interaction based on the authorization response message, e.g., completing the interaction by providing some resource (e.g., access to an email account, access to a streaming service, etc.) to the user 350, e.g., via user device 352.

[0084] After performing the interaction, user 350 can be offered to enroll in a passkey-based authentication system according to embodiments. As such, in some embodiments the passkey server 360 can transmit an enrollment request message to the user device 352. In some embodiments, the passkey server 360 can transmit the enrollment request message to the user device 352 responsive to successful authentication of the user device 352 via the alternative authentication process. View 414 of FIG. 4D shows a prompt or message being shown to the user, which may be displayed to the user via an iframe in a resource provider website (or via some other display element, e.g., a pop-up). The user can use III elements such as a button 434 in order to enroll in the passkey-based authentication service. Such a button could open another interface (view 416), e.g., by redirecting the user to a website associated with a processing network and a passkey server. The interface can indicate to the user that the passkey will be associated with the user device and with the provided credential (e.g., the PAN). This enrollment process generally corresponds to steps S316-S328 of FIG. 3.

[0085] Referring back to FIG. 3, at step S316, a registration message can be sent to the passkey server 360, e.g., from resource provider computer 354 via authentication server computer 356, from user device 352 via authentication server computer 356, from user device 352 via resource provider computer 354 and authentication server computer 356, etc. The registration message can comprise the session identifier and an alternative authentication identifier (e.g., a 3-D Secure transaction identifier) corresponding to the interaction. The alternative authentication identifier can confirm that the user 350 was authenticated (i.e. , via the alternative authentication process), and thus can safely be enrolled in passkey-based authentication systems according to embodiments. The passkey server 360 can use the session identifier to identify any relevant data collected during steps S304-S310, e.g., relevant user device data, confirmation that the user device 352 is capable of performing authentication using digital signatures and passkeys (e.g., confirming that user device 352 is FIDO compatible), confirmation that user 350 and user device 352 are not already enrolled in passkey-based authentication systems according to embodiments, etc. The registration message can also confirm the intent by the user 350 to enroll in passkey-based authentication systems according to embodiments.

[0086] At step S318, an authentication request object can be sent to the user device 352, enabling the user device 352 to continue the enrollment process. The authentication request object can be sent to the user device 352 via authentication server computer 356, via the resource provider computer 354 (e.g., via a resource provider website displayed to user 350 via user device 352), etc.

[0087] At step S320, the authentication request object can be sent back to the passkey server 360 from user device 352, e.g., via resource provider computer 354 and authentication server computer 356.

[0088] Afterwards, at step S322, the user device 352 can generate a passkey that can be used for later authentication. The passkey can comprise a public private-key pair. Thus at step S322, the user device 352 can generate a public key and a private key of a public-private key pair. In some embodiments, the user device 352 can generate the public key and the private key of the public-private key pair responsive to an enrollment request message received by the user device 352 from the passkey server 360. The user device 352 can securely store the private key, e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc. Further, the user device 352 can generate an enrollment response message and transmit the enrollment response message to the passkey server 360. The enrollment response message can include authentication data (e.g., FIDO authentication data) including the public key. The passkey server 360 can store the public key in association with other information related to the user, e.g., the user device identifier, the credential, the device data, and any other applicable information. In some embodiments, the passkey server 360 can store such data by generating a database record indicating that the credential is associated with the device identifier and the public key of the public-private key pair.

[0089] In some embodiments, the user device 352 may perform additional authentication prior to generating the public-private keypair, e.g., biometric authentication, e.g., as shown in views 418 and 420 of FIG. 4E, in which the user is provided a message 436 asking the user whether they would like to use facial recognition in order to sign in to their user device as part of the passkey generation process. Afterwards, the user can be displayed a brief “loading” or “working” screen (view 422) while the public-private key pair is generated and various other steps are performed (e.g., steps S234-S238).

[0090] Referring back to FIG. 3, at step S324, the passkey server 360 can transmit a passkey payload (e.g., a FIDO payload) to the authentication server computer 356, effectively informing the authentication server computer 356 (e.g., a 3-D Secure server) that the user 350 and user device 352 have been enrolled in passkey-based authentication systems according to embodiments.

[0091] Subsequently, at step S326, the authentication server computer 356 can transmit the passkey payload to the access control server 364, e.g., via directory server 358 (which may identify an access control server relevant to the passkey payload using its directory, e.g., an access control server corresponding to an issuer that issued a payment credential to user 350). The passkey payload can indicate to the authorizing entity that the user was enrolled in a passkey-based authentication system according to embodiments (in other words that a passkey, e.g., a FIDO or FIDO2 passkey, was created) and did so by authenticating the user 350 through an alternative authentication process (e.g., 3-D Secure, ID&V, etc.)

[0092] At step S328, the access control server 364 can transmit a success response to authentication server computer 356 (e.g., via directory server 358), thereby notifying the authentication server computer 356 that the authorizing entity has received the passkey payload and is aware that user 350 and user device 352 have been enrolled in passkey-based authentication systems according to embodiments. Referring to FIGs. 4F-4G, the user may be displayed various other views via the user device, e.g., a view requesting the user to input an email address so that a passkey creation confirmation email can be sent to the user (view 424) and a view showing an exemplary passkey creation confirmation email (view 426).

[0093] At this point, user 350 can use their passkey to be authenticated as part of interactions with various resource providers, without needing to perform an alternative authentication process. A method for authenticating a user using a passkey during an interaction is described below with reference to FIG. 5. [0094] FIG. 5 shows a sequence diagram corresponding to an interaction between a user 550 and a resource provider. In this interaction, the user 550 has already registered with a passkey-based authentication system according to embodiments (e.g., as described above with reference to FIG. 3). As such, the user 550 can be authenticated using passkey-based authentication methods according to embodiments and does not need to be authenticated using an alternative authentication process (e.g., 3-D Secure).

[0095] Similar to FIG. 3, the computers, devices, and entities in FIG. 5 can generally be divided into a resource provider domain 568 (including user 550, user device 552, resource provider computer 554, and authentication server computer 556 (e.g., a 3-D Secure authentication server)), interoperability domain 570 (including directory server 558, passkey server 560, and processing network 562), and authorizing entity domain 572 (including access control server 564 and authorizing entity computer 566).

[0096] At step S502, a user 550 operating a user device 552 can conduct an interaction with a resource provider via resource provider computer 554. User device 352 may be interacting with a resource provider website operated by resource provider computer 354 in order to conduct the interaction. As described above with reference to FIG. 3, “conducting” an interaction can take various forms depending on the nature of the resource provider and any resources provided by that resource provider. For example, user 550 could conduct an interaction by providing a credential (e.g., a password) to a web form associated with an email hosting service and clicking or otherwise selecting a “login” button. As another example, user 550 could conduct an interaction (transaction) with a merchant resource provider by inputting a credential (e.g., a PAN) into a web form and clicking or otherwise selecting a “checkout” button, thereby signaling their intent to pay for any goods or services in their virtual cart. FIG. 6A shows a view 602 of a smartphone user device displaying a resource provider website (e.g., hosted by resource provider computer 354) via a browser application. As part of the interaction, the user has provided a credential 616 (e.g., a credit card number) into an associated field in the resource provider website. The user can signal their intent to make a purchase using the provided credential by selecting a checkout button 620. [0097] In some embodiments, the resource provider website can comprise a “second resource provider website” (e.g., to differentiate it from a “first resource provider website” described above with reference to FIG. 3). Likewise, the resource provider computer 354 can comprise a second resource provider computer and the interaction can comprise a second interaction. In other words, a passkey generated during an interaction with one resource provider computer can be used to authenticate a user during an interaction with another resource provider computer. However, it is also possible that the two resource providers are the same, i.e. , in some embodiments, the first resource provider computer and the second resource provider computer can comprise a same resource provider computer and the first resource provider website and the second resource provider website can comprise a same resource provider website.

[0098] Referring back to FIG. 5, at step S504, an initialization request message (e.g., a second initialization request message) can be transmitted to passkey server 560 (sometimes more generically referred to as a “server computer”). The passkey server 560 can receive the initialization request message from the user device 552, e.g., via resource provider computer 554 and/or authentication server computer 556 (which may comprise a 3-D Secure authentication server) or from the resource provider computer 554 itself. The initialization request message can comprise device data associated with the user device 552. In some embodiments, an HTML “iframe” embedded in the resource provider website can be used to transmit the device data from the user device 552 to the passkey server 560, e.g., via a user device SDK (e.g., accessible by a browser application) that enables device data to be read from the user device 552.

[0099] As described further above, the device data can include any suitable data that can be used to identify the user device 552, e.g., via “device fingerprinting” processes. For example, the device data can include a numerical or alphanumerical code that can be used to identify the user device 552 (e.g., a phone number, an international mobile equipment identity (IMEI) number, an embedded identity document (EID) number, etc.). The device data can also include, as examples, an IP address, geolocation data, a browser type or browser version number, processor data (e.g., identifying a processor or microprocessor type or model number), a model number, a manufacturer name, an operating system identifier, device component data (e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.), etc.

[0100] The passkey server 560 can determine a device identifier based on the device data. The device identifier can uniquely identify the user device 552 based on its associated device data. There are various ways that the passkey server 560 can determine a device identifier based on the device data. For example, the passkey server 560 could rely on an external authentication provider or device intelligence provider, which could generate the device identifier based on the provided device data and return the device identifier to the passkey server 560. As another alternative, the passkey server 560 could hash the device data (or some subset of the device data), thereby generating a device hash. Provided that the device data provided by a given user device is consistent, the device hash is consistent, and thus the device hash can be used to identify the user device 552. As such, in some embodiments the device identifier can comprise the device hash.

[0101] As described in more detail in subsequent steps, the device identifier can be used by the passkey server 560 to look up a database record corresponding to user device 552. Such a database record can indicate whether user device 552 is enrolled in a passkey-based authentication system according to embodiments, e.g., if a passkey (or a component of a passkey, e.g., a related public key) is recorded in the database record in associated with the user device 552 and any applicable credential (e.g., the credential provided at step S502, e.g., a PAN).

[0102] Additionally, the passkey server 560 can determine a session identifier (e.g., a “second session identifier”). The session identifier can generally identify the interaction between the user 550 and the resource provider, or e.g., a “session” associated with the interaction, e.g., a particular “authentication session” taking place in order to authenticate the user 550. Such a session identifier can be determined in any appropriate manner, e.g., a session identifier could comprise the next sequential number in a sequence of numbers used as session identifiers.

[0103] Further, the passkey server 560 can determine that the user device 552 is capable of performing an authentication process using a digital signature, e.g., is capable of performing passkey-based authentication methods according to embodiments. The passkey server 560 can make this determination based on the received device data. For example, in some embodiments, in which the user 550 and user device 552 are authenticated via FIDO passkeys, the passkey server 560 can determine that the user device is capable of performing the authentication process using the digital signature by determining that the user device is FIDO compatible. The passkey server 560 could determine, based on the device data, whether the user device 552 has any appropriate APIs for performing authentication using a digital signature, e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.), and whether the user device can support any appropriate authentication protocols (e.g., the client to authenticator protocol CTAP1 or CTAP2).

[0104] The passkey server 560 can also determine whether the user device 552 has any form of secure memory that can securely store a private key for authentication (e.g., a private key that can be used to generate the digital signature), such as a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), a “vault”, “keychain”, etc. The passkey server 560 can further determine whether the user device 552 possesses any hardware or components that may be used for user authentication, e.g., a biometric interface (such as a fingerprint scanner or a camera for performing an iris scan or facial recognition) as part of determining whether the user device 552 is capable of performing an authentication process using a digital signature.

[0105] At step S506, the passkey server 560 can transmit the session identifier to the resource provider computer 554. Alternatively or additionally, the passkey server 560 can transmit the session identifier to user device 552. The passkey server 560 can additionally transmit a flag indicating that the user device 552 is capable of performing an authentication process using a digital signature, e.g., that the user device 552 is capable of performing a FIDO authentication process. In some embodiments, the passkey server 560 can transmit the session identifier and the flag via the authentication server computer 556 (which can comprise a 3-D Secure server).

[0106] At step S508, the passkey server 560 can receive the session identifier (also referred to as a “second session identifier”) and interaction data associated with the interaction (also referred to as a “second interaction”). The interaction data can comprise a credential (e.g., a PAN), as well as various other data, such as a resource provider identifier (e.g., a merchant identifier), an interaction amount (e.g., a transaction amount), a currency, a transaction UUID (unique universal identifier), etc. The passkey server 560 can receive the session identifier and the interaction data from the resource provider computer 554, e.g., via authentication server computer 556 (which may comprise a 3-D Secure authentication server). Alternatively, the passkey server 560 can receive the session identifier and interaction data from the user device 552 instead of the resource provider computer 554.

[0107] At step S510, the passkey server 560 can identify a database record from a database. The database record can indicate that the credential is associated with the device identifier and a public key of a public-private key pair (e.g., comprising or corresponding to a passkey). In some embodiments, the publicprivate key pair can comprise a Fast Identity Online (FIDO) passkey. In this way, the passkey server 560 can determine that the user device 552 is enrolled in a passkeybased authentication system according to embodiments.

[0108] Steps S504-S510 generally do not require any input on behalf of the user. As such, during these steps, the user 550 could be displayed a brief “loading” or “working” screen on user device 552, e.g., as depicted in view 604 of FIG. 6A.

[0109] At step S512, an authentication request including an authentication request object can be sent by the authentication server computer 556 to the passkey server 560. Passkey server 560 can then initiate passkey-based authentication of user 550 (e.g., at step S514 described below).

[0110] At step S514, the user 550 and user device 552 can be authenticated using passkey-based authentication. As such, in step S514, the passkey server 560 can transmit a challenge message to the user device 552. The user device 552 can sign the challenge message using a private key of the public-private key pair to produce a digital signature (which can be verified by the passkey server 560 to authenticate user 550, e.g., as described in more detail below).

[0111] In some embodiments, an authentication confirmation message can be displayed to the user 550 of user device 552, e.g., via a web browser application. In some embodiments, the authentication confirmation message can be displayed to the user 550 in an iframe in the resource provider website. Further, the authentication confirmation message can correspond to a server computer website associated with the passkey server 560. In some embodiments, the user device 552 can sign the challenge message using the private key of the public-private key pair responsive to user confirmation of the authentication confirmation message. View 606 of FIG. 6B shows an authentication confirmation message, which the user 550 can confirm via selecting button 622. The authentication confirmation message can include various interaction data, enabling the user 550 to confirm these interaction data prior to authentication. For example, in a payment transaction, a transaction amount can be displayed to the user 550, enabling the user 550 to confirm that they are not being overcharged.

[0112] In some embodiments, the challenge message can comprise the interaction data. Using a challenge message comprising interaction data to authenticate the user device 552 guarantees that the interaction data was presented to the user 550 in some form (e.g., by being transmitted to the user device 552, displayed in an authentication confirmation message, etc.). This can be useful during later authorization of the interaction, as the digital signature produced by signing the challenge message can be presented to an authorizing entity (e.g., operating authorizing entity computer 566), both confirming that the user 550 was presented details about the interaction (in the form of the interaction data) and was authenticated using passkey-based authentication methods according to embodiments (e.g., as the challenge message was signed using the private key to generate the digital signature).

[0113] In some embodiments, the user device 552 can authenticate the user 550 of the user device 552 prior to signing the challenge message using the private key. In some embodiments, the user device 552 can authenticate the user 550 of the user device 552 using a biometric sample, passcode and/or password. The user device 552 can sign the challenge message using the private key responsive to successfully authenticating the user via the biometric sample, passcode, or password. Views 608 and 610 of FIGs. 6B and 6C generally show such an authentication process. In views 608 and 610 the user is prompted to use facial recognition to sign-in, e.g., via message 618. [0114] Having the user device 552 authenticate the user 550 results in a convenient and familiar form of two-factor authentication for the user 550. Because passkeys according to embodiments can be device-bound, passkey-based authentication methods according to embodiments naturally demonstrate that the user 550 is in possession of their user device 552, satisfying the “something they have” authentication factor. If the user 550 is additionally authenticated via a biometric or password, that satisfies either the “something they are” or “something they know” authentication factor, meaning that at least two factors have been used to authenticate the user 550. Moreover, many user devices use biometrics for unlocking purposes (e.g., fingerprint scans or thumbprint scans, facial recognition, etc.), and many users are used to providing such biometrics in order to use their user devices. Moreover, even though methods according to embodiments can provide two (or more) factor authentication, from the user’s perspective, they only needed to provide one form of authentication, e.g., a passcode, password, or biometric sample. The user 550 does not need to e.g., receive a one-time passcode sent via text or email and input it into a web form. In this way, embodiments of the present disclosure provide a frictionless user experience.

[0115] After generating the digital signature, the user device 552 can transmit the digital signature to the passkey server 560. The passkey server 560 can then validate the digital signature using the public key of the public-private key pair, which the passkey server 560 could have identified in a previous step, e.g., when identifying a data record corresponding to the device identifier at step S504. In this way, the passkey server 560 and user device 552 can be used to authenticate user 550 and user device 552. After authenticating the user 550 and user device 552, steps S516-S522 can be performed (as described below) in order to authorize and complete the interaction between user 550 and the resource provider.

[0116] At step S516, the passkey server 560 can provide a message indicating that the user device 552 has been authenticated. In some embodiments, in which the public-private key pair corresponds to a FIDO passkey, the message can comprise a FIDO payload. In some embodiments, the passkey server 560 can provide the message indicating that the user device 552 is authenticated to the authentication server computer 556. [0117] In some embodiments, the passkey server 560 can use a directory server 558 and the credential to identify an access control server 564 associated with authorizing entity computer 566. The authorizing entity computer 566 can be associated with the credential, e.g., the authorizing entity computer 566 can comprise a computer system associated with an issuing bank (authorizing entity) that issued the credential (e.g., a PAN) to user 550. In some embodiments, the passkey server 560 can provide the message by transmitting the message to the access control server 564.

[0118] In some embodiments, the message can comprise the digital signature. As described above, the digital signature can be generated by the user device 552 by encrypting a challenge message using the private key. Also as described above, the challenge message can comprise interaction data corresponding to the interaction between user 550 and the resource provider. As such, generating the digital signature can effectively comprise signing the interaction data.

[0119] In such embodiments, the passkey server 560 can provide the message by providing the message to the authorizing entity computer. The authorizing entity 566 computer can validate the interaction between the user 550 and the resource provider computer by analyzing the digital signature. For example, the authorizing entity computer 566 may have received an authorization request message from the resource provider computer 554, e.g., requesting authorization for an interaction between user 550 and the resource provider. The authorization request message can contain the interaction data. For example, if the interaction comprises a payment transaction, the authorization request message can include a transaction amount and a merchant identifier. In such embodiments, the authorizing entity computer 566 can validate the interaction by decrypting the digital signature using the public key and comparing a result of the decryption to the interaction data from the authorization request message. Generally, if the digital signature was generated using a challenge message comprising the interaction data, decrypting the digital signature should reproduce the interaction data. In this way, the authorizing entity can confirm that the interaction data provided by the resource provider and the interaction data provided by the user are identical, providing evidence that the interaction is legitimate. [0120] Various steps described above can be performed with other computer systems, entities, and devices depicted in FIG. 5. For example, at step S518, the authentication server computer 556 can send the message (which can comprise, e.g., a FIDO payload) to the access control server 564 via directory server 558. This step can generally inform the authorizing entity that a passkey-based authentication method according to embodiments was performed in order to authenticate user 550 and user device 552.

[0121] At step S520, a success message can be sent from the access control server 564 to the authentication server computer 556 via the directory server 558. The success message can also be passed to the resource provider computer 554.

[0122] Afterwards, at step S522, an authorization request message can be sent to the authorizing entity computer 566 in order to request authorization for the interaction between user 550 and the resource provider. In some embodiments, the resource provider computer 554 can generate the authorization request message and send it to the authorizing entity computer 566. The resource provider computer 554 may be assisted by a processing network 562 (e.g., VisaNet), which may route the authorization request message to the correct authorizing entity computer 566. The authorizing entity computer 566 can then generate an authorization response message and return it to resource provider computer 554 via processing network 562. The authorization response message can indicate whether the interaction has been approved (e.g., if the user 550 has been authenticated) or has been declined. Based on the authorization response message, the resource provider computer 554 can either complete or terminate the interaction.

[0123] In some embodiments, the passkey server 560 can provide the message by transmitting the message to the authorizing entity computer 566, e.g., directly or via the authentication server computer 556, directory server 558, processing network 562, etc. As described above, the authorizing entity computer can generate an authorization response message. The authorization response message can indicate the interaction is approved (e.g., based on the information contained in the message). The authorizing entity computer 566 can transmit the authorization response message to the resource provider computer 554. The resource provider computer 554 can complete the interaction responsive to receiving the authorization response message.

[0124] Steps S516-S522 generally do not require action on the part of the user 550 or user device 552. As such, during these steps, the user device 552 can be used to display a “loading” or “working” page to the user 550, e.g., as depicted in view 612 of FIG. 6C. However, after the resource provider computer 554 receives the authorization response message, a message can be displayed to the user 550 indicating the status of the interaction, e.g., indicating whether the interaction was approved or declined, as shown in view 614 of FIG. 6D.

[0125] FIG. 7 shows an exemplary user device 700. A user device according to some embodiments may comprise a computer system (e.g., a desktop or laptop computer, a tablet, a mobile phone, a smartwatch, etc.). User devices and computer systems mentioned herein may utilize any suitable number of subsystems.

Examples of such subsystems are shown in user device 700. In some embodiments, a user device includes a single computer apparatus and the subsystems can be the components of the computer apparatus. In other embodiments, a user device can include multiple computer apparatuses with internal components, each being a subsystem of the user device.

[0126] The subsystems shown in user device 700 can be connected via a system bus 720. Additional subsystems such as a printer 718, keyboard 714, computer readable media 722 (including system memory, storage devices, etc.), data collection device 716 (e.g., a camera, microphone, accelerometer, GPS unit, fingerprint scanner, etc.), monitor 710 (e.g., a display screen, such as an LED display), which is coupled to display adaptor 708, and others, are shown.

Peripherals and input/output (I/O) devices, which couple to I/O controller 706, can be connected to the user device 700 by any number of means known in the art such as an input/output port 712 (e.g., USB, FireWire®). Likewise, I/O port 712 or an external interface 704 (e.g., Ethernet, Wi-Fi, Near Field Communication, Bluetooth, ZigBee interfaces, etc.) can be used to connect user device 700 to various networks, devices, and computer systems, such as a wide area network such as the Internet, a mouse input device, a scanner, an access device (e.g., a point-of-sale terminal), a resource provider computer, a passkey server, an access control server, etc. [0127] User device 700 can include a plurality of the same components or subsystems, e.g., connected together by external interface 704, by an internal interface, or via removal storage devices that can be connected and removed from one component to another component. Additionally, user device 700 may lack (even temporarily) some of the components and subsystems depicted in FIG. 7. As such, it should be understood that the various components and subsystems depicted in FIG. 7 are optional.

[0128] The interconnection via system bus 720 allows the processor 702 (which may comprise a “central processor”, “central processing unit”, “CPU”, or other like terms) to communicate with each subsystem to control the execution of instructions or code from computer readable medium 722 (e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.), as well as the exchange of information between subsystems. Various software modules 724- 734 can be used to implement various methods described herein. It should be understood that the particular software modules depicted in FIG. 7 (and their configuration) are intended to represent only one possible implementation, selected for ease of exposition, and are not intended to be limiting. Various other configurations may become apparent upon reading this disclosure, e.g., implementing methods according to embodiments using a single monolithic software module rather than using software modules 724-734 as depicted in FIG. 7. Further, it should be understood that various software modules that would likely be included in computer readable media 722 of user device 700 are omitted for brevity. As an example, FIG. 7 does not depict an operating system (i.e. , system software that manages hardware and software resources, provides common services and task scheduling, etc.), even though many user devices have operating systems.

[0129] These software modules can include a browser application 724. The browser application 724 may enable a user to navigate to various websites, e.g., for the purpose of performing interactions with resource providers via resource provider websites. The browser application 724 may enable various transmissions of data as described above. For example, the browser application 724 may enable the user to provide a credential to a resource provider computer, may enable the user to enroll in a passkey-based authentication system according to embodiments, etc. Similarly, user device 700 can include a resource provider application 726, which may enable the user device 700 to interface with a resource provider computer without using browser application 724. Such a resource provider application 726 could comprise, e.g., a smartphone application associated with a large ecommerce merchant.

[0130] User device 700 can further include a cryptography module 728 and a secure memory 730, which can be used to perform various cryptographic operations described herein. For example, user device 700 can use cryptography module 728 to generate public-private key pairs (as part of passkey-based authentication enrollment) as well as digitally sign challenge messages using private keys. User device 700 can use secure memory 730 to store such private keys, as well as any relevant credentials, if necessary.

[0131] User device 700 can additionally include a biometric module 732 that the user device 700 can use to perform biometric authentication of a user, including collecting biometric samples via a data collection device 716 (such as a fingerprint scanner or a camera) and analyzing those biometric samples (e.g., by comparing them to biometric data stored in secure memory 730) in order to biometrically authenticate the user, e.g., prior to digitally signing a challenge message during passkey-based authentication.

[0132] User device 700 can additionally include a device data software development kit (SDK) 734, which can be used by the user device 700 to produce and transmit device data to a passkey server, e.g., enabling the passkey server to determine a device identifier as part of passkey-based authentication methods according to embodiments.

[0133] FIG. 8 shows an exemplary passkey server 800. A passkey server according to some embodiments may comprise a computer system (e.g., a server computer). As described above, computer systems mentioned herein may utilize any suitable number of subsystems. Examples of such subsystems are shown in passkey server 800. In some embodiments, a passkey server includes a single computer apparatus and the subsystems can be the components of the computer apparatus. In other embodiments, a passkey server can include multiple computer apparatuses with internal components, each being a subsystem of the passkey server. [0134] The subsystems shown in passkey server 800 can be connected via a system bus 820. Additional subsystems such as a printer 818, keyboard 814, computer readable media 822 (including system memory, storage devices, etc.), data collection device 816 (e.g., a camera, microphone, accelerometer, GPS unit, etc.), monitor 810 (e.g., a display screen, such as an LED display), which is coupled to display adaptor 808, and others, are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 806, can be connected to the passkey server 800 by any number of means known in the art such as an input/output port 812 (e.g., USB, FireWire®). Likewise, I/O port 812 or an external interface 804 (e.g., Ethernet, Wi-Fi, Near Field Communication, Bluetooth, ZigBee interfaces, etc.) can be used to connect passkey server 800 to various networks, devices, and computer systems, such as a wide area network such as the Internet, a mouse input device, a scanner, an access device (e.g., a point-of-sale terminal), a user device, an authentication server computer, a directory server, an access control server, etc.

[0135] Passkey server 800 can include a plurality of the same components or subsystems, e.g., connected together by external interface 804, by an internal interface, or via removal storage devices that can be connected and removed from one component to another component. Additionally, passkey server 800 may lack (even temporarily) some of the components and subsystems depicted in FIG. 8. As such, it should be understood that the various components and subsystems depicted in FIG. 8 are optional.

[0136] The interconnection via system bus 820 allows the processor 802 (which may comprise a “central processor”, “central processing unit”, “CPU”, or other like terms) to communicate with each subsystem to control the execution of instructions or code from computer readable medium 822 (e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.), as well as the exchange of information between subsystems. Various software modules 824- 834 can be used to implement various methods described herein. It should be understood that the particular software modules depicted in FIG. 8 (and their configuration) are intended to represent only one possible implementation, selected for ease of exposition, and are not intended to be limiting. Various other configurations may become apparent upon reading this disclosure, e.g., implementing methods according to embodiments using a single monolithic software module rather than using software modules 824-834 as depicted in FIG. 8. Further, it should be understood that various software modules that would likely be included in computer readable media 822 of passkey server 800 are omitted for brevity. As an example, FIG. 8 does not depict an operating system, even though many server computers have operating systems.

[0137] These software modules can include a device identifier module 824. The device identifier module 824 can be used by passkey server 800 to receive and interpret user device data, as well as generate user identifiers based on such user device data. Device identifier module 824 can be used in conjunction with a database management module 826, which can be used by passkey server 800 to manage database 828, e.g., to identify, add, delete, duplicate, etc., data records stored in database 828. As described above, such data records can be identified via device identifiers and can be used to establish a mapping between credentials, user devices, and public key components of passkeys used in methods according to embodiments.

[0138] Passkey server 800 can further include a signature verification module 830, which can be used by passkey server 800 to verify digital signatures produced by user devices as part of passkey-based authentication methods according to embodiments, e.g., passkey server 800 can use signature verification module 830 to verify digital signatures using a public key corresponding to a user device private key.

[0139] Passkey server 800 can further include a registration module 832, which can be used to perform various steps associated with registering a user device with passkey-based authentication methods according to embodiments, e.g., involving determining whether a user device is compatible with passkey-based authentication methods according to embodiments (e.g., is FIDO compatible), whether the user device is already enrolled in passkey-based authentication methods according to embodiments, initiating an alternative authentication process prior to registering the user device, etc.

[0140] Passkey server 800 can additionally include an interaction processing module 834, which passkey server 800 can use to perform various steps associated with processing an interaction or otherwise enabling the authorization of an interaction. For example, passkey server 800 can use interaction processing module 834 to forward the digital signature to an access control server or authorizing entity computer (via a directory server if necessary), in order to inform an authorizing entity that a user device has been authenticated using passkey-based authentication methods according to embodiments.

[0141] Any of the computer systems mentioned herein may utilize any suitable number of subsystems. In some embodiments, a computer system includes a single computer apparatus, where the subsystems can be components of the computer apparatus. In other embodiments, a computer system can include multiple computer apparatuses, each being a subsystem, with internal components.

[0142] A computer system can include a plurality of the components or subsystems, e.g., connected together by external interface or by an internal interface. In some embodiments, computer systems, subsystems, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each include multiple systems, subsystems, or components.

[0143] It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner, and thus a processor can include memory storing software instructions that configure hardware circuitry, as well as an FPGA with configuration instructions or an ASIC. As used herein a processor can include a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. The computations can be performed in parallel by the different processing units and/or different processing threads of a single processing unit. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software. [0144] 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) or Blu-ray disk, flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices. In addition, the order of operations may be re-arranged. A process can be terminated when its operations are complete but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function of the main function.

[0145] 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 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 (e.g., as firmware) 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.

[0146] Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps. Thus, embodiments can involve computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective step or a respective group of steps. Although presented as numbered steps, steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, any of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.

[0147] Any operation performed with a processor may be performed in realtime. The term “real-time” may refer to computing operations or processes that are completed within a certain time constraint. As examples, a time constraint may be 30 seconds, 1 minute, 10 minutes, 30 minutes, 1 hour, 4 hours, 1 day, or 7 days, or different from any of these.

[0148] In some embodiments, computer systems, subsystems, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each involve multiple systems, subsystems, or components. In various embodiments, methods may involve various numbers of clients and/or servers, including at least 10, 20, 50, 100, 200, 500, 1 ,000, or 10,000 devices. Methods can include various numbers of communication messages between devices, including at least 100, 200, 500, 1 ,000, 10,000, 50,000, 100,000, 500,000, or one million communication messages. Such communications can involve at least 1 KB, 1 MB, 10 MB, 100 MB, 1 GB, 10 GB, or 100 GB of data.

[0149] The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. However, other embodiments of the invention may be directed to specific embodiments relating to each individual aspect, or specific combinations of these individual aspects.

[0150] The above description of exemplary embodiments of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. [0151] 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.

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

[0153] A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary. Reference to a “first” component does not necessarily require that a second component be provided. Moreover, reference to a “first” or “second” component does not limit the referenced component to a particular location unless explicitly stated. The term “based on” is intended to mean “based at least in part on.”

[0154] The claims may be drafted to exclude any elements which may be optional. As such, this statement is intended to serve as antecedent basis for use of such exclusive terminology as “solely”, “only”, and the like in connection with the recitation of claim elements, or the use of a “negative” limitation.

[0155] All patents, patent applications, publications and description mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted as prior art. Wherein a conflict exists between the instant application and a reference provided herein, the instant application shall dominate.

Claims

WHAT IS CLAIMED IS:

1 . A method comprising: receiving, by a server computer, from a user device interacting with a resource provider website operated by a resource provider computer to conduct an interaction, an initialization request message comprising device data associated with the user device; determining, by the server computer, a device identifier based on the device data; determining, by the server computer, a session identifier; determining, by the server computer, that the user device is capable of performing an authentication process using a digital signature; transmitting, by the server computer, the session identifier; receiving, by the server computer, the session identifier and interaction data associated with the interaction, the interaction data comprising a credential; identifying, by the server computer, a database record from a database, the database record indicating that the credential is associated with the device identifier and a public key of a public-private key pair; transmitting, by the server computer, a challenge message to the user device, wherein the user device signs the challenge message using a private key of the public-private key pair to produce the digital signature; receiving, by the server computer, the digital signature; validating, by the server computer, the digital signature using the public key of the public-private key pair; and providing, by the server computer, a message indicating that the user device is authenticated.

2. The method of claim 1 , wherein the public-private key pair comprises a passkey, and wherein determining, by the server computer, that the user device is capable of performing the authentication process using the digital signature comprises determining whether the user device is FIDO-compatible.

3. The method of claim 1 , wherein the method further comprises, prior to receiving the initialization request message: transmitting, by the server computer, to the user device, an enrollment request message, wherein the user device generates the public key and the private key of the public-private key pair responsive to the enrollment request message; receiving, by the server computer, from the user device, an enrollment response message, the enrollment response message comprising the public key; and generating, by the server computer, the database record indicating that the credential is associated with the device identifier and the public key of the publicprivate key pair.

4. The method of claim 3, wherein the resource provider website comprises a second resource provider website, wherein the resource provider computer comprises a second resource provider computer, wherein the interaction comprises a second interaction, wherein the initialization request message comprises a second initialization request message, wherein the session identifier comprises a second session identifier, wherein the message comprises a second message, and wherein the method further comprises, prior to transmitting the enrollment request message: receiving, by the server computer, from the user device interacting with a first resource provider website operated by a first resource provider computer to conduct a first interaction, a first initialization request message comprising device data associated with the user device; determining, by the server computer, the device identifier based on the device data; determining, by the server computer, a first session identifier; determining, by the server computer, that the user device is capable of performing the authentication process using a digital signature; transmitting, by the server computer, the first session identifier; receiving, by the server computer, the first session identifier and interaction data associated with the first interaction, the interaction data comprising the credential; determining, by the server computer, that the credential is not associated with the device identifier and the public key of the public-private key pair; initiating, by the server computer, an alternative authentication process, wherein the user device is authenticated via the alternative authentication process; and providing, by the server computer, a first message indicating that the user device is authenticated.

5. The method of claim 4, wherein the alternative authentication process is a 3-D secure authentication process performed by the user device and an authorizing entity computer.

6. The method of claim 4, wherein the server computer transmits the enrollment request message to the user device responsive to successful authentication of the user device via the alternative authentication process.

7. The method of claim 1 , wherein the device identifier is randomly generated and is associated with the interaction data.

8. The method of claim 1 , wherein providing, by the server computer, the message comprises transmitting the message to an authorizing entity computer, wherein the authorizing entity computer generates an authorization response message, the authorization response message indicating that the interaction is approved, wherein the authorizing entity computer transmits the authorization response message to the resource provider computer, wherein the resource provider computer completes the interaction responsive to receiving the authorization response message.

9. The method of claim 1 , wherein: the interaction data further comprises a resource provider identifier; the challenge message comprises the interaction data; the message further comprises the digital signature; providing, by the server computer, the message comprises providing the message to an authorizing entity computer; the authorizing entity computer receives an authorization request message containing the interaction data; and the authorizing entity computer validates the interaction by decrypting the digital signature using the public key and comparing a result to the interaction data from the authorization request message.

10. A server computer comprising: a processor; and a non-transitory computer-readable medium coupled to the processor, the non-transitory computer-readable medium comprising code, executable by the processor, for performing a method comprising: receiving, from a user device interacting with a resource provider website operated by a resource provider computer to conduct an interaction, an initialization request message comprising device data associated with the user device; determining a device identifier based on the device data; determining a session identifier, determining that the user device is capable of performing an authentication process using a digital signature; transmitting the session identifier; receiving the session identifier and interaction data associated with the interaction, the interaction data comprising a credential; identifying a database record in a database, the database record indicating that the credential is associated with the device identifier and a public key of a public-private key pair; transmitting a challenge message to the user device, wherein the user device signs the challenge message using a private key of the public-private key pair to produce the digital signature; receiving the digital signature; validating the digital signature using the public key of the public-private key pair; and providing a message indicating that the user device is authenticated.

11 . The server computer of claim 10, wherein the device data comprises one or more of an IP address, geolocation data, a browser type, a browser version number, a model number, a manufacturer name, an operating system identifier, processor data, RAM data, a device identifier, and device component data.

12. The server computer of claim 10, wherein determining the device identifier based on the device data comprises hashing the device data, thereby generating a device hash, wherein the device identifier comprises the device hash.

13. The server computer of claim 10, wherein the server computer receives the initialization request message from the user device via the resource provider computer and/or the resource provider website.

14. The server computer of claim 10, wherein: the server computer receives the initialization request message via a 3- D Secure authentication server; the server computer transmits the session identifier to the 3-D Secure authentication server; and the server computer receives the session identifier and interaction data associated with the interaction from the 3-D Secure authentication server.

15. The server computer of claim 10, wherein providing a message indicating that the user device is authenticated comprises: identifying, based on the credential and using a directory server, an access control server associated with an authorizing entity computer, the authorizing entity computer associated with the credential; and transmitting the message to the access control server.

16. A method comprising: transmitting, by a user device interacting with a resource provider website operated by a resource provider computer to conduct an interaction, to a server computer, an initialization request message comprising device data associated with the user device, wherein: the server computer determines a device identifier based on the device data, the server computer determines a session identifier, and the server computer determines that the user device is capable of performing an authentication process using a digital signature; receiving, by the user device, from the server computer, the session identifier; transmitting, by the user device, to the server computer, the session identifier and interaction data associated with the interaction, the interaction data comprising a credential, wherein the server computer identifies a database record in a database, the database record indicating that the credential is associated with the device identifier and a public key of a public-private key pair; receiving, by the user device, from the server computer, a challenge message; signing, by the user device, the challenge message using a private key of the public-private key pair, thereby producing a digital signature; and transmitting, by the user device, to the server computer, the digital signature, wherein the server computer validates the digital signature using the public key of the public-private key pair and provides a message indicating that the user device is authenticated.

17. The method of claim 16, further comprising, prior to transmitting, by the user device, the initialization request message to the server computer: receiving, by the user device, from the server computer, an enrollment request message; generating, by the user device, the public key and the private key of the public-private key pair responsive to the enrollment request message; and transmitting, by the user device, to the server computer, an enrollment response message, wherein the enrollment response message comprises the public key, wherein the server computer generates the database record indicating that the credential is associated with the device identifier and the public key of the publicprivate key pair responsive to receiving the enrollment response message.

18. The method of claim 16, further comprising authenticating, by the user device, a user of the user device using a biometric sample, passcode, and/or password, wherein the user device signs the challenge message using the private key responsive to successfully authenticating the user via the biometric sample, passcode, and/or password.

19. The method of claim 16, further comprising: displaying, by the user device, to a user of the user device, via a web browser application, an authentication confirmation message, wherein the user device signs the challenge message using the private key of the public-private key pair responsive to user confirmation of the authentication confirmation message.

20. The method of claim 19, further comprising: displaying, by the user device, to a user of the user device, via the web browser application, the resource provider website, wherein the authentication confirmation message is displayed to the user in an iframe in the resource provider website, and wherein the authentication confirmation message corresponds to a server computer website associated with the server computer.